A use after free issue was discovered in driver/firewire in outboundphypacketcallback in the Linux Kernel. In this flaw a local attacker with special privilege may cause a use after free problem when queueevent() fails.
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: nuvoton: wpcm450: fix out of bounds write
Write into 'pctrl->gpiobank' happens before the check for GPIO index validity, so out of bounds write may happen.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
In the Linux kernel, the following vulnerability has been resolved:
mm/vmscan: fix a bug calling wakeupkswapd() with a wrong zone index
The Linux kernel CVE team has assigned CVE-2024-26783 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024040458-CVE-2024-26783-68c8@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
kprobes/x86: Use copyfromkernelnofault() to read from unsafe address
Read from an unsafe address with copyfromkernelnofault() in archadjustkprobeaddr() because this function is used before checking the address is in text or not. Syzcaller bot found a bug and reported the case if user specifies inaccessible data area, archadjustkprobeaddr() will cause a kernel panic.
[ mingo: Clarified the comment. ]
In the Linux kernel, the following vulnerability has been resolved:
mm/memory-failure: fix deadlock when hugetlboptimizevmemmap is enabled
The Linux kernel CVE team has assigned CVE-2024-26987 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050143-CVE-2024-26987-507c@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries: Fix potential memleak in paprgetattr()
buf is allocated in paprgetattr(), and krealloc() of buf could fail. We need to free the original buf in the case of failure.
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Fix NULL domain on device release
In the kdump kernel, the IOMMU operates in deferredattach mode. In this mode, info->domain may not yet be assigned by the time the releasedevice function is called. It leads to the following crash in the crash kernel:
BUG: kernel NULL pointer dereference, address: 000000000000003c ... RIP: 0010:dorawspinlock+0xa/0xa0 ... rawspinlockirqsave+0x1b/0x30 inteliommureleasedevice+0x96/0x170 iommudeinitdevice+0x39/0xf0 iommugroupremovedevice+0xa0/0xd0 iommubusnotifier+0x55/0xb0 notifiercallchain+0x5a/0xd0 blockingnotifiercallchain+0x41/0x60 busnotify+0x34/0x50 devicedel+0x269/0x3d0 pciremovebusdevice+0x77/0x100 p2sbbar+0xae/0x1d0 ... i801probe+0x423/0x740
Use the releasedomain mechanism to fix it. The scalable mode context entry which is not part of release domain should be cleared in releasedevice().
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix mlx5eprivinit() cleanup flow
The Linux kernel CVE team has assigned CVE-2024-35959 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024052019-CVE-2024-35959-6e06@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
virtionet: Do not send RSS key if it is not supported
There is a bug when setting the RSS options in virtionet that can break the whole machine, getting the kernel into an infinite loop.
Running the following command in any QEMU virtual machine with virtionet will reproduce this problem:
# ethtool -X eth0 hfunc toeplitz
This is how the problem happens:
1) ethtoolsetrxfh() calls virtnetsetrxfh()
2) virtnetsetrxfh() calls virtnetcommitrsscommand()
3) virtnetcommitrsscommand() populates 4 entries for the rss scatter-gather
4) Since the command above does not have a key, then the last scatter-gatter entry will be zeroed, since rsskeysize == 0. sgbufsize = vi->rsskeysize;
5) This buffer is passed to qemu, but qemu is not happy with a buffer with zero length, and do the following in virtqueuemapdesc() (QEMU function):
if (!sz) { virtioerror(vdev, "virtio: zero sized buffers are not allowed");
6) virtioerror() (also QEMU function) set the device as broken
vdev->broken = true;
7) Qemu bails out, and do not repond this crazy kernel.
8) The kernel is waiting for the response to come back (function virtnetsendcommand())
9) The kernel is waiting doing the following :
while (!virtqueuegetbuf(vi->cvq, &tmp) && !virtqueueisbroken(vi->cvq)) cpurelax();
10) None of the following functions above is true, thus, the kernel loops here forever. Keeping in mind that virtqueueisbroken() does not look at the qemu vdev->broken, so, it never realizes that the vitio is broken at QEMU side.
Fix it by not sending RSS commands if the feature is not available in the device.
In the Linux kernel, the following vulnerability has been resolved:
block: fix q->blkglist corruption during disk rebind
Multiple gendisk instances can allocated/added for single request queue in case of disk rebind. blkg may still stay in q->blkglist when calling blkcginitdisk() for rebind, then q->blkglist becomes corrupted.
Fix the list corruption issue by:
- add blkginitqueue() to initialize q->blkglist & q->blkcgmutex only - move calling blkginitqueue() into blkallocqueue()
The list corruption should be started since commit f1c006f1c685 ("blk-cgroup: synchronize pdfreefn() from blkgfreeworkfn() and blkcgdeactivatepolicy()") which delays removing blkg from q->blkglist into blkgfreeworkfn().
In the Linux kernel, the following vulnerability has been resolved:
phy: marvell: a3700-comphy: Fix out of bounds read
There is an out of bounds read access of 'gbephyinitfix[fixidx].addr' every iteration after 'fixidx' reaches 'ARRAYSIZE(gbephyinitfix)'.
Make sure 'gbephyinit[addr]' is used when all elements of 'gbephyinitfix' array are handled.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: fix a possible null pointer dereference
In radeonfpnativemode(), the return value of drmmodeduplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drmmodeduplicate(). Add a check to avoid npd.
The failure status of drmcvtmode() on the other path is checked too.
In the Linux kernel, the following vulnerability has been resolved:
drivers: perf: Check findfirstbit() return value
We must check the return value of findfirstbit() before using the return value as an index array since it happens to overflow the array and then panic:
[ 107.318430] Kernel BUG [#1] [ 107.319434] CPU: 3 PID: 1238 Comm: kill Tainted: G E 6.6.0-rc6ubuntu-defconfig #2 [ 107.319465] Hardware name: riscv-virtio,qemu (DT) [ 107.319551] epc : pmusbiovfhandler+0x3a4/0x3ae [ 107.319840] ra : pmusbiovfhandler+0x52/0x3ae [ 107.319868] epc : ffffffff80a0a77c ra : ffffffff80a0a42a sp : ffffaf83fecda350 [ 107.319884] gp : ffffffff823961a8 tp : ffffaf8083db1dc0 t0 : ffffaf83fecda480 [ 107.319899] t1 : ffffffff80cafe62 t2 : 000000000000ff00 s0 : ffffaf83fecda520 [ 107.319921] s1 : ffffaf83fecda380 a0 : 00000018fca29df0 a1 : ffffffffffffffff [ 107.319936] a2 : 0000000001073734 a3 : 0000000000000004 a4 : 0000000000000000 [ 107.319951] a5 : 0000000000000040 a6 : 000000001d1c8774 a7 : 0000000000504d55 [ 107.319965] s2 : ffffffff82451f10 s3 : ffffffff82724e70 s4 : 000000000000003f [ 107.319980] s5 : 0000000000000011 s6 : ffffaf8083db27c0 s7 : 0000000000000000 [ 107.319995] s8 : 0000000000000001 s9 : 00007fffb45d6558 s10: 00007fffb45d81a0 [ 107.320009] s11: ffffaf7ffff60000 t3 : 0000000000000004 t4 : 0000000000000000 [ 107.320023] t5 : ffffaf7f80000000 t6 : ffffaf8000000000 [ 107.320037] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 [ 107.320081] [<ffffffff80a0a77c>] pmusbiovfhandler+0x3a4/0x3ae [ 107.320112] [<ffffffff800b42d0>] handlepercpudevidirq+0x9e/0x1a0 [ 107.320131] [<ffffffff800ad92c>] generichandledomainirq+0x28/0x36 [ 107.320148] [<ffffffff8065f9f8>] riscvintcirq+0x36/0x4e [ 107.320166] [<ffffffff80caf4a0>] handleriscvirq+0x54/0x86 [ 107.320189] [<ffffffff80cb0036>] doirq+0x64/0x96 [ 107.320271] Code: 85a6 855e b097 ff7f 80e7 9220 b709 9002 4501 bbd9 (9002) 6097 [ 107.320585] ---[ end trace 0000000000000000 ]--- [ 107.320704] Kernel panic - not syncing: Fatal exception in interrupt [ 107.320775] SMP: stopping secondary CPUs [ 107.321219] Kernel Offset: 0x0 from 0xffffffff80000000 [ 107.333051] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
In the Linux kernel, the following vulnerability has been resolved:
media: hantro: Check whether reset op is defined before use
The i.MX8MM/N/P does not define the .reset op since reset of the VPU is done by genpd. Check whether the .reset op is defined before calling it to avoid NULL pointer dereference.
Note that the Fixes tag is set to the commit which removed the reset op from i.MX8M Hantro G2 implementation, this is because before this commit all the implementations did define the .reset op.
In the Linux kernel, the following vulnerability has been resolved:
mm: use memallocnofssave() in pagecacheraorder()
See commit f2c817bed58d ("mm: use memallocnofssave in readahead path"), ensure that pagecacheraorder() do not attempt to reclaim file-backed pages too, or it leads to a deadlock, found issue when test ext4 large folio.
INFO: task DataXceiver for:7494 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. task:DataXceiver for state:D stack:0 pid:7494 ppid:1 flags:0x00000200 Call trace: switchto+0x14c/0x240 schedule+0x82c/0xdd0 schedule+0x58/0xf0 ioschedule+0x24/0xa0 foliolock+0x130/0x300 migratepagesbatch+0x378/0x918 migratepages+0x350/0x700 compactzone+0x63c/0xb38 compactzoneorder+0xc0/0x118 trytocompactpages+0xb0/0x280 allocpagesdirectcompact+0x98/0x248 allocpages+0x510/0x1110 allocpages+0x9c/0x130 folioalloc+0x20/0x78 filemapallocfolio+0x8c/0x1b0 pagecacheraorder+0x174/0x308 ondemandreadahead+0x1c8/0x2b8 pagecacheasyncra+0x68/0xb8 filemapreadahead.isra.0+0x64/0xa8 filemapgetpages+0x3fc/0x5b0 filemapspliceread+0xf4/0x280 ext4filespliceread+0x2c/0x48 [ext4] vfsspliceread.part.0+0xa8/0x118 splicedirecttoactor+0xbc/0x288 dosplicedirect+0x9c/0x108 dosendfile+0x328/0x468 arm64syssendfile64+0x8c/0x148 invokesyscall+0x4c/0x118 el0svccommon.constprop.0+0xc8/0xf0 doel0svc+0x24/0x38 el0svc+0x4c/0x1f8 el0t64synchandler+0xc0/0xc8 el0t64sync+0x188/0x190
A flaw was found in the Linux kernel. The existing KVM SEV API has a vulnerability that allows a non-root (host) user-level application to crash the host kernel by creating a confidential guest VM instance in AMD CPU that supports Secure Encrypted Virtualization (SEV).
In the Linux kernel, the following vulnerability has been resolved:
mm/hugememory: don't unpoison hugezerofolio
When I did memory failure tests recently, below panic occurs:
kernel BUG at include/linux/mm.h:1135! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 9 PID: 137 Comm: kswapd1 Not tainted 6.9.0-rc4-00491-gd5ce28f156fe-dirty #14 RIP: 0010:shrinkhugezeropagescan+0x168/0x1a0 RSP: 0018:ffff9933c6c57bd0 EFLAGS: 00000246 RAX: 000000000000003e RBX: 0000000000000000 RCX: ffff88f61fc5c9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff88f61fc5c9c0 RBP: ffffcd7c446b0000 R08: ffffffff9a9405f0 R09: 0000000000005492 R10: 00000000000030ea R11: ffffffff9a9405f0 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88e703c4ac00 FS: 0000000000000000(0000) GS:ffff88f61fc40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055f4da6e9878 CR3: 0000000c71048000 CR4: 00000000000006f0 Call Trace: <TASK> doshrinkslab+0x14f/0x6a0 shrinkslab+0xca/0x8c0 shrinknode+0x2d0/0x7d0 balancepgdat+0x33a/0x720 kswapd+0x1f3/0x410 kthread+0xd5/0x100 retfromfork+0x2f/0x50 retfromforkasm+0x1a/0x30 </TASK> Modules linked in: mceinject hwpoisoninject ---[ end trace 0000000000000000 ]--- RIP: 0010:shrinkhugezeropagescan+0x168/0x1a0 RSP: 0018:ffff9933c6c57bd0 EFLAGS: 00000246 RAX: 000000000000003e RBX: 0000000000000000 RCX: ffff88f61fc5c9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff88f61fc5c9c0 RBP: ffffcd7c446b0000 R08: ffffffff9a9405f0 R09: 0000000000005492 R10: 00000000000030ea R11: ffffffff9a9405f0 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88e703c4ac00 FS: 0000000000000000(0000) GS:ffff88f61fc40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055f4da6e9878 CR3: 0000000c71048000 CR4: 00000000000006f0
The root cause is that HWPoison flag will be set for hugezerofolio without increasing the folio refcnt. But then unpoisonmemory() will decrease the folio refcnt unexpectedly as it appears like a successfully hwpoisoned folio leading to VMBUGONPAGE(pagerefcount(page) == 0) when releasing hugezerofolio.
Skip unpoisoning hugezerofolio in unpoisonmemory() to fix this issue. We're not prepared to unpoison hugezerofolio yet.
In the Linux kernel, the following vulnerability has been resolved:
btrfs: skip reserved bytes warning on unmount after log cleanup failure
After the recent changes made by commit c2e39305299f01 ("btrfs: clear extent buffer uptodate when we fail to write it") and its followup fix, commit 651740a5024117 ("btrfs: check WRITEERR when trying to read an extent buffer"), we can now end up not cleaning up space reservations of log tree extent buffers after a transaction abort happens, as well as not cleaning up still dirty extent buffers.
This happens because if writeback for a log tree extent buffer failed, then we have cleared the bit EXTENTBUFFERUPTODATE from the extent buffer and we have also set the bit EXTENTBUFFERWRITEERR on it. Later on, when trying to free the log tree with freelogtree(), which iterates over the tree, we can end up getting an -EIO error when trying to read a node or a leaf, since readextentbufferpages() returns -EIO if an extent buffer does not have EXTENTBUFFERUPTODATE set and has the EXTENTBUFFERWRITEERR bit set. Getting that -EIO means that we return immediately as we can not iterate over the entire tree.
In that case we never update the reserved space for an extent buffer in the respective block group and spaceinfo object.
When this happens we get the following traces when unmounting the fs:
[174957.284509] BTRFS: error (device dm-0) in cleanuptransaction:1913: errno=-5 IO failure [174957.286497] BTRFS: error (device dm-0) in freelogtree:3420: errno=-5 IO failure [174957.399379] ------------[ cut here ]------------ [174957.402497] WARNING: CPU: 2 PID: 3206883 at fs/btrfs/block-group.c:127 btrfsputblockgroup+0x77/0xb0 [btrfs] [174957.407523] Modules linked in: btrfs overlay dmzero (...) [174957.424917] CPU: 2 PID: 3206883 Comm: umount Tainted: G W 5.16.0-rc5-btrfs-next-109 #1 [174957.426689] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [174957.428716] RIP: 0010:btrfsputblockgroup+0x77/0xb0 [btrfs] [174957.429717] Code: 21 48 8b bd (...) [174957.432867] RSP: 0018:ffffb70d41cffdd0 EFLAGS: 00010206 [174957.433632] RAX: 0000000000000001 RBX: ffff8b09c3848000 RCX: ffff8b0758edd1c8 [174957.434689] RDX: 0000000000000001 RSI: ffffffffc0b467e7 RDI: ffff8b0758edd000 [174957.436068] RBP: ffff8b0758edd000 R08: 0000000000000000 R09: 0000000000000000 [174957.437114] R10: 0000000000000246 R11: 0000000000000000 R12: ffff8b09c3848148 [174957.438140] R13: ffff8b09c3848198 R14: ffff8b0758edd188 R15: dead000000000100 [174957.439317] FS: 00007f328fb82800(0000) GS:ffff8b0a2d200000(0000) knlGS:0000000000000000 [174957.440402] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [174957.441164] CR2: 00007fff13563e98 CR3: 0000000404f4e005 CR4: 0000000000370ee0 [174957.442117] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [174957.443076] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [174957.443948] Call Trace: [174957.444264] <TASK> [174957.444538] btrfsfreeblockgroups+0x255/0x3c0 [btrfs] [174957.445238] closectree+0x301/0x357 [btrfs] [174957.445803] ? callrcu+0x16c/0x290 [174957.446250] genericshutdownsuper+0x74/0x120 [174957.446832] killanonsuper+0x14/0x30 [174957.447305] btrfskillsuper+0x12/0x20 [btrfs] [174957.447890] deactivatelockedsuper+0x31/0xa0 [174957.448440] cleanupmnt+0x147/0x1c0 [174957.448888] taskworkrun+0x5c/0xa0 [174957.449336] exittousermodeprepare+0x1e5/0x1f0 [174957.449934] syscallexittousermode+0x16/0x40 [174957.450512] dosyscall64+0x48/0xc0 [174957.450980] entrySYSCALL64afterhwframe+0x44/0xae [174957.451605] RIP: 0033:0x7f328fdc4a97 [174957.452059] Code: 03 0c 00 f7 (...) [174957.454320] RSP: 002b:00007fff13564ec8 EFLAGS: 00000246 ORIGRAX: 00000000000000a6 [174957.455262] RAX: 0000000000000000 RBX: 00007f328feea264 RCX: 00007f328fdc4a97 [174957.456131] RDX: 0000000000000000 RSI: 00000000000000 ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
mm/filemap: skip to create PMD-sized page cache if needed
On ARM64, HPAGEPMDORDER is 13 when the base page size is 64KB. The PMD-sized page cache can't be supported by xarray as the following error messages indicate.
------------[ cut here ]------------ WARNING: CPU: 35 PID: 7484 at lib/xarray.c:1025 xassplitalloc+0xf8/0x128 Modules linked in: nftfibinet nftfibipv4 nftfibipv6 nftfib \ nftrejectinet nfrejectipv4 nfrejectipv6 nftreject nftct \ nftchainnat nfnat nfconntrack nfdefragipv6 nfdefragipv4 \ ipset rfkill nftables nfnetlink vfat fat virtioballoon drm \ fuse xfs libcrc32c crct10difce ghashce sha2ce sha256arm64 \ sha1ce virtionet netfailover virtioconsole virtioblk failover \ dimlib virtiommio CPU: 35 PID: 7484 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #9 Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024 pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : xassplitalloc+0xf8/0x128 lr : splithugepagetolisttoorder+0x1c4/0x720 sp : ffff800087a4f6c0 x29: ffff800087a4f6c0 x28: ffff800087a4f720 x27: 000000001fffffff x26: 0000000000000c40 x25: 000000000000000d x24: ffff00010625b858 x23: ffff800087a4f720 x22: ffffffdfc0780000 x21: 0000000000000000 x20: 0000000000000000 x19: ffffffdfc0780000 x18: 000000001ff40000 x17: 00000000ffffffff x16: 0000018000000000 x15: 51ec004000000000 x14: 0000e00000000000 x13: 0000000000002000 x12: 0000000000000020 x11: 51ec000000000000 x10: 51ece1c0ffff8000 x9 : ffffbeb961a44d28 x8 : 0000000000000003 x7 : ffffffdfc0456420 x6 : ffff0000e1aa6eb8 x5 : 20bf08b4fe778fca x4 : ffffffdfc0456420 x3 : 0000000000000c40 x2 : 000000000000000d x1 : 000000000000000c x0 : 0000000000000000 Call trace: xassplitalloc+0xf8/0x128 splithugepagetolisttoorder+0x1c4/0x720 truncateinodepartialfolio+0xdc/0x160 truncateinodepagesrange+0x1b4/0x4a8 truncatepagecacherange+0x84/0xa0 xfsflushunmaprange+0x70/0x90 [xfs] xfsfilefallocate+0xfc/0x4d8 [xfs] vfsfallocate+0x124/0x2e8 ksysfallocate+0x4c/0xa0 arm64sysfallocate+0x24/0x38 invokesyscall.constprop.0+0x7c/0xd8 doel0svc+0xb4/0xd0 el0svc+0x44/0x1d8 el0t64synchandler+0x134/0x150 el0t64sync+0x17c/0x180
Fix it by skipping to allocate PMD-sized page cache when its size is larger than MAXPAGECACHEORDER. For this specific case, we will fall to regular path where the readahead window is determined by BDI's sysfs file (readaheadkb).
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: E-switch, Create ingress ACL when needed
Currently, ingress acl is used for three features. It is created only when vport metadata match and prio tag are enabled. But active-backup lag mode also uses it. It is independent of vport metadata match and prio tag. And vport metadata match can be disabled using the following devlink command:
# devlink dev param set pci/0000:08:00.0 name eswportmetadata \ value false cmode runtime
If ingress acl is not created, will hit panic when creating drop rule for active-backup lag mode. If always create it, there will be about 5% performance degradation.
Fix it by creating ingress acl when needed. If eswportmetadata is true, ingress acl exists, then create drop rule using existing ingress acl. If eswportmetadata is false, create ingress acl and then create drop rule.
In the Linux kernel, the following vulnerability has been resolved:
mm/filemap: make MAXPAGECACHEORDER acceptable to xarray
Patch series "mm/filemap: Limit page cache size to that supported by xarray", v2.
Currently, xarray can't support arbitrary page cache size. More details can be found from the WARNON() statement in xassplitalloc(). In our test whose code is attached below, we hit the WARNON() on ARM64 system where the base page size is 64KB and huge page size is 512MB. The issue was reported long time ago and some discussions on it can be found here [1].
[1] https://www.spinics.net/lists/linux-xfs/msg75404.html
In order to fix the issue, we need to adjust MAXPAGECACHEORDER to one supported by xarray and avoid PMD-sized page cache if needed. The code changes are suggested by David Hildenbrand.
PATCH[1] adjusts MAXPAGECACHEORDER to that supported by xarray PATCH[2-3] avoids PMD-sized page cache in the synchronous readahead path PATCH[4] avoids PMD-sized page cache for shmem files if needed
Test program ============ cat test.c #define GNUSOURCE #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <string.h> #include <fcntl.h> #include <errno.h> #include <sys/syscall.h> #include <sys/mman.h>
#define TESTXFSFILENAME "/tmp/data" #define TESTSHMEMFILENAME "/dev/shm/data" #define TESTMEMSIZE 0x20000000
int main(int argc, char argv) { const char filename; int fd = 0; void buf = (void )-1, p; int pgsize = getpagesize(); int ret;
if (pgsize != 0x10000) { fprintf(stderr, "64KB base page size is required\n"); return -EPERM; }
system("echo force > /sys/kernel/mm/transparenthugepage/shmemenabled"); system("rm -fr /tmp/data"); system("rm -fr /dev/shm/data"); system("echo 1 > /proc/sys/vm/dropcaches");
/ Open xfs or shmem file / filename = TESTXFSFILENAME; if (argc > 1 && !strcmp(argv[1], "shmem")) filename = TESTSHMEMFILENAME;
fd = open(filename, OCREAT | ORDWR | OTRUNC); if (fd < 0) { fprintf(stderr, "Unable to open <%s>\n", filename); return -EIO; }
/ Extend file size / ret = ftruncate(fd, TESTMEMSIZE); if (ret) { fprintf(stderr, "Error %d to ftruncate()\n", ret); goto cleanup; }
/ Create VMA / buf = mmap(NULL, TESTMEMSIZE, PROTREAD | PROTWRITE, MAPSHARED, fd, 0); if (buf == (void )-1) { fprintf(stderr, "Unable to mmap <%s>\n", filename); goto cleanup; }
fprintf(stdout, "mapped buffer at 0x%p\n", buf); ret = madvise(buf, TESTMEMSIZE, MADVHUGEPAGE); if (ret) { fprintf(stderr, "Unable to madvise(MADVHUGEPAGE)\n"); goto cleanup; }
/ Populate VMA / ret = madvise(buf, TESTMEMSIZE, MADVPOPULATEWRITE); if (ret) { fprintf(stderr, "Error %d to madvise(MADVPOPULATEWRITE)\n", ret); goto cleanup; }
/ Punch the file to enforce xarray split / ret = fallocate(fd, FALLOCFLKEEPSIZE | FALLOCFLPUNCHHOLE, TESTMEMSIZE - pgsize, pgsize); if (ret) fprintf(stderr, "Error %d to fallocate()\n", ret);
cleanup: if (buf != (void )-1) munmap(buf, TESTMEMSIZE); if (fd > 0) close(fd);
return 0; }
gcc test.c -o test cat /proc/1/smaps | grep KernelPageSize | head -n 1 KernelPageSize: 64 kB ./test shmem : ------------[ cut here ]------------ WARNING: CPU: 17 PID: 5253 at lib/xarray.c:1025 xassplitalloc+0xf8/0x128 Modules linked in: nftfibinet nftfibipv4 nftfibipv6 nftfib \ nftrejectinet nfrejectipv4 nfrejectipv6 nftreject nftct \ nftchainnat nfnat nfconntrack nfdefragipv6 nfdefragipv4 \ ipset nftables rfkill nfnetlink vfat fat virtioballoon \ drm fuse xfs libcrc32c crct10difce ghashce sha2ce sha256arm64 \ virtionet sha1ce netfailover failover virtioconsole virtioblk \ dimlib virtiommio CPU: 17 PID: 5253 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #12 Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024 pstate: 83400005 (Nzcv daif +PAN -UAO +TC ---truncated---
bpf: Fix null pointer dereference in resolveprogtype() for BPFPROGTYPEEXT
In the Linux kernel, the following vulnerability has been resolved:
PCI: rcar: Demote WARN() to devwarnratelimited() in rcarpciewakeup()
Avoid large backtrace, it is sufficient to warn the user that there has been a link problem. Either the link has failed and the system is in need of maintenance, or the link continues to work and user has been informed. The message from the warning can be looked up in the sources.
This makes an actual link issue less verbose.
First of all, this controller has a limitation in that the controller driver has to assist the hardware with transition to L1 link state by writing L1IATN to PMCTRL register, the L1 and L0 link state switching is not fully automatic on this controller.
In case of an ASMedia ASM1062 PCIe SATA controller which does not support ASPM, on entry to suspend or during platform pmtest, the SATA controller enters D3hot state and the link enters L1 state. If the SATA controller wakes up before rcarpciewakeup() was called and returns to D0, the link returns to L0 before the controller driver even started its transition to L1 link state. At this point, the SATA controller did send an PMENTERL1 DLLP to the PCIe controller and the PCIe controller received it, and the PCIe controller did set PMSR PMEL1RX bit.
Once rcarpciewakeup() is called, if the link is already back in L0 state and PMEL1RX bit is set, the controller driver has no way to determine if it should perform the link transition to L1 state, or treat the link as if it is in L0 state. Currently the driver attempts to perform the transition to L1 link state unconditionally, which in this specific case fails with a PMSR L1FAEG poll timeout, however the link still works as it is already back in L0 state.
Reduce this warning verbosity. In case the link is really broken, the rcarpcieconfigaccess() would fail, otherwise it will succeed and any system with this controller and ASM1062 can suspend without generating a backtrace.
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Fix command stats access after free
Command may fail while driver is reloading and can't accept FW commands till command interface is reinitialized. Such command failure is being logged to command stats. This results in NULL pointer access as command stats structure is being freed and reallocated during mlx5 devlink reload (see kernel log below).
Fix it by making command stats statically allocated on driver probe.
Kernel log: [ 2394.808802] BUG: unable to handle kernel paging request at 000000000002a9c0 [ 2394.810610] PGD 0 P4D 0 [ 2394.811811] Oops: 0002 [#1] SMP NOPTI ... [ 2394.815482] RIP: 0010:nativequeuedspinlockslowpath+0x183/0x1d0 ... [ 2394.829505] Call Trace: [ 2394.830667] rawspinlockirq+0x23/0x26 [ 2394.831858] cmdstatuserr+0x55/0x110 [mlx5core] [ 2394.833020] mlx5accessreg+0xe7/0x150 [mlx5core] [ 2394.834175] mlx5queryportptys+0x78/0xa0 [mlx5core] [ 2394.835337] mlx5eethtoolgetlinkksettings+0x74/0x590 [mlx5core] [ 2394.836454] ? kmemcachealloctrace+0x140/0x1c0 [ 2394.837562] rhcallgetlinkksettings+0x33/0x100 [ 2394.838663] ? rtnlunlock+0x25/0x50 [ 2394.839755] ethtoolgetlinkksettings+0x72/0x150 [ 2394.840862] duplexshow+0x6e/0xc0 [ 2394.841963] devattrshow+0x1c/0x40 [ 2394.843048] sysfskfseqshow+0x9b/0x100 [ 2394.844123] seqread+0x153/0x410 [ 2394.845187] vfsread+0x91/0x140 [ 2394.846226] ksysread+0x4f/0xb0 [ 2394.847234] dosyscall64+0x5b/0x1a0 [ 2394.848228] entrySYSCALL64afterhwframe+0x65/0xca
In the Linux kernel, the following vulnerability has been resolved:
spi: rockchip: Resolve unbalanced runtime PM / system PM handling
Commit e882575efc77 ("spi: rockchip: Suspend and resume the bus during NOIRQSYSTEMSLEEPPM ops") stopped respecting runtime PM status and simply disabled clocks unconditionally when suspending the system. This causes problems when the device is already runtime suspended when we go to sleep -- in which case we double-disable clocks and produce a WARNing.
Switch back to pmruntimeforce{suspend,resume}(), because that still seems like the right thing to do, and the aforementioned commit makes no explanation why it stopped using it.
Also, refactor some of the resume() error handling, because it's not actually a good idea to re-disable clocks on failure.
In the Linux kernel, the following vulnerability has been resolved:
scsi: wd33c93: Don't use stale scsipointer value
A regression was introduced with commit dbb2da557a6a ("scsi: wd33c93: Move the SCSI pointer to private command data") which results in an oops in wd33c93intr(). That commit added the scsipointer variable and initialized it from hostdata->connected. However, during selection, hostdata->connected is not yet valid. Fix this by getting the current scsipointer from hostdata->selecting.
In the Linux kernel, the following vulnerability has been resolved:
net: wwan: iosm: fix memory leak in ipcmuxinit()
When failed to alloc ipcmux->uladb.ppqlt in ipcmuxinit(), ipcmux is not released.
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (asus-ec-sensors) Add checks for devmkcalloc
As the devmkcalloc may return NULL, the return value needs to be checked to avoid NULL poineter dereference.
In the Linux kernel, the following vulnerability has been resolved:
mctp i2c: handle NULL header address
daddr can be NULL if there is no neighbour table entry present, in that case the tx packet should be dropped.
saddr will usually be set by MCTP core, but check for NULL in case a packet is transmitted by a different protocol.
In the Linux kernel, the following vulnerability has been resolved:
ipv4: iptunnel: Fix suspicious RCU usage warning in iptunnelinitflow()
There are code paths from which the function is called without holding the RCU read lock, resulting in a suspicious RCU usage warning [1].
Fix by using l3mdevmasterupperifindexbyindex() which will acquire the RCU read lock before calling l3mdevmasterupperifindexbyindexrcu().
[1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!!
other info that might help us debug this:
rcuscheduleractive = 2, debuglocks = 1 1 lock held by ip/361: #0: ffffffff86fc7cb0 (rtnlmutex){+.+.}-{3:3}, at: rtnetlinkrcvmsg+0x377/0xf60
stack backtrace: CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: <TASK> dumpstacklvl+0xba/0x110 lockdeprcususpicious.cold+0x4f/0xd6 devgetbyindexrcu+0x1d3/0x210 l3mdevmasterupperifindexbyindexrcu+0x2b/0xf0 iptunnelbinddev+0x72f/0xa00 iptunnelnewlink+0x368/0x7a0 ipgrenewlink+0x14c/0x170 rtnlnewlink+0x1173/0x19c0 rtnlnewlink+0x6c/0xa0 rtnetlinkrcvmsg+0x3cc/0xf60 netlinkrcvskb+0x171/0x450 netlinkunicast+0x539/0x7f0 netlinksendmsg+0x8c1/0xd80 syssendmsg+0x8f9/0xc20 syssendmsg+0x197/0x1e0 syssendmsg+0x122/0x1f0 dosyscall64+0xbb/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f