OESA-2025-1033

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved: sh: cpuinfo: Fix a warning for CONFIGCPUMASKOFFSTACK When CONFIGCPUMASKOFFSTACK and CONFIGDEBUGPERCPUMAPS are selected, cpumaxbitswarn() generates a runtime warning similar as below when showing /proc/cpuinfo. Fix this by using nrcpuids (the runtime limit) instead of NRCPUS to iterate CPUs. [ 3.052463] ------------[ cut here ]------------ [ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 showcpuinfo+0x5e8/0x5f0 [ 3.070072] Modules linked in: efivarfs autofs4 [ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052 [ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000 [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 [ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 [ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000 [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000 [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000 [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c [ 3.195868] ... [ 3.199917] Call Trace: [ 3.203941] [<90000000002086d8>] showstack+0x38/0x14c [ 3.210666] [<9000000000cf846c>] dumpstacklvl+0x60/0x88 [ 3.217625] [<900000000023d268>] _warn+0xd0/0x100 [ 3.223958] [<9000000000cf3c90>] warnslowpathfmt+0x7c/0xcc [ 3.231150] [<9000000000210220>] showcpuinfo+0x5e8/0x5f0 [ 3.238080] [<90000000004f578c>] seqreaditer+0x354/0x4b4 [ 3.245098] [<90000000004c2e90>] newsyncread+0x17c/0x1c4 [ 3.252114] [<90000000004c5174>] vfsread+0x138/0x1d0 [ 3.258694] [<90000000004c55f8>] ksysread+0x70/0x100 [ 3.265265] [<9000000000cfde9c>] dosyscall+0x7c/0x94 [ 3.271820] [<9000000000202fe4>] handlesyscall+0xc4/0x160 [ 3.281824] ---[ end trace 8b484262b4b8c24c ]---(CVE-2022-49034)

In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/qm - inject error before stopping queue The master ooo cannot be completely closed when the accelerator core reports memory error. Therefore, the driver needs to inject the qm error to close the master ooo. Currently, the qm error is injected after stopping queue, memory may be released immediately after stopping queue, causing the device to access the released memory. Therefore, error is injected to close master ooo before stopping queue to ensure that the device does not access the released memory.(CVE-2024-47730)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using dc->clkmgr [WHY & HOW] dc->clkmgr is null checked previously in the same function, indicating it might be null. Passing "dc" to "dc->hwss.applyidlepoweroptimizations", which dereferences null "dc->clkmgr". (The function pointer resolves to "dcn35applyidlepoweroptimizations".) This fixes 1 FORWARD_NULL issue reported by Coverity.(CVE-2024-49907)

In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix error path in multi-packet WQE transmit Remove the erroneous unmap in case no DMA mapping was established The multi-packet WQE transmit code attempts to obtain a DMA mapping for the skb. This could fail, e.g. under memory pressure, when the IOMMU driver just can't allocate more memory for page tables. While the code tries to handle this in the path below the err_unmap label it erroneously unmaps one entry from the sq's FIFO list of active mappings. Since the current map attempt failed this unmap is removing some random DMA mapping that might still be required. If the PCI function now presents that IOVA, the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI function in error state. The erroneous behavior was seen in a stress-test environment that created memory pressure.(CVE-2024-50001)

In the Linux kernel, the following vulnerability has been resolved: net: phy: dp83869: fix memory corruption when enabling fiber When configuring the fiber port, the DP83869 PHY driver incorrectly calls linkmodesetbit() with a bit mask (1 << 10) rather than a bit number (10). This corrupts some other memory location -- in case of arm64 the priv pointer in the same structure. Since the advertising flags are updated from supported at the end of the function the incorrect line isn't needed at all and can be removed.(CVE-2024-50188)

In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9832: fix division by zero in ad9832calcfreqreg() In the ad9832writefrequency() function, clkgetrate() might return 0. This can lead to a division by zero when calling ad9832calcfreqreg(). The check if (fout > (clkgetrate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832writefrequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value.(CVE-2024-50233)

In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: Initialization of the dangling pointer occurring in vsk->trans During loopback communication, a dangling pointer can be created in vsk->trans, potentially leading to a Use-After-Free condition. This issue is resolved by initializing vsk->trans to NULL.(CVE-2024-50264)

In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent a potential integer overflow If the tag length is >= U32MAX - 3 then the "length + 4" addition can result in an integer overflow. Address this by splitting the decoding into several steps so that decodecb_compound4res() does not have to perform arithmetic on the unsafe length value.(CVE-2024-53146)

In the Linux kernel, the following vulnerability has been resolved: exfat: fix out-of-bounds access of directory entries In the case of the directory size is greater than or equal to the cluster size, if startclu becomes an EOF cluster(an invalid cluster) due to file system corruption, then the directory entry where ei->hintfemp.eidx hint is outside the directory, resulting in an out-of-bounds access, which may cause further file system corruption. This commit adds a check for start_clu, if it is an invalid cluster, the file or directory will be treated as empty.(CVE-2024-53147)

In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix uninitialized value in ocfs2filereaditer() Syzbot has reported the following KMSAN splat: BUG: KMSAN: uninit-value in ocfs2filereaditer+0x9a4/0xf80 ocfs2filereaditer+0x9a4/0xf80 ioread+0x8d4/0x20f0 ioread+0x3e/0xf0 ioissuesqe+0x42b/0x22c0 iowqsubmitwork+0xaf9/0xdc0 ioworkerhandlework+0xd13/0x2110 iowqworker+0x447/0x1410 retfromfork+0x6f/0x90 retfromforkasm+0x1a/0x30 Uninit was created at: _allocpagesnoprof+0x9a7/0xe00 allocpagesmpolnoprof+0x299/0x990 allocpagesnoprof+0x1bf/0x1e0 allocateslab+0x33a/0x1250 _slaballoc+0x12ef/0x35e0 kmemcacheallocbulknoprof+0x486/0x1330 _ioallocreqrefill+0x84/0x560 iosubmitsqes+0x172f/0x2f30 _sesysiouringenter+0x406/0x41c0 _x64sysiouringenter+0x11f/0x1a0 x64syscall+0x2b54/0x3ba0 dosyscall64+0xcd/0x1e0 entrySYSCALL64afterhwframe+0x77/0x7f Since an instance of 'struct kiocb' may be passed from the block layer with 'private' field uninitialized, introduce 'ocfs2iocbinitrwlocked()' and use it from where 'ocfs2dioendio()' might take care, i.e. in 'ocfs2filereaditer()' and 'ocfs2filewrite_iter()'.(CVE-2024-53155)

In the Linux kernel, the following vulnerability has been resolved: soc: qcom: geni-se: fix array underflow in geniseclktblget() This loop is supposed to break if the frequency returned from clkroundrate() is the same as on the previous iteration. However, that check doesn't make sense on the first iteration through the loop. It leads to reading before the start of these->clkperftbl[] array.(CVE-2024-53158)

In the Linux kernel, the following vulnerability has been resolved: EDAC/bluefield: Fix potential integer overflow The 64-bit argument for the "get DIMM info" SMC call consists of memctrlidx left-shifted 16 bits and OR-ed with DIMM index. With memctrlidx defined as 32-bits wide the left-shift operation truncates the upper 16 bits of information during the calculation of the SMC argument. The memctrlidx stack variable must be defined as 64-bits wide to prevent any potential integer overflow, i.e. loss of data from upper 16 bits.(CVE-2024-53161)

In the Linux kernel, the following vulnerability has been resolved: sh: intc: Fix use-after-free bug in registerintccontroller() In the error handling for this function, d is freed without ever removing it from intc_list which would lead to a use after free. To fix this, let's only add it to the list after everything has succeeded.(CVE-2024-53165)

In the Linux kernel, the following vulnerability has been resolved: NFSv4.0: Fix a use-after-free problem in the asynchronous open() Yang Erkun reports that when two threads are opening files at the same time, and are forced to abort before a reply is seen, then the call to nfsreleaseseqid() in nfs4opendatafree() can result in a use-after-free of the pointer to the defunct rpc task of the other thread. The fix is to ensure that if the RPC call is aborted before the call to nfswaitonsequence() is complete, then we must call nfsreleaseseqid() in nfs4openrelease() before the rpctask is freed.(CVE-2024-53173)

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix NULL ptr deref in cryptoaeadsetkey() Neither SMB3.0 or SMB3.02 supports encryption negotiate context, so when SMB2GLOBALCAPENCRYPTION flag is set in the negotiate response, the client uses AES-128-CCM as the default cipher. See MS-SMB2 3.3.5.4. Commit b0abcd65ec54 ("smb: client: fix UAF in async decryption") added a @server->ciphertype check to conditionally call smb3cryptoaeadallocate(), but that check would always be false as @server->ciphertype is unset for SMB3.02. Fix the following KASAN splat by setting @server->ciphertype for SMB3.02 as well. mount.cifs //srv/share /mnt -o vers=3.02,seal,... BUG: KASAN: null-ptr-deref in cryptoaeadsetkey+0x2c/0x130 Read of size 8 at addr 0000000000000020 by task mount.cifs/1095 CPU: 1 UID: 0 PID: 1095 Comm: mount.cifs Not tainted 6.12.0 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x5d/0x80 ? cryptoaeadsetkey+0x2c/0x130 kasanreport+0xda/0x110 ? cryptoaeadsetkey+0x2c/0x130 cryptoaeadsetkey+0x2c/0x130 cryptmessage+0x258/0xec0 [cifs] ? asanmemset+0x23/0x50 ? _pfxcryptmessage+0x10/0x10 [cifs] ? marklock+0xb0/0x6a0 ? hlockclass+0x32/0xb0 ? marklock+0xb0/0x6a0 smb3inittransformrq+0x352/0x3f0 [cifs] ? lockacquire.part.0+0xf4/0x2a0 smbsendrqst+0x144/0x230 [cifs] ? _pfxsmbsendrqst+0x10/0x10 [cifs] ? hlockclass+0x32/0xb0 ? smb2setuprequest+0x225/0x3a0 [cifs] ? _pfxcifscompoundlastcallback+0x10/0x10 [cifs] compoundsendrecv+0x59b/0x1140 [cifs] ? _pfxcompoundsendrecv+0x10/0x10 [cifs] ? _createobject+0x5e/0x90 ? hlockclass+0x32/0xb0 ? dorawspinunlock+0x9a/0xf0 cifssendrecv+0x23/0x30 [cifs] SMB2tcon+0x3ec/0xb30 [cifs] ? _pfxSMB2tcon+0x10/0x10 [cifs] ? lockacquire.part.0+0xf4/0x2a0 ? _pfxlockrelease+0x10/0x10 ? dorawspintrylock+0xc6/0x120 ? lockacquire+0x3f/0x90 ? getxid+0x16/0xd0 [cifs] ? _pfxSMB2tcon+0x10/0x10 [cifs] ? cifsgetsmbses+0xcdd/0x10a0 [cifs] cifsgetsmbses+0xcdd/0x10a0 [cifs] ? _pfxcifsgetsmbses+0x10/0x10 [cifs] ? cifsgettcpsession+0xaa0/0xca0 [cifs] cifsmountgetsession+0x8a/0x210 [cifs] dfsmountshare+0x1b0/0x11d0 [cifs] ? _pfxlockacquire+0x10/0x10 ? pfxdfsmountshare+0x10/0x10 [cifs] ? lockacquire.part.0+0xf4/0x2a0 ? findheldlock+0x8a/0xa0 ? hlockclass+0x32/0xb0 ? lockrelease+0x203/0x5d0 cifsmount+0xb3/0x3d0 [cifs] ? dorawspintrylock+0xc6/0x120 ? _pfxcifsmount+0x10/0x10 [cifs] ? lockacquire+0x3f/0x90 ? findnls+0x16/0xa0 ? smb3updatemntflags+0x372/0x3b0 [cifs] cifssmb3domount+0x1e2/0xc80 [cifs] ? _pfxvfsparsefsstring+0x10/0x10 ? _pfxcifssmb3domount+0x10/0x10 [cifs] smb3gettree+0x1bf/0x330 [cifs] vfsgettree+0x4a/0x160 pathmount+0x3c1/0xfb0 ? kasanquarantineput+0xc7/0x1d0 ? _pfxpathmount+0x10/0x10 ? kmemcachefree+0x118/0x3e0 ? userpathat+0x74/0xa0 _x64sysmount+0x1a6/0x1e0 ? _pfxx64sysmount+0x10/0x10 ? markheldlocks+0x1a/0x90 dosyscall64+0xbb/0x1d0 entrySYSCALL64after_hwframe+0x77/0x7f(CVE-2024-53185)

In the Linux kernel, the following vulnerability has been resolved: iouring: check for overflows in iopinpages WARNING: CPU: 0 PID: 5834 at iouring/memmap.c:144 iopinpages+0x149/0x180 iouring/memmap.c:144 CPU: 0 UID: 0 PID: 5834 Comm: syz-executor825 Not tainted 6.12.0-next-20241118-syzkaller #0 Call Trace: <TASK> _iouaddrmap+0xfb/0x2d0 iouring/memmap.c:183 ioringsmap iouring/iouring.c:2611 [inline] ioallocatescqurings+0x1c0/0x650 iouring/iouring.c:3470 iouringcreate+0x5b5/0xc00 iouring/iouring.c:3692 iouringsetup iouring/iouring.c:3781 [inline] ... </TASK> iopinpages()'s uaddr parameter came directly from the user and can be garbage. Don't just add size to it as it can overflow.(CVE-2024-53187)

In the Linux kernel, the following vulnerability has been resolved: PCI: Fix use-after-free of slot->bus on hot remove Dennis reports a boot crash on recent Lenovo laptops with a USB4 dock. Since commit 0fc70886569c ("thunderbolt: Reset USB4 v2 host router") and commit 59a54c5f3dbd ("thunderbolt: Reset topology created by the boot firmware"), USB4 v2 and v1 Host Routers are reset on probe of the thunderbolt driver. The reset clears the Presence Detect State and Data Link Layer Link Active bits at the USB4 Host Router's Root Port and thus causes hot removal of the dock. The crash occurs when pciehp is unbound from one of the dock's Downstream Ports: pciehp creates a pcislot on bind and destroys it on unbind. The pcislot contains a pointer to the pcibus below the Downstream Port, but a reference on that pcibus is never acquired. The pcibus is destroyed before the pcislot, so a use-after-free ensues when pcislotrelease() accesses slot->bus. In principle this should not happen because pcistopbusdevice() unbinds pciehp (and therefore destroys the pcislot) before the pcibus is destroyed by pciremovebusdevice(). However the stacktrace provided by Dennis shows that pciehp is unbound from pciremovebusdevice() instead of pcistopbusdevice(). To understand the significance of this, one needs to know that the PCI core uses a two step process to remove a portion of the hierarchy: It first unbinds all drivers in the sub-hierarchy in pcistopbusdevice() and then actually removes the devices in pciremovebusdevice(). There is no precaution to prevent driver binding in-between pcistopbusdevice() and pciremovebusdevice(). In Dennis' case, it seems removal of the hierarchy by pciehp races with driver binding by pcibusadddevices(). pciehp is bound to the Downstream Port after pcistopbusdevice() has run, so it is unbound by pciremovebusdevice() instead of pcistopbusdevice(). Because the pcibus has already been destroyed at that point, accesses to it result in a use-after-free. One might conclude that driver binding needs to be prevented after pcistopbusdevice() has run. However it seems risky that pcislot points to pcibus without holding a reference. Solely relying on correct ordering of driver unbind versus pcibus destruction is certainly not defensive programming. If pcislot has a need to access data in pcibus, it ought to acquire a reference. Amend pcicreateslot() accordingly. Dennis reports that the crash is not reproducible with this change. Abridged stacktrace: pcieport 0000:00:07.0: PME: Signaling with IRQ 156 pcieport 0000:00:07.0: pciehp: Slot #12 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+ pcibus 0000:20: dev 00, created physical slot 12 pcieport 0000:00:07.0: pciehp: Slot(12): Card not present ... pcieport 0000:21:02.0: pciehp: pciedisablenotification: SLOTCTRL d8 write cmd 0 Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI CPU: 13 UID: 0 PID: 134 Comm: irq/156-pciehp Not tainted 6.11.0-devel+ #1 RIP: 0010:devdriverstring+0x12/0x40 pcidestroyslot pciehpremove pcieportremoveservice devicereleasedriverinternal busremovedevice devicedel deviceunregister removeiter deviceforeachchild pcieportdrvremove pcideviceremove devicereleasedriverinternal busremovedevice devicedel pciremovebusdevice (recursive invocation) pciremovebusdevice pciehpunconfiguredevice pciehpdisableslot pciehphandlepresenceorlinkchange pciehp_ist(CVE-2024-53194)

In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devices A bogus device can provide a bNumConfigurations value that exceeds the initial value used in usbgetconfiguration for allocating dev->config. This can lead to out-of-bounds accesses later, e.g. in usbdestroyconfiguration.(CVE-2024-53197)

In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent NULL dereference in nfsd4processcbupdate() @ses is initialized to NULL. If _nfsd4findbackchannel() finds no available backchannel session, setupcallbackclient() will try to dereference @ses and segfault.(CVE-2024-53217)

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix race in concurrent f2fsstopgcthread In my test case, concurrent calls to f2fs shutdown report the following stack trace: Oops: general protection fault, probably for non-canonical address 0xc6cfff63bb5513fc: 0000 [#1] PREEMPT SMP PTI CPU: 0 UID: 0 PID: 678 Comm: f2fsrepshutdo Not tainted 6.12.0-rc5-next-20241029-g6fb2fa9805c5-dirty #85 Call Trace: <TASK> ? showregs+0x8b/0xa0 ? _diebody+0x26/0xa0 ? dieaddr+0x54/0x90 ? excgeneralprotection+0x24b/0x5c0 ? asmexcgeneralprotection+0x26/0x30 ? kthreadstop+0x46/0x390 f2fsstopgcthread+0x6c/0x110 f2fsdoshutdown+0x309/0x3a0 f2fsiocshutdown+0x150/0x1c0 _f2fsioctl+0xffd/0x2ac0 f2fsioctl+0x76/0xe0 vfsioctl+0x23/0x60 _x64sysioctl+0xce/0xf0 x64syscall+0x2b1b/0x4540 dosyscall64+0xa7/0x240 entrySYSCALL64afterhwframe+0x76/0x7e The root cause is a race condition in f2fsstopgcthread() called from different f2fs shutdown paths: [CPU0] [CPU1] ---------------------- ----------------------- f2fsstopgcthread f2fsstopgcthread gcth = sbi->gcthread gcth = sbi->gcthread kfree(gcth) sbi->gcthread = NULL < gcth != NULL > kthreadstop(gcth->f2fsgctask) //UAF The commit c7f114d864ac ("f2fs: fix to avoid use-after-free in f2fsstopgcthread()") attempted to fix this issue by using a read semaphore to prevent races between shutdown and remount threads, but it fails to prevent all race conditions. Fix it by converting to write lock of sumount in f2fsdo_shutdown().(CVE-2024-53218)

In the Linux kernel, the following vulnerability has been resolved: virtiofs: use pages instead of pointer for kernel direct IO When trying to insert a 10MB kernel module kept in a virtio-fs with cache disabled, the following warning was reported: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 404 at mm/pagealloc.c:4551 ...... Modules linked in: CPU: 1 PID: 404 Comm: insmod Not tainted 6.9.0-rc5+ #123 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...... RIP: 0010:allocpages+0x2bf/0x380 ...... Call Trace: <TASK> ? _warn+0x8e/0x150 ? _allocpages+0x2bf/0x380 _kmalloclargenode+0x86/0x160 _kmalloc+0x33c/0x480 virtiofsenqueuereq+0x240/0x6d0 virtiofswakependingandunlock+0x7f/0x190 queuerequestandunlock+0x55/0x60 fusesimplerequest+0x152/0x2b0 fusedirectio+0x5d2/0x8c0 fusefilereaditer+0x121/0x160 _kernelread+0x151/0x2d0 kernelread+0x45/0x50 kernelreadfile+0x1a9/0x2a0 initmodulefromfile+0x6a/0xe0 idempotentinitmodule+0x175/0x230 _x64sysfinitmodule+0x5d/0xb0 x64syscall+0x1c3/0x9e0 dosyscall64+0x3d/0xc0 entrySYSCALL64afterhwframe+0x4b/0x53 ...... </TASK> ---[ end trace 0000000000000000 ]--- The warning is triggered as follows: 1) syscall finitmodule() handles the module insertion and it invokes kernelreadfile() to read the content of the module first. 2) kernelreadfile() allocates a 10MB buffer by using vmalloc() and passes it to kernelread(). kernelread() constructs a kvec iter by using ioviterkvec() and passes it to fusefilereaditer(). 3) virtio-fs disables the cache, so fusefilereaditer() invokes fusedirectio(). As for now, the maximal read size for kvec iter is only limited by fc->maxread. For virtio-fs, maxread is UINTMAX, so fusedirectio() doesn't split the 10MB buffer. It saves the address and the size of the 10MB-sized buffer in outargs[0] of a fuse request and passes the fuse request to virtiofswakependingandunlock(). 4) virtiofswakependingandunlock() uses virtiofsenqueuereq() to queue the request. Because virtiofs need DMA-able address, so virtiofsenqueuereq() uses kmalloc() to allocate a bounce buffer for all fuse args, copies these args into the bounce buffer and passed the physical address of the bounce buffer to virtiofsd. The total length of these fuse args for the passed fuse request is about 10MB, so copyargstoargbuf() invokes kmalloc() with a 10MB size parameter and it triggers the warning in _allocpages(): if (WARNONONCEGFP(order > MAXPAGEORDER, gfp)) return NULL; 5) virtiofsenqueuereq() will retry the memory allocation in a kworker, but it won't help, because kmalloc() will always return NULL due to the abnormal size and finitmodule() will hang forever. A feasible solution is to limit the value of maxread for virtio-fs, so the length passed to kmalloc() will be limited. However it will affect the maximal read size for normal read. And for virtio-fs write initiated from kernel, it has the similar problem but now there is no way to limit fc->maxwrite in kernel. So instead of limiting both the values of maxread and maxwrite in kernel, introducing usepagesforkvecio in fuseconn and setting it as true in virtiofs. When usepagesforkvecio is enabled, fuse will use pages instead of pointer to pass the KVECIO data. After switching to pages for KVECIO data, these pages will be used for DMA through virtio-fs. If these pages are backed by vmalloc(), {flush|invalidate}kernelvmaprange() are necessary to flush or invalidate the cache before the DMA operation. So add two new fields in fuseargspages to record the base address of vmalloc area and the condition indicating whether invalidation is needed. Perform the flush in fusegetuserpages() for write operations and the invalidation in fusereleaseuserpages() for read operations. It may seem necessary to introduce another fie ---truncated---(CVE-2024-53219)

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix null-ptr-deref in f2fssubmitpagebio() There's issue as follows when concurrently installing the f2fs.ko module and mounting the f2fs file system: KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] RIP: 0010:bioalloc+0x2fb/0x6c0 [f2fs] Call Trace: <TASK> f2fssubmitpagebio+0x126/0x8b0 [f2fs] _getmetapage+0x1d4/0x920 [f2fs] getcheckpointversion.constprop.0+0x2b/0x3c0 [f2fs] validatecheckpoint+0xac/0x290 [f2fs] f2fsgetvalidcheckpoint+0x207/0x950 [f2fs] f2fsfillsuper+0x1007/0x39b0 [f2fs] mountbdev+0x183/0x250 legacygettree+0xf4/0x1e0 vfsgettree+0x88/0x340 donewmount+0x283/0x5e0 pathmount+0x2b2/0x15b0 _x64sysmount+0x1fe/0x270 dosyscall64+0x5f/0x170 entrySYSCALL64afterhwframe+0x76/0x7e Above issue happens as the biset of the f2fs file system is not initialized before register "f2fsfstype". To address above issue just register "f2fsfstype" at the last in initf2fs_fs(). Ensure that all f2fs file system resources are initialized.(CVE-2024-53221)

In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Move events notifier registration to be after device registration Move pkey change work initialization and cleanup from device resources stage to notifier stage, since this is the stage which handles this work events. Fix a race between the device deregistration and pkey change work by moving MLX5IBSTAGEDEVICENOTIFIER to be after MLX5IBSTAGEIBREG in order to ensure that the notifier is deregistered before the device during cleanup. Which ensures there are no works that are being executed after the device has already unregistered which can cause the panic below. BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 630071 Comm: kworker/1:2 Kdump: loaded Tainted: G W OE --------- --- 5.14.0-162.6.1.el91.x8664 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008 02/27/2023 Workqueue: events pkeychangehandler [mlx5ib] RIP: 0010:setupqp+0x38/0x1f0 [mlx5ib] Code: ee 41 54 45 31 e4 55 89 f5 53 48 89 fb 48 83 ec 20 8b 77 08 65 48 8b 04 25 28 00 00 00 48 89 44 24 18 48 8b 07 48 8d 4c 24 16 <4c> 8b 38 49 8b 87 80 0b 00 00 4c 89 ff 48 8b 80 08 05 00 00 8b 40 RSP: 0018:ffffbcc54068be20 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff954054494128 RCX: ffffbcc54068be36 RDX: ffff954004934000 RSI: 0000000000000001 RDI: ffff954054494128 RBP: 0000000000000023 R08: ffff954001be2c20 R09: 0000000000000001 R10: ffff954001be2c20 R11: ffff9540260133c0 R12: 0000000000000000 R13: 0000000000000023 R14: 0000000000000000 R15: ffff9540ffcb0905 FS: 0000000000000000(0000) GS:ffff9540ffc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010625c001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: mlx5ibgsipkeychange+0x20/0x40 [mlx5ib] processonework+0x1e8/0x3c0 workerthread+0x50/0x3b0 ? rescuerthread+0x380/0x380 kthread+0x149/0x170 ? setkthreadstruct+0x50/0x50 retfromfork+0x22/0x30 Modules linked in: rdmaucm(OE) rdmacm(OE) iwcm(OE) ibipoib(OE) ibcm(OE) ibumad(OE) mlx5ib(OE) mlx5fwctl(OE) fwctl(OE) ibuverbs(OE) mlx5core(OE) mlxdevm(OE) ibcore(OE) mlxcompat(OE) psample mlxfw(OE) tls knem(OE) netconsole nfsv3 nfsacl nfs lockd grace fscache netfs qrtr rfkill sunrpc intelraplmsr intelraplcommon rapl hvballoon hvutils i2cpiix4 pcspkr joydev fuse ext4 mbcache jbd2 srmod sdmod cdrom t10pi sg atageneric pcihyperv pcihypervintf hypervdrm drmshmemhelper drmkmshelper hvstorvsc syscopyarea hvnetvsc sysfillrect sysimgblt hidhyperv fbsysfops scsitransportfc hypervkeyboard drm atapiix crct10difpclmul crc32pclmul crc32cintel libata ghashclmulniintel hvvmbus serioraw [last unloaded: ib_core] CR2: 0000000000000000 ---[ end trace f6f8be4eae12f7bc ]---(CVE-2024-53224)

In the Linux kernel, the following vulnerability has been resolved: scsi: bfa: Fix use-after-free in bfadimmoduleexit() BUG: KASAN: slab-use-after-free in _lockacquire+0x2aca/0x3a20 Read of size 8 at addr ffff8881082d80c8 by task modprobe/25303 Call Trace: <TASK> dumpstacklvl+0x95/0xe0 printreport+0xcb/0x620 kasanreport+0xbd/0xf0 _lockacquire+0x2aca/0x3a20 lockacquire+0x19b/0x520 rawspinlock+0x2b/0x40 attributecontainerunregister+0x30/0x160 fcreleasetransport+0x19/0x90 [scsitransportfc] bfadimmoduleexit+0x23/0x60 [bfa] bfadinit+0xdb/0xff0 [bfa] dooneinitcall+0xdc/0x550 doinitmodule+0x22d/0x6b0 loadmodule+0x4e96/0x5ff0 initmodulefromfile+0xcd/0x130 idempotentinitmodule+0x330/0x620 _x64sysfinitmodule+0xb3/0x110 dosyscall64+0xc1/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f </TASK> Allocated by task 25303: kasansavestack+0x24/0x50 kasansavetrack+0x14/0x30 _kasankmalloc+0x7f/0x90 fcattachtransport+0x4f/0x4740 [scsitransportfc] bfadimmoduleinit+0x17/0x80 [bfa] bfadinit+0x23/0xff0 [bfa] dooneinitcall+0xdc/0x550 doinitmodule+0x22d/0x6b0 loadmodule+0x4e96/0x5ff0 initmodulefromfile+0xcd/0x130 idempotentinitmodule+0x330/0x620 _x64sysfinitmodule+0xb3/0x110 dosyscall64+0xc1/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f Freed by task 25303: kasansavestack+0x24/0x50 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3b/0x60 _kasanslabfree+0x38/0x50 kfree+0x212/0x480 bfadimmoduleinit+0x7e/0x80 [bfa] bfadinit+0x23/0xff0 [bfa] dooneinitcall+0xdc/0x550 doinitmodule+0x22d/0x6b0 loadmodule+0x4e96/0x5ff0 initmodulefromfile+0xcd/0x130 idempotentinitmodule+0x330/0x620 _x64sysfinitmodule+0xb3/0x110 dosyscall64+0xc1/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f Above issue happens as follows: bfadinit error = bfadimmoduleinit() fcreleasetransport(bfadimscsitransporttemplate); if (error) goto ext; ext: bfadimmoduleexit(); fcreleasetransport(bfadimscsitransporttemplate); --> Trigger double release Don't call bfadimmoduleexit() if bfadimmoduleinit() failed.(CVE-2024-53227)

In the Linux kernel, the following vulnerability has been resolved: drm: zynqmp_kms: Unplug DRM device before removal Prevent userspace accesses to the DRM device from causing use-after-frees by unplugging the device before we remove it. This causes any further userspace accesses to result in an error without further calls into this driver's internals.(CVE-2024-56538)

In the Linux kernel, the following vulnerability has been resolved: hfsplus: don't query the device logical block size multiple times Devices block sizes may change. One of these cases is a loop device by using ioctl LOOPSETBLOCKSIZE. While this may cause other issues like IO being rejected, in the case of hfsplus, it will allocate a block by using that size and potentially write out-of-bounds when hfsplusreadwrapper calls hfsplussubmitbio and the latter function reads a different iosize. Using a new miniosize initally set to sbminblocksize works for the purposes of the original fix, since it will be set to the max between HFSPLUSSECTORSIZE and the first seen logical block size. We still use the max between HFSPLUSSECTORSIZE and miniosize in case the latter is not initialized. Tested by mounting an hfsplus filesystem with loop block sizes 512, 1024 and 4096. The produced KASAN report before the fix looks like this: [ 419.944641] ================================================================== [ 419.945655] BUG: KASAN: slab-use-after-free in hfsplusreadwrapper+0x659/0xa0a [ 419.946703] Read of size 2 at addr ffff88800721fc00 by task repro/10678 [ 419.947612] [ 419.947846] CPU: 0 UID: 0 PID: 10678 Comm: repro Not tainted 6.12.0-rc5-00008-gdf56e0f2f3ca #84 [ 419.949007] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 419.950035] Call Trace: [ 419.950384] <TASK> [ 419.950676] dumpstacklvl+0x57/0x78 [ 419.951212] ? hfsplusreadwrapper+0x659/0xa0a [ 419.951830] printreport+0x14c/0x49e [ 419.952361] ? _virtaddrvalid+0x267/0x278 [ 419.952979] ? kmemcachedebugflags+0xc/0x1d [ 419.953561] ? hfsplusreadwrapper+0x659/0xa0a [ 419.954231] kasanreport+0x89/0xb0 [ 419.954748] ? hfsplusreadwrapper+0x659/0xa0a [ 419.955367] hfsplusreadwrapper+0x659/0xa0a [ 419.955948] ? _pfxhfsplusreadwrapper+0x10/0x10 [ 419.956618] ? dorawspinunlock+0x59/0x1a9 [ 419.957214] ? _rawspinunlock+0x1a/0x2e [ 419.957772] hfsplusfillsuper+0x348/0x1590 [ 419.958355] ? hlockclass+0x4c/0x109 [ 419.958867] ? _pfxhfsplusfillsuper+0x10/0x10 [ 419.959499] ? _pfxstring+0x10/0x10 [ 419.960006] ? lockacquire+0x3e2/0x454 [ 419.960532] ? bdevname.constprop.0+0xce/0x243 [ 419.961129] ? _pfxbdevname.constprop.0+0x10/0x10 [ 419.961799] ? pointer+0x3f0/0x62f [ 419.962277] ? _pfxpointer+0x10/0x10 [ 419.962761] ? vsnprintf+0x6c4/0xfba [ 419.963178] ? _pfxvsnprintf+0x10/0x10 [ 419.963621] ? setupbdevsuper+0x376/0x3b3 [ 419.964029] ? snprintf+0x9d/0xd2 [ 419.964344] ? _pfxsnprintf+0x10/0x10 [ 419.964675] ? lockacquired+0x45c/0x5e9 [ 419.965016] ? setblocksize+0x139/0x1c1 [ 419.965381] ? sbsetblocksize+0x6d/0xae [ 419.965742] ? _pfxhfsplusfillsuper+0x10/0x10 [ 419.966179] mountbdev+0x12f/0x1bf [ 419.966512] ? _pfxmountbdev+0x10/0x10 [ 419.966886] ? vfsparsefsstring+0xce/0x111 [ 419.967293] ? _pfxvfsparsefsstring+0x10/0x10 [ 419.967702] ? _pfxhfsplusmount+0x10/0x10 [ 419.968073] legacygettree+0x104/0x178 [ 419.968414] vfsgettree+0x86/0x296 [ 419.968751] pathmount+0xba3/0xd0b [ 419.969157] ? _pfxpathmount+0x10/0x10 [ 419.969594] ? kmemcachefree+0x1e2/0x260 [ 419.970311] domount+0x99/0xe0 [ 419.970630] ? _pfxdomount+0x10/0x10 [ 419.971008] _dosysmount+0x199/0x1c9 [ 419.971397] dosyscall64+0xd0/0x135 [ 419.971761] entrySYSCALL64afterhwframe+0x76/0x7e [ 419.972233] RIP: 0033:0x7c3cb812972e [ 419.972564] Code: 48 8b 0d f5 46 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c2 46 0d 00 f7 d8 64 89 01 48 [ 419.974371] RSP: 002b:00007ffe30632548 EFLAGS: 00000286 ORIGRAX: 00000000000000a5 [ 419.975048] RAX: ffffffffffffffda RBX: 00007ffe306328d8 RCX: 00007c3cb812972e [ 419.975701] RDX: 0000000020000000 RSI: 0000000020000c80 RDI: ---truncated---(CVE-2024-56548)

In the Linux kernel, the following vulnerability has been resolved: i3c: master: Fix miss free initdynaddr at i3cmasterputi3caddrs() if (dev->boardinfo && dev->boardinfo->initdynaddr) ^^^ here check "initdynaddr" i3cbussetaddrslotstatus(&master->bus, dev->info.dynaddr, ...) ^^^^ free "dynaddr" Fix copy/paste error "dynaddr" by replacing it with "initdynaddr".(CVE-2024-56562)

In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix regression with module command in stacktracefilter When executing the following command: # echo "write*:mod:ext3" > /sys/kernel/tracing/stacktracefilter The current mod command causes a null pointer dereference. While commit 0f17976568b3f ("ftrace: Fix regression with module command in stacktracefilter") has addressed part of the issue, it left a corner case unhandled, which still results in a kernel crash.(CVE-2024-56569)

In the Linux kernel, the following vulnerability has been resolved: ovl: Filter invalid inodes with missing lookup function Add a check to the ovldentryweird() function to prevent the processing of directory inodes that lack the lookup function. This is important because such inodes can cause errors in overlayfs when passed to the lowerstack.(CVE-2024-56570)

In the Linux kernel, the following vulnerability has been resolved: media: platform: allegro-dvt: Fix possible memory leak in allocatebuffersinternal() The buffer in the loop should be released under the exception path, otherwise there may be a memory leak here. To mitigate this, free the buffer when allegroallocbuffer fails.(CVE-2024-56572)

In the Linux kernel, the following vulnerability has been resolved: btrfs: ref-verify: fix use-after-free after invalid ref action At btrfsreftreemod() after we successfully inserted the new ref entry (local variable 'ref') into the respective block entry's rbtree (local variable 'be'), if we find an unexpected action of BTRFSDROPDELAYEDREF, we error out and free the ref entry without removing it from the block entry's rbtree. Then in the error path of btrfsreftreemod() we call btrfsfreerefcache(), which iterates over all block entries and then calls freeblockentry() for each one, and there we will trigger a use-after-free when we are called against the block entry to which we added the freed ref entry to its rbtree, since the rbtree still points to the block entry, as we didn't remove it from the rbtree before freeing it in the error path at btrfsreftreemod(). Fix this by removing the new ref entry from the rbtree before freeing it. Syzbot report this with the following stack traces: BTRFS error (device loop0 state EA): Ref action 2, root 5, refroot 0, parent 8564736, owner 0, offset 0, numrefs 18446744073709551615 _btrfsmodref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523 updaterefforcow+0x9cd/0x11f0 fs/btrfs/ctree.c:512 btrfsforcecowblock+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfscowblock+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfssearchslot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfsinsertemptyitems+0x9c/0x1a0 fs/btrfs/ctree.c:4314 btrfsinsertemptyitem fs/btrfs/ctree.h:669 [inline] btrfsinsertorphanitem+0x1f1/0x320 fs/btrfs/orphan.c:23 btrfsorphanadd+0x6d/0x1a0 fs/btrfs/inode.c:3482 btrfsunlink+0x267/0x350 fs/btrfs/inode.c:4293 vfsunlink+0x365/0x650 fs/namei.c:4469 dounlinkat+0x4ae/0x830 fs/namei.c:4533 _dosysunlinkat fs/namei.c:4576 [inline] _sesysunlinkat fs/namei.c:4569 [inline] _x64sysunlinkat+0xcc/0xf0 fs/namei.c:4569 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f BTRFS error (device loop0 state EA): Ref action 1, root 5, refroot 5, parent 0, owner 260, offset 0, numrefs 1 _btrfsmodref+0x76b/0xac0 fs/btrfs/extent-tree.c:2521 updaterefforcow+0x96a/0x11f0 btrfsforcecowblock+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfscowblock+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfssearchslot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfslookupinode+0xdc/0x480 fs/btrfs/inode-item.c:411 _btrfsupdatedelayedinode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030 btrfsupdatedelayedinode fs/btrfs/delayed-inode.c:1114 [inline] _btrfscommitinodedelayeditems+0x2318/0x24a0 fs/btrfs/delayed-inode.c:1137 _btrfsrundelayeditems+0x213/0x490 fs/btrfs/delayed-inode.c:1171 btrfscommittransaction+0x8a8/0x3740 fs/btrfs/transaction.c:2313 preparetorelocate+0x3c4/0x4c0 fs/btrfs/relocation.c:3586 relocateblockgroup+0x16c/0xd40 fs/btrfs/relocation.c:3611 btrfsrelocateblockgroup+0x77d/0xd90 fs/btrfs/relocation.c:4081 btrfsrelocatechunk+0x12c/0x3b0 fs/btrfs/volumes.c:3377 _btrfsbalance+0x1b0f/0x26b0 fs/btrfs/volumes.c:4161 btrfsbalance+0xbdc/0x10c0 fs/btrfs/volumes.c:4538 BTRFS error (device loop0 state EA): Ref action 2, root 5, refroot 0, parent 8564736, owner 0, offset 0, numrefs 18446744073709551615 _btrfsmodref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523 updaterefforcow+0x9cd/0x11f0 fs/btrfs/ctree.c:512 btrfsforcecowblock+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfscowblock+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfssearchslot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfslookupinode+0xdc/0x480 fs/btrfs/inode-item.c:411 _btrfsupdatedelayedinode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030 btrfsupdatedelayedi ---truncated---(CVE-2024-56581)

In the Linux kernel, the following vulnerability has been resolved: sched/deadline: Fix warning in migrateenable for boosted tasks When running the following command: while true; do stress-ng --cyclic 30 --timeout 30s --minimize --quiet done a warning is eventually triggered: WARNING: CPU: 43 PID: 2848 at kernel/sched/deadline.c:794 setupnewdlentity+0x13e/0x180 ... Call Trace: <TASK> ? showtraceloglvl+0x1c4/0x2df ? enqueuedlentity+0x631/0x6e0 ? setupnewdlentity+0x13e/0x180 ? _warn+0x7e/0xd0 ? reportbug+0x11a/0x1a0 ? handlebug+0x3c/0x70 ? excinvalidop+0x14/0x70 ? asmexcinvalidop+0x16/0x20 enqueuedlentity+0x631/0x6e0 enqueuetaskdl+0x7d/0x120 _dosetcpusallowed+0xe3/0x280 _setcpusallowedptrlocked+0x140/0x1d0 _setcpusallowedptr+0x54/0xa0 migrateenable+0x7e/0x150 rtspinunlock+0x1c/0x90 groupsendsiginfo+0xf7/0x1a0 ? killpidinfo+0x1f/0x1d0 killpidinfo+0x78/0x1d0 killprocinfo+0x5b/0x110 _x64syskill+0x93/0xc0 dosyscall64+0x5c/0xf0 entrySYSCALL64afterhwframe+0x6e/0x76 RIP: 0033:0x7f0dab31f92b This warning occurs because setcpusallowed dequeues and enqueues tasks with the ENQUEUERESTORE flag set. If the task is boosted, the warning is triggered. A boosted task already had its parameters set by rtmutexsetprio, and a new call to setupnewdlentity is unnecessary, hence the WARNON call. Check if we are requeueing a boosted task and avoid calling setupnewdlentity if that's the case.(CVE-2024-56583)

In the Linux kernel, the following vulnerability has been resolved: iouring/tctx: work around xastore() allocation error issue syzbot triggered the following WARNON: WARNING: CPU: 0 PID: 16 at iouring/tctx.c:51 _iouringfree+0xfa/0x140 iouring/tctx.c:51 which is the WARNONONCE(!xaempty(&tctx->xa)); sanity check in _iouringfree() when a iouringtask is going through its final put. The syzbot test case includes injecting memory allocation failures, and it very much looks like xastore() can fail one of its memory allocations and end up with ->head being non-NULL even though no entries exist in the xarray. Until this issue gets sorted out, work around it by attempting to iterate entries in our xarray, and WARNON_ONCE() if one is found.(CVE-2024-56584)

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix f2fsbugon when uninstalling filesystem call f2fsevictinode. creating a large files during checkpoint disable until it runs out of space and then delete it, then remount to enable checkpoint again, and then unmount the filesystem triggers the f2fsbugon as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/inode.c:896! CPU: 2 UID: 0 PID: 1286 Comm: umount Not tainted 6.11.0-rc7-dirty #360 Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:f2fsevictinode+0x58c/0x610 Call Trace: _diebody+0x15/0x60 die+0x33/0x50 dotrap+0x10a/0x120 f2fsevictinode+0x58c/0x610 doerrortrap+0x60/0x80 f2fsevictinode+0x58c/0x610 excinvalidop+0x53/0x60 f2fsevictinode+0x58c/0x610 asmexcinvalidop+0x16/0x20 f2fsevictinode+0x58c/0x610 evict+0x101/0x260 disposelist+0x30/0x50 evictinodes+0x140/0x190 genericshutdownsuper+0x2f/0x150 killblocksuper+0x11/0x40 killf2fssuper+0x7d/0x140 deactivatelockedsuper+0x2a/0x70 cleanupmnt+0xb3/0x140 taskworkrun+0x61/0x90 The root cause is: creating large files during disable checkpoint period results in not enough free segments, so when writing back root inode will failed in f2fsenablecheckpoint. When umount the file system after enabling checkpoint, the root inode is dirty in f2fsevictinode function, which triggers BUGON. The steps to reproduce are as follows: dd if=/dev/zero of=f2fs.img bs=1M count=55 mount f2fs.img f2fsdir -o checkpoint=disable:10% dd if=/dev/zero of=big bs=1M count=50 sync rm big mount -o remount,checkpoint=enable f2fsdir umount f2fs_dir Let's redirty inode when there is not free segments during checkpoint is disable.(CVE-2024-56586)

In the Linux kernel, the following vulnerability has been resolved: scsi: hisisas: Add condresched() for no forced preemption model For no forced preemption model kernel, in the scenario where the expander is connected to 12 high performance SAS SSDs, the following call trace may occur: [ 214.409199][ C240] watchdog: BUG: soft lockup - CPU#240 stuck for 22s! [irq/149-hisisa:3211] [ 214.568533][ C240] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--) [ 214.575224][ C240] pc : fputmany+0x8c/0xdc [ 214.579480][ C240] lr : fput+0x1c/0xf0 [ 214.583302][ C240] sp : ffff80002de2b900 [ 214.587298][ C240] x29: ffff80002de2b900 x28: ffff1082aa412000 [ 214.593291][ C240] x27: ffff3062a0348c08 x26: ffff80003a9f6000 [ 214.599284][ C240] x25: ffff1062bbac5c40 x24: 0000000000001000 [ 214.605277][ C240] x23: 000000000000000a x22: 0000000000000001 [ 214.611270][ C240] x21: 0000000000001000 x20: 0000000000000000 [ 214.617262][ C240] x19: ffff3062a41ae580 x18: 0000000000010000 [ 214.623255][ C240] x17: 0000000000000001 x16: ffffdb3a6efe5fc0 [ 214.629248][ C240] x15: ffffffffffffffff x14: 0000000003ffffff [ 214.635241][ C240] x13: 000000000000ffff x12: 000000000000029c [ 214.641234][ C240] x11: 0000000000000006 x10: ffff80003a9f7fd0 [ 214.647226][ C240] x9 : ffffdb3a6f0482fc x8 : 0000000000000001 [ 214.653219][ C240] x7 : 0000000000000002 x6 : 0000000000000080 [ 214.659212][ C240] x5 : ffff55480ee9b000 x4 : fffffde7f94c6554 [ 214.665205][ C240] x3 : 0000000000000002 x2 : 0000000000000020 [ 214.671198][ C240] x1 : 0000000000000021 x0 : ffff3062a41ae5b8 [ 214.677191][ C240] Call trace: [ 214.680320][ C240] fputmany+0x8c/0xdc [ 214.684230][ C240] fput+0x1c/0xf0 [ 214.687707][ C240] aiocompleterw+0xd8/0x1fc [ 214.692225][ C240] blkdevbioendio+0x98/0x140 [ 214.696917][ C240] bioendio+0x160/0x1bc [ 214.701001][ C240] blkupdaterequest+0x1c8/0x3bc [ 214.705867][ C240] scsiendrequest+0x3c/0x1f0 [ 214.710471][ C240] scsiiocompletion+0x7c/0x1a0 [ 214.715249][ C240] scsifinishcommand+0x104/0x140 [ 214.720200][ C240] scsisoftirqdone+0x90/0x180 [ 214.724892][ C240] blkmqcompleterequest+0x5c/0x70 [ 214.730016][ C240] scsimqdone+0x48/0xac [ 214.734194][ C240] sasscsitaskdone+0xbc/0x16c [libsas] [ 214.739758][ C240] slotcompletev3hw+0x260/0x760 [hisisasv3hw] [ 214.746185][ C240] cqthreadv3hw+0xbc/0x190 [hisisasv3hw] [ 214.752179][ C240] irqthreadfn+0x34/0xa4 [ 214.756435][ C240] irqthread+0xc4/0x130 [ 214.760520][ C240] kthread+0x108/0x13c [ 214.764430][ C240] retfromfork+0x10/0x18 This is because in the hisisas driver, both the hardware interrupt handler and the interrupt thread are executed on the same CPU. In the performance test scenario, function irqwaitforinterrupt() will always return 0 if lots of interrupts occurs and the CPU will be continuously consumed. As a result, the CPU cannot run the watchdog thread. When the watchdog time exceeds the specified time, call trace occurs. To fix it, add cond_resched() to execute the watchdog thread.(CVE-2024-56589)

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: set the right AMDGPU sg segment limitation The driver needs to set the correct maxsegmentsize; otherwise debugdmamapsg() will complain about the over-mapping of the AMDGPU sg length as following: WARNING: CPU: 6 PID: 1964 at kernel/dma/debug.c:1178 debugdmamapsg+0x2dc/0x370 [ 364.049444] Modules linked in: veth amdgpu(OE) amdxcp drmexec gpusched drmbuddy drmttmhelper ttm(OE) drmsuballochelper drmdisplayhelper drmkmshelper i2calgobit rpcsecgsskrb5 authrpcgss nfsv4 nfs lockd grace netfs xtconntrack xtMASQUERADE nfconntracknetlink xfrmuser xfrmalgo iptablenat xtaddrtype iptablefilter brnetfilter nvmefabrics overlay nfnetlinkcttimeout nfnetlink openvswitch nsh nfconncount nfnat nfconntrack nfdefragipv6 nfdefragipv4 libcrc32c bridge stp llc amdatl intelraplmsr intelraplcommon sunrpc schfqcodel sndhdacodecrealtek sndhdacodecgeneric sndhdascodeccomponent sndhdacodechdmi sndhdaintel sndinteldspcfg edacmceamd binfmtmisc sndhdacodec sndpciacp6x sndhdacore sndacpconfig sndhwdep sndsocacpi kvmamd sndpcm kvm sndseqmidi sndseqmidievent crct10difpclmul ghashclmulniintel sha512ssse3 sndrawmidi sha256ssse3 sha1ssse3 aesniintel sndseq nlsiso88591 cryptosimd sndseqdevice cryptd sndtimer rapl inputleds snd [ 364.049532] ipmidevintf wmibmof ccp serioraw k10temp sp5100tco soundcore ipmimsghandler cm32181 industrialio machid msr parportpc ppdev lp parport drm efipstore iptables xtables pcistub crc32pclmul nvme ahci libahci i2cpiix4 r8169 nvmecore i2cdesignwarepci realtek i2cccgxucsi video wmi hidgeneric cdcether usbnet usbhid hid r8152 mii [ 364.049576] CPU: 6 PID: 1964 Comm: rocminfo Tainted: G OE 6.10.0-custom #492 [ 364.049579] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021 [ 364.049582] RIP: 0010:debugdmamapsg+0x2dc/0x370 [ 364.049585] Code: 89 4d b8 e8 36 b1 86 00 8b 4d b8 48 8b 55 b0 44 8b 45 a8 4c 8b 4d a0 48 89 c6 48 c7 c7 00 4b 74 bc 4c 89 4d b8 e8 b4 73 f3 ff <0f> 0b 4c 8b 4d b8 8b 15 c8 2c b8 01 85 d2 0f 85 ee fd ff ff 8b 05 [ 364.049588] RSP: 0018:ffff9ca600b57ac0 EFLAGS: 00010286 [ 364.049590] RAX: 0000000000000000 RBX: ffff88b7c132b0c8 RCX: 0000000000000027 [ 364.049592] RDX: ffff88bb0f521688 RSI: 0000000000000001 RDI: ffff88bb0f521680 [ 364.049594] RBP: ffff9ca600b57b20 R08: 000000000000006f R09: ffff9ca600b57930 [ 364.049596] R10: ffff9ca600b57928 R11: ffffffffbcb46328 R12: 0000000000000000 [ 364.049597] R13: 0000000000000001 R14: ffff88b7c19c0700 R15: ffff88b7c9059800 [ 364.049599] FS: 00007fb2d3516e80(0000) GS:ffff88bb0f500000(0000) knlGS:0000000000000000 [ 364.049601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 364.049603] CR2: 000055610bd03598 CR3: 00000001049f6000 CR4: 0000000000350ef0 [ 364.049605] Call Trace: [ 364.049607] <TASK> [ 364.049609] ? showregs+0x6d/0x80 [ 364.049614] ? _warn+0x8c/0x140 [ 364.049618] ? debugdmamapsg+0x2dc/0x370 [ 364.049621] ? reportbug+0x193/0x1a0 [ 364.049627] ? handlebug+0x46/0x80 [ 364.049631] ? excinvalidop+0x1d/0x80 [ 364.049635] ? asmexcinvalidop+0x1f/0x30 [ 364.049642] ? debugdmamapsg+0x2dc/0x370 [ 364.049647] _dmamapsgattrs+0x90/0xe0 [ 364.049651] dmamapsgtable+0x25/0x40 [ 364.049654] amdgpubomove+0x59a/0x850 [amdgpu] [ 364.049935] ? srsoreturnthunk+0x5/0x5f [ 364.049939] ? amdgputtmttpopulate+0x5d/0xc0 [amdgpu] [ 364.050095] ttmbohandlemovemem+0xc3/0x180 [ttm] [ 364.050103] ttmbovalidate+0xc1/0x160 [ttm] [ 364.050108] ? amdgputtmttgetuserpages+0xe5/0x1b0 [amdgpu] [ 364.050263] amdgpuamdkfdgpuvmallocmemoryofgpu+0xa12/0xc90 [amdgpu] [ 364.050473] kfdioctlallocmemoryofgpu+0x16b/0x3b0 [amdgpu] [ 364.050680] kfdioctl+0x3c2/0x530 [amdgpu] [ 364.050866] ? _pfxkfdioctlallocmemoryofgpu+0x10/0x10 [amdgpu] [ 364.05105 ---truncated---(CVE-2024-56594)

In the Linux kernel, the following vulnerability has been resolved: jfs: fix array-index-out-of-bounds in jfs_readdir The stbl might contain some invalid values. Added a check to return error code in that case.(CVE-2024-56596)

In the Linux kernel, the following vulnerability has been resolved: jfs: array-index-out-of-bounds fix in dtReadFirst The value of stbl can be sometimes out of bounds due to a bad filesystem. Added a check with appopriate return of error code in that case.(CVE-2024-56598)

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: avoid leaving dangling sk pointer in rfcommsockalloc() btsockalloc() attaches allocated sk object to the provided sock object. If rfcommdlcalloc() fails, we release the sk object, but leave the dangling pointer in the sock object, which may cause use-after-free. Fix this by swapping calls to btsockalloc() and rfcommdlcalloc().(CVE-2024-56604)

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2capsockcreate() btsockalloc() allocates the sk object and attaches it to the provided sock object. On error l2capsockalloc() frees the sk object, but the dangling pointer is still attached to the sock object, which may create use-after-free in other code.(CVE-2024-56605)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix out-of-bounds access in 'dcn21linkencodercreate' An issue was identified in the dcn21linkencodercreate function where an out-of-bounds access could occur when the hpdsource index was used to reference the linkenchpdregs array. This array has a fixed size and the index was not being checked against the array's bounds before accessing it. This fix adds a conditional check to ensure that the hpdsource index is within the valid range of the linkenchpdregs array. If the index is out of bounds, the function now returns NULL to prevent undefined behavior. References: [ 65.920507] ------------[ cut here ]------------ [ 65.920510] UBSAN: array-index-out-of-bounds in drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn21/dcn21resource.c:1312:29 [ 65.920519] index 7 is out of range for type 'dcn10linkenchpdregisters [5]' [ 65.920523] CPU: 3 PID: 1178 Comm: modprobe Tainted: G OE 6.8.0-cleanershaderfeatureresetasdntipmi200nv2132 #13 [ 65.920525] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS WMJ0429NWeekly20042 04/29/2020 [ 65.920527] Call Trace: [ 65.920529] <TASK> [ 65.920532] dumpstacklvl+0x48/0x70 [ 65.920541] dumpstack+0x10/0x20 [ 65.920543] ubsanhandleoutofbounds+0xa2/0xe0 [ 65.920549] dcn21linkencodercreate+0xd9/0x140 [amdgpu] [ 65.921009] linkcreate+0x6d3/0xed0 [amdgpu] [ 65.921355] createlinks+0x18a/0x4e0 [amdgpu] [ 65.921679] dccreate+0x360/0x720 [amdgpu] [ 65.921999] ? dmimatches+0xa0/0x220 [ 65.922004] amdgpudminit+0x2b6/0x2c90 [amdgpu] [ 65.922342] ? consoleunlock+0x77/0x120 [ 65.922348] ? devprintkemit+0x86/0xb0 [ 65.922354] dmhwinit+0x15/0x40 [amdgpu] [ 65.922686] amdgpudeviceinit+0x26a8/0x33a0 [amdgpu] [ 65.922921] amdgpudriverloadkms+0x1b/0xa0 [amdgpu] [ 65.923087] amdgpupciprobe+0x1b7/0x630 [amdgpu] [ 65.923087] localpciprobe+0x4b/0xb0 [ 65.923087] pcideviceprobe+0xc8/0x280 [ 65.923087] reallyprobe+0x187/0x300 [ 65.923087] _driverprobedevice+0x85/0x130 [ 65.923087] driverprobedevice+0x24/0x110 [ 65.923087] _driverattach+0xac/0x1d0 [ 65.923087] ? _pfxdriverattach+0x10/0x10 [ 65.923087] busforeachdev+0x7d/0xd0 [ 65.923087] driverattach+0x1e/0x30 [ 65.923087] busadddriver+0xf2/0x200 [ 65.923087] driverregister+0x64/0x130 [ 65.923087] ? _pfxamdgpuinit+0x10/0x10 [amdgpu] [ 65.923087] _pciregisterdriver+0x61/0x70 [ 65.923087] amdgpuinit+0x7d/0xff0 [amdgpu] [ 65.923087] dooneinitcall+0x49/0x310 [ 65.923087] ? kmalloctrace+0x136/0x360 [ 65.923087] doinitmodule+0x6a/0x270 [ 65.923087] loadmodule+0x1fce/0x23a0 [ 65.923087] initmodulefromfile+0x9c/0xe0 [ 65.923087] ? initmodulefromfile+0x9c/0xe0 [ 65.923087] idempotentinitmodule+0x179/0x230 [ 65.923087] _x64sysfinitmodule+0x5d/0xa0 [ 65.923087] dosyscall64+0x76/0x120 [ 65.923087] entrySYSCALL64afterhwframe+0x6e/0x76 [ 65.923087] RIP: 0033:0x7f2d80f1e88d [ 65.923087] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48 [ 65.923087] RSP: 002b:00007ffc7bc1aa78 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 65.923087] RAX: ffffffffffffffda RBX: 0000564c9c1db130 RCX: 00007f2d80f1e88d [ 65.923087] RDX: 0000000000000000 RSI: 0000564c9c1e5480 RDI: 000000000000000f [ 65.923087] RBP: 0000000000040000 R08: 0000000000000000 R09: 0000000000000002 [ 65.923087] R10: 000000000000000f R11: 0000000000000246 R12: 0000564c9c1e5480 [ 65.923087] R13: 0000564c9c1db260 R14: 0000000000000000 R15: 0000564c9c1e54b0 [ 65.923087] </TASK> [ 65.923927] ---[ end trace ]---(CVE-2024-56608)

In the Linux kernel, the following vulnerability has been resolved: bpf: fix OOB devmap writes when deleting elements Jordy reported issue against XSKMAP which also applies to DEVMAP - the index used for accessing map entry, due to being a signed integer, causes the OOB writes. Fix is simple as changing the type from int to u32, however, when compared to XSKMAP case, one more thing needs to be addressed. When map is released from system via devmapfree(), we iterate through all of the entries and an iterator variable is also an int, which implies OOB accesses. Again, change it to be u32. Example splat below: [ 160.724676] BUG: unable to handle page fault for address: ffffc8fc2c001000 [ 160.731662] #PF: supervisor read access in kernel mode [ 160.736876] #PF: errorcode(0x0000) - not-present page [ 160.742095] PGD 0 P4D 0 [ 160.744678] Oops: Oops: 0000 [#1] PREEMPT SMP [ 160.749106] CPU: 1 UID: 0 PID: 520 Comm: kworker/u145:12 Not tainted 6.12.0-rc1+ #487 [ 160.757050] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019 [ 160.767642] Workqueue: eventsunbound bpfmapfreedeferred [ 160.773308] RIP: 0010:devmapfree+0x77/0x170 [ 160.777735] Code: 00 e8 fd 91 ed ff e8 b8 73 ed ff 41 83 7d 18 19 74 6e 41 8b 45 24 49 8b bd f8 00 00 00 31 db 85 c0 74 48 48 63 c3 48 8d 04 c7 <48> 8b 28 48 85 ed 74 30 48 8b 7d 18 48 85 ff 74 05 e8 b3 52 fa ff [ 160.796777] RSP: 0018:ffffc9000ee1fe38 EFLAGS: 00010202 [ 160.802086] RAX: ffffc8fc2c001000 RBX: 0000000080000000 RCX: 0000000000000024 [ 160.809331] RDX: 0000000000000000 RSI: 0000000000000024 RDI: ffffc9002c001000 [ 160.816576] RBP: 0000000000000000 R08: 0000000000000023 R09: 0000000000000001 [ 160.823823] R10: 0000000000000001 R11: 00000000000ee6b2 R12: dead000000000122 [ 160.831066] R13: ffff88810c928e00 R14: ffff8881002df405 R15: 0000000000000000 [ 160.838310] FS: 0000000000000000(0000) GS:ffff8897e0c40000(0000) knlGS:0000000000000000 [ 160.846528] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 160.852357] CR2: ffffc8fc2c001000 CR3: 0000000005c32006 CR4: 00000000007726f0 [ 160.859604] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 160.866847] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 160.874092] PKRU: 55555554 [ 160.876847] Call Trace: [ 160.879338] <TASK> [ 160.881477] ? _die+0x20/0x60 [ 160.884586] ? pagefaultoops+0x15a/0x450 [ 160.888746] ? searchextable+0x22/0x30 [ 160.892647] ? searchbpfextables+0x5f/0x80 [ 160.896988] ? excpagefault+0xa9/0x140 [ 160.900973] ? asmexcpagefault+0x22/0x30 [ 160.905232] ? devmapfree+0x77/0x170 [ 160.909043] ? devmapfree+0x58/0x170 [ 160.912857] bpfmapfreedeferred+0x51/0x90 [ 160.917196] processonework+0x142/0x370 [ 160.921272] workerthread+0x29e/0x3b0 [ 160.925082] ? rescuerthread+0x4b0/0x4b0 [ 160.929157] kthread+0xd4/0x110 [ 160.932355] ? kthreadpark+0x80/0x80 [ 160.936079] retfromfork+0x2d/0x50 [ 160.943396] ? kthreadpark+0x80/0x80 [ 160.950803] retfromforkasm+0x11/0x20 [ 160.958482] </TASK>(CVE-2024-56615)

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential out-of-bounds memory access in nilfsfindentry() Syzbot reported that when searching for records in a directory where the inode's isize is corrupted and has a large value, memory access outside the folio/page range may occur, or a use-after-free bug may be detected if KASAN is enabled. This is because nilfslastbyte(), which is called by nilfsfindentry() and others to calculate the number of valid bytes of directory data in a page from isize and the page index, loses the upper 32 bits of the 64-bit size information due to an inappropriate type of local variable to which the isize value is assigned. This caused a large byte offset value due to underflow in the end address calculation in the calling nilfsfindentry(), resulting in memory access that exceeds the folio/page size. Fix this issue by changing the type of the local variable causing the bit loss from "unsigned int" to "u64". The return value of nilfslastbyte() is also of type "unsigned int", but it is truncated so as not to exceed PAGESIZE and no bit loss occurs, so no change is required.(CVE-2024-56619)

In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix Out-of-Bounds Read in ksmbdvfsstreamread An offset from client could be a negative value, It could lead to an out-of-bounds read from the streambuf. Note that this issue is coming when setting 'vfs objects = streams_xattr parameter' in ksmbd.conf.(CVE-2024-56627)

In the Linux kernel, the following vulnerability has been resolved: HID: wacom: fix when get product name maybe null pointer Due to incorrect dev->product reporting by certain devices, null pointer dereferences occur when dev->product is empty, leading to potential system crashes. This issue was found on EXCELSIOR DL37-D05 device with Loongson-LS3A6000-7A2000-DL37 motherboard. Kernel logs: [ 56.470885] usb 4-3: new full-speed USB device number 4 using ohci-pci [ 56.671638] usb 4-3: string descriptor 0 read error: -22 [ 56.671644] usb 4-3: New USB device found, idVendor=056a, idProduct=0374, bcdDevice= 1.07 [ 56.671647] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 56.678839] hid-generic 0003:056A:0374.0004: hiddev0,hidraw3: USB HID v1.10 Device [HID 056a:0374] on usb-0000:00:05.0-3/input0 [ 56.697719] CPU 2 Unable to handle kernel paging request at virtual address 0000000000000000, era == 90000000066e35c8, ra == ffff800004f98a80 [ 56.697732] Oops[#1]: [ 56.697734] CPU: 2 PID: 2742 Comm: (udev-worker) Tainted: G OE 6.6.0-loong64-desktop #25.00.2000.015 [ 56.697737] Hardware name: Inspur CE520L2/C09901N000000000, BIOS 2.09.00 10/11/2024 [ 56.697739] pc 90000000066e35c8 ra ffff800004f98a80 tp 9000000125478000 sp 900000012547b8a0 [ 56.697741] a0 0000000000000000 a1 ffff800004818b28 a2 0000000000000000 a3 0000000000000000 [ 56.697743] a4 900000012547b8f0 a5 0000000000000000 a6 0000000000000000 a7 0000000000000000 [ 56.697745] t0 ffff800004818b2d t1 0000000000000000 t2 0000000000000003 t3 0000000000000005 [ 56.697747] t4 0000000000000000 t5 0000000000000000 t6 0000000000000000 t7 0000000000000000 [ 56.697748] t8 0000000000000000 u0 0000000000000000 s9 0000000000000000 s0 900000011aa48028 [ 56.697750] s1 0000000000000000 s2 0000000000000000 s3 ffff800004818e80 s4 ffff800004810000 [ 56.697751] s5 90000001000b98d0 s6 ffff800004811f88 s7 ffff800005470440 s8 0000000000000000 [ 56.697753] ra: ffff800004f98a80 wacomupdatename+0xe0/0x300 [wacom] [ 56.697802] ERA: 90000000066e35c8 strstr+0x28/0x120 [ 56.697806] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) [ 56.697816] PRMD: 0000000c (PPLV0 +PIE +PWE) [ 56.697821] EUEN: 00000000 (-FPE -SXE -ASXE -BTE) [ 56.697827] ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) [ 56.697831] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) [ 56.697835] BADV: 0000000000000000 [ 56.697836] PRID: 0014d000 (Loongson-64bit, Loongson-3A6000) [ 56.697838] Modules linked in: wacom(+) bnep bluetooth rfkill qrtr nlsiso88591 nlscp437 sndhdacodecconexant sndhdacodecgeneric ledtrigaudio sndhdacodechdmi sndhdaintel sndinteldspcfg sndhdacodec sndhdacore sndhwdep sndpcm sndtimer snd soundcore inputleds mousedev ledclass joydev deepinnetmonitor(OE) fuse nfnetlink dmisysfs iptables xtables overlay amdgpu amdxcp drmexec gpusched drmbuddy radeon drmsuballochelper i2calgobit drmttmhelper r8169 ttm drmdisplayhelper spiloongsonpci xhcipci cec xhcipcirenesas spiloongsoncore hidgeneric realtek gpioloongson_64bit [ 56.697887] Process (udev-worker) (pid: 2742, threadinfo=00000000aee0d8b4, task=00000000a9eff1f3) [ 56.697890] Stack : 0000000000000000 ffff800004817e00 0000000000000000 0000251c00000000 [ 56.697896] 0000000000000000 00000011fffffffd 0000000000000000 0000000000000000 [ 56.697901] 0000000000000000 1b67a968695184b9 0000000000000000 90000001000b98d0 [ 56.697906] 90000001000bb8d0 900000011aa48028 0000000000000000 ffff800004f9d74c [ 56.697911] 90000001000ba000 ffff800004f9ce58 0000000000000000 ffff800005470440 [ 56.697916] ffff800004811f88 90000001000b98d0 9000000100da2aa8 90000001000bb8d0 [ 56.697921] 0000000000000000 90000001000ba000 900000011aa48028 ffff800004f9d74c [ 56.697926] ffff8000054704e8 90000001000bb8b8 90000001000ba000 0000000000000000 [ 56.697931] 90000001000bb8d0 ---truncated---(CVE-2024-56629)

In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: Fix UAF in blkcgunpinonline() blkcgunpinonline() walks up the blkcg hierarchy putting the online pin. To walk up, it uses blkcgparent(blkcg) but it was calling that after blkcgdestroyblkgs(blkcg) which could free the blkcg, leading to the following UAF: ================================================================== BUG: KASAN: slab-use-after-free in blkcgunpinonline+0x15a/0x270 Read of size 8 at addr ffff8881057678c0 by task kworker/9:1/117 CPU: 9 UID: 0 PID: 117 Comm: kworker/9:1 Not tainted 6.13.0-rc1-work-00182-gb8f52214c61a-dirty #48 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 02/02/2022 Workqueue: cgwbrelease cgwbreleaseworkfn Call Trace: <TASK> dumpstacklvl+0x27/0x80 printreport+0x151/0x710 kasanreport+0xc0/0x100 blkcgunpinonline+0x15a/0x270 cgwbreleaseworkfn+0x194/0x480 processscheduledworks+0x71b/0xe20 workerthread+0x82a/0xbd0 kthread+0x242/0x2c0 retfromfork+0x33/0x70 retfromforkasm+0x1a/0x30 </TASK> ... Freed by task 1944: kasansavetrack+0x2b/0x70 kasansavefreeinfo+0x3c/0x50 _kasanslabfree+0x33/0x50 kfree+0x10c/0x330 cssfreerworkfn+0xe6/0xb30 processscheduledworks+0x71b/0xe20 workerthread+0x82a/0xbd0 kthread+0x242/0x2c0 retfromfork+0x33/0x70 retfromforkasm+0x1a/0x30 Note that the UAF is not easy to trigger as the free path is indirected behind a couple RCU grace periods and a work item execution. I could only trigger it with artifical msleep() injected in blkcgunpin_online(). Fix it by reading the parent pointer before destroying the blkcg's blkg's.(CVE-2024-56672)

In the Linux kernel, the following vulnerability has been resolved: crypto: bcm - add error check in the ahashhmacinit function The ahashinit functions may return fails. The ahashhmacinit should not return ok when ahashinit returns error. For an example, ahash_init will return -ENOMEM when allocation memory is error.(CVE-2024-56681)

In the Linux kernel, the following vulnerability has been resolved: ext4: fix race in bufferhead read fault injection When I enabled ext4 debug for fault injection testing, I encountered the following warning: EXT4-fs error (device sda): ext4readinodebitmap:201: comm fsstress: Cannot read inode bitmap - blockgroup = 8, inodebitmap = 1051 WARNING: CPU: 0 PID: 511 at fs/buffer.c:1181 markbufferdirty+0x1b3/0x1d0 The root cause of the issue lies in the improper implementation of ext4's bufferhead read fault injection. The actual completion of bufferhead read and the bufferhead fault injection are not atomic, which can lead to the uptodate flag being cleared on normally used bufferheads in race conditions. [CPU0] [CPU1] [CPU2] ext4readinodebitmap ext4readbh() <bh read complete> ext4readinodebitmap if (bufferuptodate(bh)) return bh jbd2journalcommittransaction _jbd2journalrefilebuffer _jbd2journalunfilebuffer _jbd2journaltempunlinkbuffer ext4simulatefailbh() clearbufferuptodate markbufferdirty <report warning> WARNONONCE(!buffer_uptodate(bh)) The best approach would be to perform fault injection in the IO completion callback function, rather than after IO completion. However, the IO completion callback function cannot get the fault injection code in sb. Fix it by passing the result of fault injection into the bh read function, we simulate faults within the bh read function itself. This requires adding an extra parameter to the bh read functions that need fault injection.(CVE-2024-56686)

In the Linux kernel, the following vulnerability has been resolved: mfd: intelsocpmicbxtwc: Use IRQ domain for USB Type-C device While design wise the idea of converting the driver to use the hierarchy of the IRQ chips is correct, the implementation has (inherited) flaws. This was unveiled when platformget_irq() had started WARN() on IRQ 0 that is supposed to be a Linux IRQ number (also known as vIRQ). Rework the driver to respect IRQ domain when creating each MFD device separately, as the domain is not the same for all of them.(CVE-2024-56691)

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on node blkaddr in truncatenode() syzbot reports a f2fs bug as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2534! RIP: 0010:f2fsinvalidateblocks+0x35f/0x370 fs/f2fs/segment.c:2534 Call Trace: truncatenode+0x1ae/0x8c0 fs/f2fs/node.c:909 f2fsremoveinodepage+0x5c2/0x870 fs/f2fs/node.c:1288 f2fsevictinode+0x879/0x15c0 fs/f2fs/inode.c:856 evict+0x4e8/0x9b0 fs/inode.c:723 f2fshandlefailedinode+0x271/0x2e0 fs/f2fs/inode.c:986 f2fscreate+0x357/0x530 fs/f2fs/namei.c:394 lookupopen fs/namei.c:3595 [inline] openlastlookups fs/namei.c:3694 [inline] pathopenat+0x1c03/0x3590 fs/namei.c:3930 dofilpopen+0x235/0x490 fs/namei.c:3960 dosysopenat2+0x13e/0x1d0 fs/open.c:1415 dosysopen fs/open.c:1430 [inline] _dosysopenat fs/open.c:1446 [inline] _sesysopenat fs/open.c:1441 [inline] _x64sysopenat+0x247/0x2a0 fs/open.c:1441 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0010:f2fsinvalidateblocks+0x35f/0x370 fs/f2fs/segment.c:2534 The root cause is: on a fuzzed image, blkaddr in nat entry may be corrupted, then it will cause system panic when using it in f2fsinvalidateblocks(), to avoid this, let's add sanity check on nat blkaddr in truncate_node().(CVE-2024-56692)

In the Linux kernel, the following vulnerability has been resolved: media: wl128x: Fix atomicity violation in fmcsendcmd() Atomicity violation occurs when the fmcsendcmd() function is executed simultaneously with the modification of the fmdev->respskb value. Consider a scenario where, after passing the validity check within the function, a non-null fmdev->respskb variable is assigned a null value. This results in an invalid fmdev->respskb variable passing the validity check. As seen in the later part of the function, skb = fmdev->respskb; when the invalid fmdev->respskb passes the check, a null pointer dereference error may occur at line 478, evthdr = (void *)skb->data; To address this issue, it is recommended to include the validity check of fmdev->respskb within the locked section of the function. This modification ensures that the value of fmdev->respskb does not change during the validation process, thereby maintaining its validity. This possible bug is found by an experimental static analysis tool developed by our team. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations.(CVE-2024-56700)

In the Linux kernel, the following vulnerability has been resolved: iouring: check if iowq is killed before queuing task work can be executed after the task has gone through iouring termination, whether it's the final taskwork run or the fallback path. In this case, task work will find ->iowq being already killed and null'ed, which is a problem if it then tries to forward the request to ioqueueiowq(). Make ioqueueiowq() fail requests in this case. Note that it also checks PFKTHREAD, because the user can first close a DEFERTASKRUN ring and shortly after kill the task, in which case ->iowq check would race.(CVE-2024-56709)

In the Linux kernel, the following vulnerability has been resolved: rtc: check if _rtcreadtime was successful in rtctimerdowork() If the _rtcreadtime call fails,, the struct rtctime tm; may contain uninitialized data, or an illegal date/time read from the RTC hardware. When calling rtctmtoktime later, the result may be a very large value (possibly KTIMEMAX). If there are periodic timers in rtc->timerqueue, they will continually expire, may causing kernel softlockup.(CVE-2024-56739)

In the Linux kernel, the following vulnerability has been resolved: apparmor: test: Fix memory leak for aaunpackstrdup() The string allocated by kmemdup() in aaunpackstrdup() is not freed and cause following memory leaks, free them to fix it. unreferenced object 0xffffff80c6af8a50 (size 8): comm "kunittrycatch", pid 225, jiffies 4294894407 hex dump (first 8 bytes): 74 65 73 74 69 6e 67 00 testing. backtrace (crc 5eab668b): [<0000000001e3714d>] kmemleakalloc+0x34/0x40 [<000000006e6c7776>] _kmallocnodetrackcallernoprof+0x300/0x3e0 [<000000006870467c>] kmemdupnoprof+0x34/0x60 [<000000001176bb03>] aaunpackstrdup+0xd0/0x18c [<000000008ecde918>] policyunpacktestunpackstrdupwithnullname+0xf8/0x3ec [<0000000032ef8f77>] kunittryruncase+0x13c/0x3ac [<00000000f3edea23>] kunitgenericrunthreadfnadapter+0x80/0xec [<00000000adf936cf>] kthread+0x2e8/0x374 [<0000000041bb1628>] retfromfork+0x10/0x20 unreferenced object 0xffffff80c2a29090 (size 8): comm "kunittrycatch", pid 227, jiffies 4294894409 hex dump (first 8 bytes): 74 65 73 74 69 6e 67 00 testing. backtrace (crc 5eab668b): [<0000000001e3714d>] kmemleakalloc+0x34/0x40 [<000000006e6c7776>] _kmallocnodetrackcallernoprof+0x300/0x3e0 [<000000006870467c>] kmemdupnoprof+0x34/0x60 [<000000001176bb03>] aaunpackstrdup+0xd0/0x18c [<0000000046a45c1a>] policyunpacktestunpackstrdupwithname+0xd0/0x3c4 [<0000000032ef8f77>] kunittryruncase+0x13c/0x3ac [<00000000f3edea23>] kunitgenericrunthreadfnadapter+0x80/0xec [<00000000adf936cf>] kthread+0x2e8/0x374 [<0000000041bb1628>] retfrom_fork+0x10/0x20(CVE-2024-56741)

In the Linux kernel, the following vulnerability has been resolved: scsi: qedi: Fix a possible memory leak in qediallocandinitsb() Hook "qediops->common->sbinit = qedsbinit" does not release the DMA memory sbvirt when it fails. Add dmafreecoherent() to free it. This is the same way as qedrallocmemsb() and qedeallocmem_sb().(CVE-2024-56747)

In the Linux kernel, the following vulnerability has been resolved: scsi: qedf: Fix a possible memory leak in qedfallocandinitsb() Hook "qedops->common->sbinit = qedsbinit" does not release the DMA memory sbvirt when it fails. Add dmafreecoherent() to free it. This is the same way as qedrallocmemsb() and qedeallocmem_sb().(CVE-2024-56748)

In the Linux kernel, the following vulnerability has been resolved: nvme-pci: fix freeing of the HMB descriptor table The HMB descriptor table is sized to the maximum number of descriptors that could be used for a given device, but _nvmeallochostmem could break out of the loop earlier on memory allocation failure and end up using less descriptors than planned for, which leads to an incorrect size passed to dmafreecoherent. In practice this was not showing up because the number of descriptors tends to be low and the dma coherent allocator always allocates and frees at least a page.(CVE-2024-56756)

In the Linux kernel, the following vulnerability has been resolved: tracing: Prevent bad count for tracingcpumaskwrite If a large count is provided, it will trigger a warning in bitmapparseuser. Also check zero for it.(CVE-2024-56763)