OESA-2025-1032

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: drm/amd/display: Check null pointer before try to access it [why & how] Change the order of the pipectx->planestate check to ensure that plane_state is not null before accessing it.(CVE-2024-49906)

In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client A number of Zen4 client SoCs advertise the ability to use virtualized VMLOAD/VMSAVE, but using these instructions is reported to be a cause of a random host reboot. These instructions aren't intended to be advertised on Zen4 client so clear the capability.(CVE-2024-53114)

In the Linux kernel, the following vulnerability has been resolved: vdpa: solidrun: Fix UB bug with devres In psnetopenpfbar() and snetopenvfbar() a string later passed to pcimiomapregions() is placed on the stack. Neither pcimiomapregions() nor the functions it calls copy that string. Should the string later ever be used, this, consequently, causes undefined behavior since the stack frame will by then have disappeared. Fix the bug by allocating the strings on the heap through devm_kasprintf().(CVE-2024-53126)

In the Linux kernel, the following vulnerability has been resolved: Revert "mmc: dwmmc: Fix IDMAC operation with pages bigger than 4K" The commit 8396c793ffdf ("mmc: dwmmc: Fix IDMAC operation with pages bigger than 4K") increased the maxreqsize, even for 4K pages, causing various issues: - Panic booting the kernel/rootfs from an SD card on Rockchip RK3566 - Panic booting the kernel/rootfs from an SD card on StarFive JH7100 - "swiotlb buffer is full" and data corruption on StarFive JH7110 At this stage no fix have been found, so it's probably better to just revert the change. This reverts commit 8396c793ffdf28bb8aee7cfe0891080f8cab7890.(CVE-2024-53127)

In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx93-blk-ctrl: correct remove path The check condition should be 'i < bc->onecelldata.numdomains', not 'bc->onecelldata.numdomains' which will make the look never finish and cause kernel panic. Also disable runtime to address "imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pmruntimeenable!"(CVE-2024-53134)

In the Linux kernel, the following vulnerability has been resolved: mm: revert "mm: shmem: fix data-race in shmemgetattr()" Revert d949d1d14fa2 ("mm: shmem: fix data-race in shmemgetattr()") as suggested by Chuck [1]. It is causing deadlocks when accessing tmpfs over NFS. As Hugh commented, "added just to silence a syzbot sanitizer splat: added where there has never been any practical problem".(CVE-2024-53136)

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: svcrdma: Address an integer overflow Dan Carpenter reports: > Commit 78147ca8b4a9 ("svcrdma: Add a "parsed chunk list" data > structure") from Jun 22, 2020 (linux-next), leads to the following > Smatch static checker warning: > > net/sunrpc/xprtrdma/svcrdmarecvfrom.c:498 xdrcheckwritechunk() > warn: potential user controlled sizeof overflow 'segcount * 4 * 4' > > net/sunrpc/xprtrdma/svcrdmarecvfrom.c > 488 static bool xdrcheckwritechunk(struct svcrdmarecvctxt *rctxt) > 489 { > 490 u32 segcount; > 491 _be32 p; > 492 > 493 if (xdr_stream_decode_u32(&rctxt->rc_stream, &segcount)) > ^^^^^^^^ > > 494 return false; > 495 > 496 / A bogus segcount causes this buffer overflow check to fail. / > 497 p = xdr_inline_decode(&rctxt->rc_stream, > --> 498 segcount * rpcrdma_segment_maxsz * sizeof(p)); > > > segcount is an untrusted u32. On 32bit systems anything >= SIZEMAX / 16 will > have an integer overflow and some those values will be accepted by > xdrinline_decode().(CVE-2024-53151)

In the Linux kernel, the following vulnerability has been resolved: clk: clk-apple-nco: Add NULL check in applncoprobe Add NULL check in applncoprobe, to handle kernel NULL pointer dereference error.(CVE-2024-53154)

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: crypto: qat/qat420xx - fix off by one in uofgetname() This is called from uofgetname420xx() where "numobjs" is the ARRAYSIZE() of fw_objs[]. The > needs to be >= to prevent an out of bounds access.(CVE-2024-53163)

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: block: fix uaf for flush rq while iterating tags blkmqclearflushrqmapping() is not called during scsi probe, by checking blkqueueinitdone(). However, QUEUEFLAGINITDONE is cleared in delgendisk by commit aec89dc5d421 ("block: keep qusagecounter in atomic mode after delgendisk"), hence for disk like scsi, following blkmqdestroyqueue() will not clear flush rq from tags->rqs[] as well, cause following uaf that is found by our syzkaller for v6.6: ================================================================== BUG: KASAN: slab-use-after-free in blkmqfindandgetreq+0x16e/0x1a0 block/blk-mq-tag.c:261 Read of size 4 at addr ffff88811c969c20 by task kworker/1:2H/224909 CPU: 1 PID: 224909 Comm: kworker/1:2H Not tainted 6.6.0-ga836a5060850 #32 Workqueue: kblockd blkmqtimeoutwork Call Trace: dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x91/0xf0 lib/dumpstack.c:106 printaddressdescription.constprop.0+0x66/0x300 mm/kasan/report.c:364 printreport+0x3e/0x70 mm/kasan/report.c:475 kasanreport+0xb8/0xf0 mm/kasan/report.c:588 blkmqfindandgetreq+0x16e/0x1a0 block/blk-mq-tag.c:261 btiter block/blk-mq-tag.c:288 [inline] _sbitmapforeachset include/linux/sbitmap.h:295 [inline] sbitmapforeachset include/linux/sbitmap.h:316 [inline] btforeach+0x455/0x790 block/blk-mq-tag.c:325 blkmqqueuetagbusyiter+0x320/0x740 block/blk-mq-tag.c:534 blkmqtimeoutwork+0x1a3/0x7b0 block/blk-mq.c:1673 processonework+0x7c4/0x1450 kernel/workqueue.c:2631 processscheduledworks kernel/workqueue.c:2704 [inline] workerthread+0x804/0xe40 kernel/workqueue.c:2785 kthread+0x346/0x450 kernel/kthread.c:388 retfromfork+0x4d/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1b/0x30 arch/x86/entry/entry64.S:293 Allocated by task 942: kasansavestack+0x22/0x50 mm/kasan/common.c:45 kasansettrack+0x25/0x30 mm/kasan/common.c:52 _kasankmalloc mm/kasan/common.c:374 [inline] kasankmalloc mm/kasan/common.c:383 [inline] _kasankmalloc+0xaa/0xb0 mm/kasan/common.c:380 kasankmalloc include/linux/kasan.h:198 [inline] _dokmallocnode mm/slabcommon.c:1007 [inline] _kmallocnode+0x69/0x170 mm/slabcommon.c:1014 kmallocnode include/linux/slab.h:620 [inline] kzallocnode include/linux/slab.h:732 [inline] blkallocflushqueue+0x144/0x2f0 block/blk-flush.c:499 blkmqallochctx+0x601/0x940 block/blk-mq.c:3788 blkmqallocandinithctx+0x27f/0x330 block/blk-mq.c:4261 blkmqreallochwctxs+0x488/0x5e0 block/blk-mq.c:4294 blkmqinitallocatedqueue+0x188/0x860 block/blk-mq.c:4350 blkmqinitqueuedata block/blk-mq.c:4166 [inline] blkmqinitqueue+0x8d/0x100 block/blk-mq.c:4176 scsiallocsdev+0x843/0xd50 drivers/scsi/scsiscan.c:335 scsiprobeandaddlun+0x77c/0xde0 drivers/scsi/scsiscan.c:1189 _scsiscantarget+0x1fc/0x5a0 drivers/scsi/scsiscan.c:1727 scsiscanchannel drivers/scsi/scsiscan.c:1815 [inline] scsiscanchannel+0x14b/0x1e0 drivers/scsi/scsiscan.c:1791 scsiscanhostselected+0x2fe/0x400 drivers/scsi/scsiscan.c:1844 scsiscan+0x3a0/0x3f0 drivers/scsi/scsisysfs.c:151 storescan+0x2a/0x60 drivers/scsi/scsisysfs.c:191 devattrstore+0x5c/0x90 drivers/base/core.c:2388 sysfskfwrite+0x11c/0x170 fs/sysfs/file.c:136 kernfsfopwriteiter+0x3fc/0x610 fs/kernfs/file.c:338 callwriteiter include/linux/fs.h:2083 [inline] newsyncwrite+0x1b4/0x2d0 fs/readwrite.c:493 vfswrite+0x76c/0xb00 fs/readwrite.c:586 ksyswrite+0x127/0x250 fs/readwrite.c:639 dosyscallx64 arch/x86/entry/common.c:51 [inline] dosyscall64+0x70/0x120 arch/x86/entry/common.c:81 entrySYSCALL64afterhwframe+0x78/0xe2 Freed by task 244687: kasansavestack+0x22/0x50 mm/kasan/common.c:45 kasansettrack+0x25/0x30 mm/kasan/common.c:52 kasansavefreeinfo+0x2b/0x50 mm/kasan/generic.c:522 _kasanslabfree mm/kasan/common.c:236 [inline] _kasanslabfree+0x12a/0x1b0 mm/kasan/common.c:244 kasanslab_free include/linux/kasan.h:164 [in ---truncated---(CVE-2024-53170)

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: ksmbd: fix use-after-free in SMB request handling A race condition exists between SMB request handling in ksmbd_conn_handler_loop() and the freeing of ksmbd_conn in the workqueue handler handle_ksmbd_work(). This leads to a UAF. - KASAN: slab-use-after-free Read in handleksmbdwork - KASAN: slab-use-after-free in rtlockslowlocklocked This race condition arises as follows: - ksmbd_conn_handler_loop() waits for conn->r_count to reach zero: wait_event(conn->r_count_q, atomic_read(&conn->r_count) == 0); - Meanwhile, handle_ksmbd_work() decrements conn->r_count using atomic_dec_return(&conn->r_count), and if it reaches zero, calls ksmbd_conn_free(), which frees conn. - However, after handle_ksmbd_work() decrements conn->r_count, it may still access conn->r_count_q in the following line: waitqueue_active(&conn->r_count_q) or wake_up(&conn->r_count_q) This results in a UAF, as conn has already been freed. The discovery of this UAF can be referenced in the following PR for syzkaller's support for SMB requests.(CVE-2024-53186)

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: firmwareloader: Fix possible resource leak in fwlogfirmwareinfo() The alg instance should be released under the exception path, otherwise there may be resource leak here. To mitigate this, free the alg instance with cryptofreeshash when kmalloc fails.(CVE-2024-53202)

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 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: 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: cpufreq: CPPC: Fix possible null-ptr-deref for cppcgetcpucost() cpufreqcpugetraw() may return NULL if the cpu is not in policy->cpus cpu mask and it will cause null pointer dereference, so check NULL for cppcgetcpu_cost().(CVE-2024-53230)

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: 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: media: imx-jpeg: Ensure power suppliers be suspended before detach them The power suppliers are always requested to suspend asynchronously, devpmdomaindetach() requires the caller to ensure proper synchronization of this function with power management callbacks. otherwise the detach may led to kernel panic, like below: [ 1457.107934] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000040 [ 1457.116777] Mem abort info: [ 1457.119589] ESR = 0x0000000096000004 [ 1457.123358] EC = 0x25: DABT (current EL), IL = 32 bits [ 1457.128692] SET = 0, FnV = 0 [ 1457.131764] EA = 0, S1PTW = 0 [ 1457.134920] FSC = 0x04: level 0 translation fault [ 1457.139812] Data abort info: [ 1457.142707] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 1457.148196] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 1457.153256] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1457.158563] user pgtable: 4k pages, 48-bit VAs, pgdp=00000001138b6000 [ 1457.165000] [0000000000000040] pgd=0000000000000000, p4d=0000000000000000 [ 1457.171792] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 1457.178045] Modules linked in: v4l2jpeg wave6vpuctrl(-) [last unloaded: mxcjpegencdec] [ 1457.186383] CPU: 0 PID: 51938 Comm: kworker/0:3 Not tainted 6.6.36-gd23d64eea511 #66 [ 1457.194112] Hardware name: NXP i.MX95 19X19 board (DT) [ 1457.199236] Workqueue: pm pmruntimework [ 1457.203247] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1457.210188] pc : genpdruntimesuspend+0x20/0x290 [ 1457.214886] lr : _rpmcallback+0x48/0x1d8 [ 1457.218968] sp : ffff80008250bc50 [ 1457.222270] x29: ffff80008250bc50 x28: 0000000000000000 x27: 0000000000000000 [ 1457.229394] x26: 0000000000000000 x25: 0000000000000008 x24: 00000000000f4240 [ 1457.236518] x23: 0000000000000000 x22: ffff00008590f0e4 x21: 0000000000000008 [ 1457.243642] x20: ffff80008099c434 x19: ffff00008590f000 x18: ffffffffffffffff [ 1457.250766] x17: 5300326563697665 x16: 645f676e696c6f6f x15: 63343a6d726f6674 [ 1457.257890] x14: 0000000000000004 x13: 00000000000003a4 x12: 0000000000000002 [ 1457.265014] x11: 0000000000000000 x10: 0000000000000a60 x9 : ffff80008250bbb0 [ 1457.272138] x8 : ffff000092937200 x7 : ffff0003fdf6af80 x6 : 0000000000000000 [ 1457.279262] x5 : 00000000410fd050 x4 : 0000000000200000 x3 : 0000000000000000 [ 1457.286386] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00008590f000 [ 1457.293510] Call trace: [ 1457.295946] genpdruntimesuspend+0x20/0x290 [ 1457.300296] _rpmcallback+0x48/0x1d8 [ 1457.304038] rpmcallback+0x6c/0x78 [ 1457.307515] rpmsuspend+0x10c/0x570 [ 1457.311077] pmruntimework+0xc4/0xc8 [ 1457.314813] processonework+0x138/0x248 [ 1457.318816] workerthread+0x320/0x438 [ 1457.322552] kthread+0x110/0x114 [ 1457.325767] retfrom_fork+0x10/0x20(CVE-2024-56575)

In the Linux kernel, the following vulnerability has been resolved: media: imx-jpeg: Set video drvdata before register video device The video drvdata should be set before the video device is registered, otherwise video_drvdata() may return NULL in the open() file ops, and led to oops.(CVE-2024-56578)

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: 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: 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: 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: scsi: ufs: qcom: Only free platform MSIs when ESI is enabled Otherwise, it will result in a NULL pointer dereference as below: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Call trace: mutexlock+0xc/0x54 platformdevicemsifreeirqsall+0x14/0x20 ufsqcomremove+0x34/0x48 [ufsqcom] platformremove+0x28/0x44 deviceremove+0x4c/0x80 devicereleasedriverinternal+0xd8/0x178 driverdetach+0x50/0x9c busremovedriver+0x6c/0xbc driverunregister+0x30/0x60 platformdriverunregister+0x14/0x20 ufsqcompltformexit+0x18/0xb94 [ufsqcom] _arm64sysdeletemodule+0x180/0x260 invokesyscall+0x44/0x100 el0svccommon.constprop.0+0xc0/0xe0 doel0svc+0x1c/0x28 el0svc+0x34/0xdc el0t64synchandler+0xc0/0xc4 el0t64_sync+0x190/0x194(CVE-2024-56620)

In the Linux kernel, the following vulnerability has been resolved: iommufd: Fix outfput in iommufdfaultalloc() As fput() calls the file->fop->release op, where fault obj and ictx are getting released, there is no need to release these two after fput() one more time, which would result in imbalanced refcounts: refcountt: decrement hit 0; leaking memory. WARNING: CPU: 48 PID: 2369 at lib/refcount.c:31 refcountwarnsaturate+0x60/0x230 Call trace: refcountwarnsaturate+0x60/0x230 (P) refcountwarnsaturate+0x60/0x230 (L) iommufdfaultfopsrelease+0x9c/0xe0 [iommufd] ... VFS: Close: file count is 0 (fop=iommufdfops [iommufd]) WARNING: CPU: 48 PID: 2369 at fs/open.c:1507 filpflush+0x3c/0xf0 Call trace: filpflush+0x3c/0xf0 (P) filpflush+0x3c/0xf0 (L) _arm64sysclose+0x34/0x98 ... imbalanced put on file reference count WARNING: CPU: 48 PID: 2369 at fs/file.c:74 _filerefput+0x100/0x138 Call trace: _filerefput+0x100/0x138 (P) _filerefput+0x100/0x138 (L) _fput_sync+0x4c/0xd0 Drop those two lines to fix the warnings above.(CVE-2024-56624)

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: ocfs2: free inode when ocfs2getinitinode() fails syzbot is reporting busy inodes after unmount, for commit 9c89fe0af826 ("ocfs2: Handle error from dquotinitialize()") forgot to call iput() when newinode() succeeded and dquotinitialize() failed.(CVE-2024-56630)

In the Linux kernel, the following vulnerability has been resolved: bpf,perf: Fix invalid progarray access in perfeventdetachbpfprog Syzbot reported [1] crash that happens for following tracing scenario: - create tracepoint perf event with attr.inherit=1, attach it to the process and set bpf program to it - attached process forks -> chid creates inherited event the new child event shares the parent's bpf program and tpevent (hence progarray) which is global for tracepoint - exit both process and its child -> release both events - first perfeventdetachbpfprog call will release tpevent->progarray and second perfeventdetachbpfprog will crash, because tpevent->progarray is NULL The fix makes sure the perfeventdetachbpfprog checks progarray is valid before it tries to remove the bpf program from it. [1] https://lore.kernel.org/bpf/Z1MR6dCIKajNS6nU@krava/T/#m91dbf0688221ec7a7fc95e896a7ef9ff93b0b8ad(CVE-2024-56665)

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix UAF via mismatching bpfprog/attachment RCU flavors Uprobes always use bpfprogrunarrayuprobe() under tasks-trace-RCU protection. But it is possible to attach a non-sleepable BPF program to a uprobe, and non-sleepable BPF programs are freed via normal RCU (see _bpfprogputnoref()). This leads to UAF of the bpfprog because a normal RCU grace period does not imply a tasks-trace-RCU grace period. Fix it by explicitly waiting for a tasks-trace-RCU grace period after removing the attachment of a bpfprog to a perfevent.(CVE-2024-56675)

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: drm/vc4: hdmi: Avoid hang with debug registers when suspended Trying to read /sys/kernel/debug/dri/1/hdmi1regs when the hdmi is disconnected results in a fatal system hang. This is due to the pm suspend code disabling the dvp clock. That is just a gate of the 108MHz clock in DVPHTRPIMISC_CONFIG, which results in accesses hanging AXI bus. Protect against this.(CVE-2024-56683)

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: brd: defer automatic disk creation until module initialization succeeds My colleague Wupeng found the following problems during fault injection: BUG: unable to handle page fault for address: fffffbfff809d073 PGD 6e648067 P4D 123ec8067 PUD 123ec4067 PMD 100e38067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 5 UID: 0 PID: 755 Comm: modprobe Not tainted 6.12.0-rc3+ #17 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:_asanload8+0x4c/0xa0 ... Call Trace: <TASK> blkdevputwhole+0x41/0x70 bdevrelease+0x1a3/0x250 blkdevrelease+0x11/0x20 _fput+0x1d7/0x4a0 taskworkrun+0xfc/0x180 syscallexittousermode+0x1de/0x1f0 dosyscall64+0x6b/0x170 entrySYSCALL64afterhwframe+0x76/0x7e loopinit() is calling loopadd() after _registerblkdev() succeeds and is ignoring diskadd() failure from loopadd(), for loopadd() failure is not fatal and successfully created disks are already visible to bdevopen(). brdinit() is currently calling brdalloc() before _registerblkdev() succeeds and is releasing successfully created disks when brdinit() returns an error. This can cause UAF for the latter two case: case 1: T1: modprobe brd brdinit brdalloc(0) // success adddisk diskscanpartitions bdevfileopenbydev // alloc file fput // won't free until back to userspace brdalloc(1) // failed since mem alloc error inject // error path for modprobe will release code segment // back to userspace _fput blkdevrelease bdevrelease blkdevputwhole bdev->bddisk->fops->release // fops is freed now, UAF! case 2: T1: T2: modprobe brd brdinit brdalloc(0) // success open(/dev/ram0) brdalloc(1) // fail // error path for modprobe close(/dev/ram0) ... /* UAF! */ bdev->bddisk->fops->release Fix this problem by following what loopinit() does. Besides, reintroduce brddevicesmutex to help serialize modifications to brdlist.(CVE-2024-56693)

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: bpf: Mark rawtp arguments with PTRMAYBENULL Arguments to a raw tracepoint are tagged as trusted, which carries the semantics that the pointer will be non-NULL. However, in certain cases, a raw tracepoint argument may end up being NULL. More context about this issue is available in [0]. Thus, there is a discrepancy between the reality, that rawtp arguments can actually be NULL, and the verifier's knowledge, that they are never NULL, causing explicit NULL checks to be deleted, and accesses to such pointers potentially crashing the kernel. To fix this, mark rawtp arguments as PTRMAYBENULL, and then special case the dereference and pointer arithmetic to permit it, and allow passing them into helpers/kfuncs; these exceptions are made for rawtp programs only. Ensure that we don't do this when refobjid > 0, as in that case this is an acquired object and doesn't need such adjustment. The reason we do maskrawtptrustedreg logic is because other will recheck in places whether the register is a trustedreg, and then consider our register as untrusted when detecting the presence of the PTRMAYBENULL flag. To allow safe dereference, we enable PROBEMEM marking when we see loads into trusted pointers with PTRMAYBENULL. While trusted rawtp arguments can also be passed into helpers or kfuncs where such broken assumption may cause issues, a future patch set will tackle their case separately, as PTRTOBTFID (without PTRTRUSTED) can already be passed into helpers and causes similar problems. Thus, they are left alone for now. It is possible that these checks also permit passing non-rawtp args that are trusted PTRTOBTFID with null marking. In such a case, allowing dereference when pointer is NULL expands allowed behavior, so won't regress existing programs, and the case of passing these into helpers is the same as above and will be dealt with later. Also update the failure case in tpbtfnullable selftest to capture the new behavior, as the verifier will no longer cause an error when directly dereference a raw tracepoint argument marked as _nullable. [0]: https://lore.kernel.org/bpf/ZrCZS6nisraEqehw@jlelli-thinkpadt14gen4.remote.csb(CVE-2024-56702)

In the Linux kernel, the following vulnerability has been resolved: EDAC/igen6: Avoid segmentation fault on module unload The segmentation fault happens because: During modprobe: 1. In igen6probe(), igen6pvt will be allocated with kzalloc() 2. In igen6registermci(), mci->pvtinfo will point to &igen6pvt->imc[mc] During rmmod: 1. In mcirelease() in edacmc.c, it will kfree(mci->pvtinfo) 2. In igen6remove(), it will kfree(igen6pvt); Fix this issue by setting mci->pvtinfo to NULL to avoid the double kfree.(CVE-2024-56708)

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: 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: f2fs: fix to avoid potential deadlock in f2fsrecordstopreason() syzbot reports deadlock issue of f2fs as below: ====================================================== WARNING: possible circular locking dependency detected 6.12.0-rc3-syzkaller-00087-gc964ced77262 #0 Not tainted ------------------------------------------------------ kswapd0/79 is trying to acquire lock: ffff888011824088 (&sbi->sblock){++++}-{3:3}, at: f2fsdownwrite fs/f2fs/f2fs.h:2199 [inline] ffff888011824088 (&sbi->sblock){++++}-{3:3}, at: f2fsrecordstopreason+0x52/0x1d0 fs/f2fs/super.c:4068 but task is already holding lock: ffff88804bd92610 (sbinternal#2){.+.+}-{0:0}, at: f2fsevictinode+0x662/0x15c0 fs/f2fs/inode.c:842 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (sbinternal#2){.+.+}-{0:0}: lockacquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 percpudownread include/linux/percpu-rwsem.h:51 [inline] _sbstartwrite include/linux/fs.h:1716 [inline] sbstartintwrite+0x4d/0x1c0 include/linux/fs.h:1899 f2fsevictinode+0x662/0x15c0 fs/f2fs/inode.c:842 evict+0x4e8/0x9b0 fs/inode.c:725 f2fsevictinode+0x1a4/0x15c0 fs/f2fs/inode.c:807 evict+0x4e8/0x9b0 fs/inode.c:725 disposelist fs/inode.c:774 [inline] pruneicachesb+0x239/0x2f0 fs/inode.c:963 supercachescan+0x38c/0x4b0 fs/super.c:223 doshrinkslab+0x701/0x1160 mm/shrinker.c:435 shrinkslab+0x1093/0x14d0 mm/shrinker.c:662 shrinkone+0x43b/0x850 mm/vmscan.c:4818 shrinkmany mm/vmscan.c:4879 [inline] lrugenshrinknode mm/vmscan.c:4957 [inline] shrinknode+0x3799/0x3de0 mm/vmscan.c:5937 kswapdshrinknode mm/vmscan.c:6765 [inline] balancepgdat mm/vmscan.c:6957 [inline] kswapd+0x1ca3/0x3700 mm/vmscan.c:7226 kthread+0x2f0/0x390 kernel/kthread.c:389 retfromfork+0x4b/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:244 -> #1 (fsreclaim){+.+.}-{0:0}: lockacquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 _fsreclaimacquire mm/pagealloc.c:3834 [inline] fsreclaimacquire+0x88/0x130 mm/pagealloc.c:3848 mightalloc include/linux/sched/mm.h:318 [inline] prepareallocpages+0x147/0x5b0 mm/pagealloc.c:4493 _allocpagesnoprof+0x16f/0x710 mm/pagealloc.c:4722 allocpagesmpolnoprof+0x3e8/0x680 mm/mempolicy.c:2265 allocpagesnoprof mm/mempolicy.c:2345 [inline] folioallocnoprof+0x128/0x180 mm/mempolicy.c:2352 filemapallocfolionoprof+0xdf/0x500 mm/filemap.c:1010 doreadcachefolio+0x2eb/0x850 mm/filemap.c:3787 readmappingfolio include/linux/pagemap.h:1011 [inline] f2fscommitsuper+0x3c0/0x7d0 fs/f2fs/super.c:4032 f2fsrecordstopreason+0x13b/0x1d0 fs/f2fs/super.c:4079 f2fshandlecriticalerror+0x2ac/0x5c0 fs/f2fs/super.c:4174 f2fswriteinode+0x35f/0x4d0 fs/f2fs/inode.c:785 writeinode fs/fs-writeback.c:1503 [inline] _writebacksingleinode+0x711/0x10d0 fs/fs-writeback.c:1723 writebacksingleinode+0x1f3/0x660 fs/fs-writeback.c:1779 syncinodemetadata+0xc4/0x120 fs/fs-writeback.c:2849 f2fsreleasefile+0xa8/0x100 fs/f2fs/file.c:1941 _fput+0x23f/0x880 fs/filetable.c:431 taskworkrun+0x24f/0x310 kernel/taskwork.c:228 resumeusermodework include/linux/resumeusermode.h:50 [inline] exittousermodeloop kernel/entry/common.c:114 [inline] exittousermodeprepare include/linux/entry-common.h:328 [inline] _syscallexittousermodework kernel/entry/common.c:207 [inline] syscallexittousermode+0x168/0x370 kernel/entry/common.c:218 dosyscall64+0x100/0x230 arch/x86/entry/common.c:89 entrySYSCALL64after_hwframe+0x77/0x7f ---truncated---(CVE-2024-56744)

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: drm/nouveau/gr/gf100: Fix missing unlock in gf100grchannew() When the call to gf100grctxgenerate() fails, unlock gr->fecs.mutex before returning the error. Fixes smatch warning: drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:480 gf100grchannew() warn: inconsistent returns '&gr->fecs.mutex'.(CVE-2024-56752)