OESA-2024-2367

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Add NULL pointer check for kzalloc

[Why & How] Check return pointer of kzalloc before using it.(CVE-2024-42122)

In the Linux kernel, the following vulnerability has been resolved:

mm: gup: stop abusing trygrabfolio

A kernel warning was reported when pinning folio in CMA memory when launching SEV virtual machine. The splat looks like:

[ 464.325306] WARNING: CPU: 13 PID: 6734 at mm/gup.c:1313 getuserpages+0x423/0x520 [ 464.325464] CPU: 13 PID: 6734 Comm: qemu-kvm Kdump: loaded Not tainted 6.6.33+ #6 [ 464.325477] RIP: 0010:getuserpages+0x423/0x520 [ 464.325515] Call Trace: [ 464.325520] <TASK> [ 464.325523] ? _getuserpages+0x423/0x520 [ 464.325528] ? _warn+0x81/0x130 [ 464.325536] ? _getuserpages+0x423/0x520 [ 464.325541] ? reportbug+0x171/0x1a0 [ 464.325549] ? handlebug+0x3c/0x70 [ 464.325554] ? excinvalidop+0x17/0x70 [ 464.325558] ? asmexcinvalidop+0x1a/0x20 [ 464.325567] ? _getuserpages+0x423/0x520 [ 464.325575] _guplongtermlocked+0x212/0x7a0 [ 464.325583] internalgetuserpagesfast+0xfb/0x190 [ 464.325590] pinuserpagesfast+0x47/0x60 [ 464.325598] sevpinmemory+0xca/0x170 [kvmamd] [ 464.325616] sevmemencregisterregion+0x81/0x130 [kvm_amd]

Per the analysis done by yangge, when starting the SEV virtual machine, it will call pinuserpagesfast(..., FOLLLONGTERM, ...) to pin the memory. But the page is in CMA area, so fast GUP will fail then fallback to the slow path due to the longterm pinnalbe check in trygrabfolio().

The slow path will try to pin the pages then migrate them out of CMA area. But the slow path also uses trygrabfolio() to pin the page, it will also fail due to the same check then the above warning is triggered.

In addition, the trygrabfolio() is supposed to be used in fast path and it elevates folio refcount by using add ref unless zero. We are guaranteed to have at least one stable reference in slow path, so the simple atomic add could be used. The performance difference should be trivial, but the misuse may be confusing and misleading.

Redefined trygrabfolio() to trygrabfoliofast(), and trygrabpage() to trygrab_folio(), and use them in the proper paths. This solves both the abuse and the kernel warning.

The proper naming makes their usecase more clear and should prevent from abusing in the future.

peterx said:

: The user will see the pin fails, for gpu-slow it further triggers the WARN : right below that failure (as in the original report): : : folio = trygrabfolio(page, pageincrem - 1, : follflags); : if (WARNONONCE(!folio)) { <------------------------ here : /* : * Release the 1st page ref if the : * folio is problematic, fail hard. : */ : gupputfolio(pagefolio(page), 1, : follflags); : ret = -EFAULT; : goto out; : }

[1] https://lore.kernel.org/linux-mm/1719478388-31917-1-git-send-email-yangge1116@126.com/

[shy828301@gmail.com: fix implicit declaration of function trygrabfolio_fast] Link: https://lkml.kernel.org/r/CAHbLzkowMSso-4Nufc9hcMehQsK9PNz3OSu-+eniU-2Mm-xjhA@mail.gmail.com(CVE-2024-44943)

In the Linux kernel, the following vulnerability has been resolved:

serial: sc16is7xx: fix TX fifo corruption

Sometimes, when a packet is received on channel A at almost the same time as a packet is about to be transmitted on channel B, we observe with a logic analyzer that the received packet on channel A is transmitted on channel B. In other words, the Tx buffer data on channel B is corrupted with data from channel A.

The problem appeared since commit 4409df5866b7 ("serial: sc16is7xx: change EFR lock to operate on each channels"), which changed the EFR locking to operate on each channel instead of chip-wise.

This commit has introduced a regression, because the EFR lock is used not only to protect the EFR registers access, but also, in a very obscure and undocumented way, to protect access to the data buffer, which is shared by the Tx and Rx handlers, but also by each channel of the IC.

Fix this regression first by switching to kfifooutlinearptr() in sc16is7xxhandle_tx() to eliminate the need for a shared Rx/Tx buffer.

Secondly, replace the chip-wise Rx buffer with a separate Rx buffer for each channel.(CVE-2024-44951)

In the Linux kernel, the following vulnerability has been resolved:

memcgwriteevent_control(): fix a user-triggerable oops

we are not guaranteed that anything past the terminating NUL is mapped (let alone initialized with anything sane).(CVE-2024-45021)

In the Linux kernel, the following vulnerability has been resolved:

pinctrl: single: fix potential NULL dereference in pcsgetfunction()

pinmuxgenericgetfunction() can return NULL and the pointer 'function' was dereferenced without checking against NULL. Add checking of pointer 'function' in pcsget_function().

Found by code review.(CVE-2024-46685)

In the Linux kernel, the following vulnerability has been resolved:

thunderbolt: Mark XDomain as unplugged when router is removed

I noticed that when we do discrete host router NVM upgrade and it gets hot-removed from the PCIe side as a result of NVM firmware authentication, if there is another host connected with enabled paths we hang in tearing them down. This is due to fact that the Thunderbolt networking driver also tries to cleanup the paths and ends up blocking in tbdisconnectxdomain_paths() waiting for the domain lock.

However, at this point we already cleaned the paths in tbstop() so there is really no need for tbdisconnectxdomainpaths() to do that anymore. Furthermore it already checks if the XDomain is unplugged and bails out early so take advantage of that and mark the XDomain as unplugged when we remove the parent router.(CVE-2024-46702)

In the Linux kernel, the following vulnerability has been resolved:

ublkdrv: fix NULL pointer dereference in ublkctrlstartrecovery()

When two UBLKCMDSTARTUSERRECOVERY commands are submitted, the first one sets 'ubq->ubqdaemon' to NULL, and the second one triggers WARN in ublkqueue_reinit() and subsequently a NULL pointer dereference issue.

Fix it by adding the check in ublkctrlstartrecovery() and return immediately in case of zero 'ub->nrqueues_ready'.

BUG: kernel NULL pointer dereference, address: 0000000000000028 RIP: 0010:ublkctrlstartrecovery.constprop.0+0x82/0x180 Call Trace: <TASK> ? _die+0x20/0x70 ? pagefaultoops+0x75/0x170 ? excpagefault+0x64/0x140 ? asmexcpagefault+0x22/0x30 ? ublkctrlstartrecovery.constprop.0+0x82/0x180 ublkctrluringcmd+0x4f7/0x6c0 ? picknexttaskidle+0x26/0x40 iouringcmd+0x9a/0x1b0 ioissuesqe+0x193/0x3f0 iowqsubmitwork+0x9b/0x390 ioworkerhandlework+0x165/0x360 iowqworker+0xcb/0x2f0 ? finishtaskswitch.isra.0+0x203/0x290 ? finishtaskswitch.isra.0+0x203/0x290 ? _pfxiowqworker+0x10/0x10 retfromfork+0x2d/0x50 ? _pfxiowqworker+0x10/0x10 retfromfork_asm+0x1a/0x30 </TASK>(CVE-2024-46735)

In the Linux kernel, the following vulnerability has been resolved:

of/irq: Prevent device address out-of-bounds read in interrupt map walk

When ofirqparseraw() is invoked with a device address smaller than the interrupt parent node (from #address-cells property), KASAN detects the following out-of-bounds read when populating the initial match table (dyndbg="func ofirqparse* +p"):

OF: ofirqparseone: dev=/soc@0/picasso/watchdog, index=0 OF: parent=/soc@0/pci@878000000000/gpio0@17,0, intsize=2 OF: intspec=4 OF: ofirqparseraw: ipar=/soc@0/pci@878000000000/gpio0@17,0, size=2 OF: -> addrsize=3 ================================================================== BUG: KASAN: slab-out-of-bounds in ofirqparse_raw+0x2b8/0x8d0 Read of size 4 at addr ffffff81beca5608 by task bash/764

CPU: 1 PID: 764 Comm: bash Tainted: G O 6.1.67-484c613561-nokiasmarm64 #1 Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.01-12.24.03-dirty 01/01/2023 Call trace: dumpbacktrace+0xdc/0x130 showstack+0x1c/0x30 dumpstacklvl+0x6c/0x84 printreport+0x150/0x448 kasanreport+0x98/0x140 _asanload4+0x78/0xa0 ofirqparseraw+0x2b8/0x8d0 ofirqparseone+0x24c/0x270 parseinterrupts+0xc0/0x120 offwnodeaddlinks+0x100/0x2d0 fwdevlinkparsefwtree+0x64/0xc0 deviceadd+0xb38/0xc30 ofdeviceadd+0x64/0x90 ofplatformdevicecreatepdata+0xd0/0x170 ofplatformbuscreate+0x244/0x600 ofplatformnotify+0x1b0/0x254 blockingnotifiercallchain+0x9c/0xd0 _ofchangesetentrynotify+0x1b8/0x230 _ofchangesetapplynotify+0x54/0xe4 ofoverlayfdt_apply+0xc04/0xd94 ...

The buggy address belongs to the object at ffffff81beca5600 which belongs to the cache kmalloc-128 of size 128 The buggy address is located 8 bytes inside of 128-byte region [ffffff81beca5600, ffffff81beca5680)

The buggy address belongs to the physical page: page:00000000230d3d03 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1beca4 head:00000000230d3d03 order:1 compoundmapcount:0 compoundpincount:0 flags: 0x8000000000010200(slab|head|zone=2) raw: 8000000000010200 0000000000000000 dead000000000122 ffffff810000c300 raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffffff81beca5500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffffff81beca5580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffffff81beca5600: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffffff81beca5680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffffff81beca5700: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc ================================================================== OF: -> got it !

Prevent the out-of-bounds read by copying the device address into a buffer of sufficient size.(CVE-2024-46743)

In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check BIOS images before it is used

BIOS images may fail to load and null checks are added before they are used.

This fixes 6 NULL_RETURNS issues reported by Coverity.(CVE-2024-46809)

In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check numvalidsets before accessing readerwmsets[]

[WHY & HOW] numvalidsets needs to be checked to avoid a negative index when accessing readerwmsets[numvalidsets - 1].

This fixes an OVERRUN issue reported by Coverity.(CVE-2024-46815)

In the Linux kernel, the following vulnerability has been resolved:

iommufd: Require drivers to supply the cacheinvalidateuser ops

If drivers don't do this then iommufd will oops invalidation ioctls with something like:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000004 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101059000 [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP Modules linked in: CPU: 2 PID: 371 Comm: qemu-system-aar Not tainted 6.8.0-rc7-gde77230ac23a #9 Hardware name: linux,dummy-virt (DT) pstate: 81400809 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=-c) pc : 0x0 lr : iommufdhwptinvalidate+0xa4/0x204 sp : ffff800080f3bcc0 x29: ffff800080f3bcf0 x28: ffff0000c369b300 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 x23: 0000000000000000 x22: 00000000c1e334a0 x21: ffff0000c1e334a0 x20: ffff800080f3bd38 x19: ffff800080f3bd58 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffff8240d6d8 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000001000000002 x7 : 0000fffeac1ec950 x6 : 0000000000000000 x5 : ffff800080f3bd78 x4 : 0000000000000003 x3 : 0000000000000002 x2 : 0000000000000000 x1 : ffff800080f3bcc8 x0 : ffff0000c6034d80 Call trace: 0x0 iommufdfopsioctl+0x154/0x274 _arm64sysioctl+0xac/0xf0 invokesyscall+0x48/0x110 el0svccommon.constprop.0+0x40/0xe0 doel0svc+0x1c/0x28 el0svc+0x34/0xb4 el0t64synchandler+0x120/0x12c el0t64sync+0x190/0x194

All existing drivers implement this op for nesting, this is mostly a bisection aid.(CVE-2024-46824)

In the Linux kernel, the following vulnerability has been resolved:

net: microchip: vcap: Fix use-after-free error in kunit test

This is a clear use-after-free error. We remove it, and rely on checking the return code of vcapdelrule.(CVE-2024-46831)

In the Linux kernel, the following vulnerability has been resolved: vfs: fix race between eviceinodes() and findinode()&iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs. Let's assume there's a inode (ie ino 261) with icount 1 is called by iput(), and there's a concurrent thread calling genericshutdownsuper(). cpu0: cpu1: iput() // icount is 1 ->spinlock(inode) ->dec icount to 0 ->iputfinal() genericshutdownsuper() ->inodeaddlru() ->evictinodes() // cause some reason[2] ->if (atomicread(inode->icount)) continue; // return before // inode 261 passed the above check // listlruaddobj() // and then schedule out ->spinunlock() // note here: the inode 261 // was still at sb list and hash list, // and IFREEING|IWILLFREE was not been set btrfsiget() // after some function calls ->findinode() // found the above inode 261 ->spinlock(inode) // check IFREEING|IWILLFREE // and passed ->iget() ->spinunlock(inode) // schedule back ->spinlock(inode) // check (INEW|IFREEING|IWILLFREE) flags, // passed and set IFREEING iput() ->spinunlock(inode) ->spinlock(inode) ->evict() // dec icount to 0 ->iputfinal() ->spinunlock() ->evict() Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->istate & ICLEAR) statement both within clearinode() and iput(). To fix the bug, recheck the inode->icount after holding ilock. Because in the most scenarios, the first check is valid, and the overhead of spinlock() can be reduced. If there is any misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SBACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug.(CVE-2024-47679)

In the Linux kernel, the following vulnerability has been resolved: ep93xx: clock: Fix off by one in ep93xxdivrecalcrate() The psc->div[] array has psc->numdiv elements. These values come from when we call clkhwregisterdiv(). It's adcdivisors and ARRAYSIZE(adcdivisors)) and so on. So this condition needs to be >= instead of > to prevent an out of bounds read.(CVE-2024-47686)

In the Linux kernel, the following vulnerability has been resolved: driver core: Fix a potential null-ptr-deref in moduleadddriver() Inject fault while probing of-fpga-region, if kasprintf() fails in moduleadddriver(), the second sysfsremovelink() in exit path will cause null-ptr-deref as below because kernfsnamehash() will call strlen() with NULL drivername. Fix it by releasing resources based on the exit path sequence. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [dfffffc000000000] address between user and kernel address ranges Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: offpgaregion(+) fpgaregion fpgabridge cfg80211 rfkill 8021q garp mrp stp llc ipv6 [last unloaded: offpgaregion] CPU: 2 UID: 0 PID: 2036 Comm: modprobe Not tainted 6.11.0-rc2-g6a0e38264012 #295 Hardware name: linux,dummy-virt (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : strlen+0x24/0xb0 lr : kernfsnamehash+0x1c/0xc4 sp : ffffffc081f97380 x29: ffffffc081f97380 x28: ffffffc081f97b90 x27: ffffff80c821c2a0 x26: ffffffedac0be418 x25: 0000000000000000 x24: ffffff80c09d2000 x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000 x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000001840 x17: 0000000000000000 x16: 0000000000000000 x15: 1ffffff8103f2e42 x14: 00000000f1f1f1f1 x13: 0000000000000004 x12: ffffffb01812d61d x11: 1ffffff01812d61c x10: ffffffb01812d61c x9 : dfffffc000000000 x8 : 0000004fe7ed29e4 x7 : ffffff80c096b0e7 x6 : 0000000000000001 x5 : ffffff80c096b0e0 x4 : 1ffffffdb990efa2 x3 : 0000000000000000 x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000000 Call trace: strlen+0x24/0xb0 kernfsnamehash+0x1c/0xc4 kernfsfindns+0x118/0x2e8 kernfsremovebynamens+0x80/0x100 sysfsremovelink+0x74/0xa8 moduleadddriver+0x278/0x394 busadddriver+0x1f0/0x43c driverregister+0xf4/0x3c0 _platformdriverregister+0x60/0x88 offpgaregioninit+0x20/0x1000 [offpgaregion] dooneinitcall+0x110/0x788 doinitmodule+0x1dc/0x5c8 loadmodule+0x3c38/0x4cac initmodulefromfile+0xd4/0x128 idempotentinitmodule+0x2cc/0x528 _arm64sysfinitmodule+0xac/0x100 invokesyscall+0x6c/0x258 el0svccommon.constprop.0+0x160/0x22c doel0svc+0x44/0x5c el0svc+0x48/0xb8 el0t64synchandler+0x13c/0x158 el0t64_sync+0x190/0x194 Code: f2fbffe1 a90157f4 12000802 aa0003f5 (38e16861) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception(CVE-2024-47688)

In the Linux kernel, the following vulnerability has been resolved: f2fs: get rid of online repaire on corrupted directory syzbot reports a f2fs bug as below: kernel BUG at fs/f2fs/inode.c:896! RIP: 0010:f2fsevictinode+0x1598/0x15c0 fs/f2fs/inode.c:896 Call Trace: evict+0x532/0x950 fs/inode.c:704 disposelist fs/inode.c:747 [inline] evictinodes+0x5f9/0x690 fs/inode.c:797 genericshutdownsuper+0x9d/0x2d0 fs/super.c:627 killblocksuper+0x44/0x90 fs/super.c:1696 killf2fssuper+0x344/0x690 fs/f2fs/super.c:4898 deactivatelockedsuper+0xc4/0x130 fs/super.c:473 cleanupmnt+0x41f/0x4b0 fs/namespace.c:1373 taskworkrun+0x24f/0x310 kernel/taskwork.c:228 ptracenotify+0x2d2/0x380 kernel/signal.c:2402 ptracereportsyscall include/linux/ptrace.h:415 [inline] ptracereportsyscallexit include/linux/ptrace.h:477 [inline] syscallexitwork+0xc6/0x190 kernel/entry/common.c:173 syscallexittousermodeprepare kernel/entry/common.c:200 [inline] _syscallexittousermodework kernel/entry/common.c:205 [inline] syscallexittousermode+0x279/0x370 kernel/entry/common.c:218 dosyscall64+0x100/0x230 arch/x86/entry/common.c:89 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0010:f2fsevictinode+0x1598/0x15c0 fs/f2fs/inode.c:896 Online repaire on corrupted directory in f2fslookup() can generate dirty data/meta while racing w/ readonly remount, it may leave dirty inode after filesystem becomes readonly, however, checkpoint() will skips flushing dirty inode in a state of readonly mode, result in above panic. Let's get rid of online repaire in f2fs_lookup(), and leave the work to fsck.f2fs.(CVE-2024-47690)

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid use-after-free in f2fsstopgcthread() syzbot reports a f2fs bug as below: _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:114 printreport+0xe8/0x550 mm/kasan/report.c:491 kasanreport+0x143/0x180 mm/kasan/report.c:601 kasancheckrange+0x282/0x290 mm/kasan/generic.c:189 instrumentatomicreadwrite include/linux/instrumented.h:96 [inline] atomicfetchaddrelaxed include/linux/atomic/atomic-instrumented.h:252 [inline] _refcountadd include/linux/refcount.h:184 [inline] _refcountinc include/linux/refcount.h:241 [inline] refcountinc include/linux/refcount.h:258 [inline] gettaskstruct include/linux/sched/task.h:118 [inline] kthreadstop+0xca/0x630 kernel/kthread.c:704 f2fsstopgcthread+0x65/0xb0 fs/f2fs/gc.c:210 f2fsdoshutdown+0x192/0x540 fs/f2fs/file.c:2283 f2fsiocshutdown fs/f2fs/file.c:2325 [inline] _f2fsioctl+0x443a/0xbe60 fs/f2fs/file.c:4325 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:907 [inline] _sesysioctl+0xfc/0x170 fs/ioctl.c:893 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f The root cause is below race condition, it may cause use-after-free issue in sbi->gcth pointer. - remount - f2fsremount - f2fsstopgcthread - kfree(gcth) - f2fsiocshutdown - f2fsdoshutdown - f2fsstopgcthread - kthreadstop(gcth->f2fsgctask) : sbi->gcthread = NULL; We will call f2fsdoshutdown() in two paths: - for f2fsiocshutdown() path, we should grab sb->sumount semaphore for fixing. - for f2fsshutdown() path, it's safe since caller has already grabbed sb->sumount semaphore.(CVE-2024-47691)

In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix WARNING:atkernel/workqueue.c:#checkflushdependency In the commit aee2424246f9 ("RDMA/iwcm: Fix a use-after-free related to destroying CM IDs"), the function flushworkqueue is invoked to flush the work queue iwcmwq. But at that time, the work queue iwcmwq was created via the function allocorderedworkqueue without the flag WQMEMRECLAIM. Because the current process is trying to flush the whole iwcmwq, if iwcmwq doesn't have the flag WQMEMRECLAIM, verify that the current process is not reclaiming memory or running on a workqueue which doesn't have the flag WQMEMRECLAIM as that can break forward-progress guarantee leading to a deadlock. The call trace is as below: [ 125.350876][ T1430] Call Trace: [ 125.356281][ T1430] <TASK> [ 125.361285][ T1430] ? warn (kernel/panic.c:693) [ 125.367640][ T1430] ? checkflushdependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.375689][ T1430] ? reportbug (lib/bug.c:180 lib/bug.c:219) [ 125.382505][ T1430] ? handlebug (arch/x86/kernel/traps.c:239) [ 125.388987][ T1430] ? excinvalidop (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 125.395831][ T1430] ? asmexcinvalidop (arch/x86/include/asm/idtentry.h:621) [ 125.403125][ T1430] ? checkflushdependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.410984][ T1430] ? checkflushdependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.418764][ T1430] _flushworkqueue (kernel/workqueue.c:3970) [ 125.426021][ T1430] ? _pfxmightresched (kernel/sched/core.c:10151) [ 125.433431][ T1430] ? destroycmid (drivers/infiniband/core/iwcm.c:375) iwcm [ 125.441209][ T1430] ? pfxflushworkqueue (kernel/workqueue.c:3910) [ 125.473900][ T1430] ? _rawspinlockirqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlockapismp.h:111 kernel/locking/spinlock.c:162) [ 125.473909][ T1430] ? pfxrawspinlockirqsave (kernel/locking/spinlock.c:161) [ 125.482537][ T1430] _destroyid (drivers/infiniband/core/cma.c:2044) rdmacm [ 125.495072][ T1430] nvmerdmafreequeue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvmerdma [ 125.505827][ T1430] nvmerdmaresetctrlwork (drivers/nvme/host/rdma.c:2180) nvmerdma [ 125.505831][ T1430] processonework (kernel/workqueue.c:3231) [ 125.515122][ T1430] workerthread (kernel/workqueue.c:3306 kernel/workqueue.c:3393) [ 125.515127][ T1430] ? _pfxworkerthread (kernel/workqueue.c:3339) [ 125.531837][ T1430] kthread (kernel/kthread.c:389) [ 125.539864][ T1430] ? _pfxkthread (kernel/kthread.c:342) [ 125.550628][ T1430] retfromfork (arch/x86/kernel/process.c:147) [ 125.558840][ T1430] ? _pfxkthread (kernel/kthread.c:342) [ 125.558844][ T1430] retfromforkasm (arch/x86/entry/entry64.S:257) [ 125.566487][ T1430] </TASK> [ 125.566488][ T1430] ---[ end trace 0000000000000000 ]---(CVE-2024-47696)

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential null-ptr-deref in nilfsbtreeinsert() Patch series "nilfs2: fix potential issues with empty b-tree nodes". This series addresses three potential issues with empty b-tree nodes that can occur with corrupted filesystem images, including one recently discovered by syzbot. This patch (of 3): If a b-tree is broken on the device, and the b-tree height is greater than 2 (the level of the root node is greater than 1) even if the number of child nodes of the b-tree root is 0, a NULL pointer dereference occurs in nilfsbtreeprepareinsert(), which is called from nilfsbtreeinsert(). This is because, when the number of child nodes of the b-tree root is 0, nilfsbtreedolookup() does not set the block buffer head in any of path[x].bpbh, leaving it as the initial value of NULL, but if the level of the b-tree root node is greater than 1, nilfsbtreegetnonrootnode(), which accesses the buffer memory of path[x].bpbh, is called. Fix this issue by adding a check to nilfsbtreeroot_broken(), which performs sanity checks when reading the root node from the device, to detect this inconsistency. Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause early on.(CVE-2024-47699)

In the Linux kernel, the following vulnerability has been resolved: ext4: check stripe size compatibility on remount as well We disable stripe size in _ext4fillsuper if it is not a multiple of the cluster ratio however this check is missed when trying to remount. This can leave us with cases where stripe < clusterratio after remount:set making EXT4B2C(sbi->sstripe) become 0 that can cause some unforeseen bugs like divide by 0. Fix that by adding the check in remount path as well.(CVE-2024-47700)

In the Linux kernel, the following vulnerability has been resolved: ext4: avoid OOB when system.data xattr changes underneath the filesystem When looking up for an entry in an inlined directory, if evalueoffs is changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds access that KASAN detects as an UAF. EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity change from 2048 to 2047 ================================================================== BUG: KASAN: use-after-free in ext4searchdir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103 CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> _dumpstack lib/dumpstack.c:93 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:119 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x169/0x550 mm/kasan/report.c:488 kasanreport+0x143/0x180 mm/kasan/report.c:601 ext4searchdir+0xf2/0x1c0 fs/ext4/namei.c:1500 ext4findinlineentry+0x4be/0x5e0 fs/ext4/inline.c:1697 _ext4findentry+0x2b4/0x1b30 fs/ext4/namei.c:1573 ext4lookupentry fs/ext4/namei.c:1727 [inline] ext4lookup+0x15f/0x750 fs/ext4/namei.c:1795 lookuponeqstrexcl+0x11f/0x260 fs/namei.c:1633 filenamecreate+0x297/0x540 fs/namei.c:3980 dosymlinkat+0xf9/0x3a0 fs/namei.c:4587 _dosyssymlinkat fs/namei.c:4610 [inline] _sesyssymlinkat fs/namei.c:4607 [inline] _x64syssymlinkat+0x95/0xb0 fs/namei.c:4607 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f3e73ced469 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 18 00 00 90 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 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIGRAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0 </TASK> Calling ext4xattribodyfind right after reading the inode with ext4getinodeloc will lead to a check of the validity of the xattrs, avoiding this problem.(CVE-2024-47701)

In the Linux kernel, the following vulnerability has been resolved: bpf, lsm: Add check for BPF LSM return value A bpf prog returning a positive number attached to fileallocsecurity hook makes kernel panic. This happens because file system can not filter out the positive number returned by the LSM prog using ISERR, and misinterprets this positive number as a file pointer. Given that hook filealloc_security never returned positive number before the introduction of BPF LSM, and other BPF LSM hooks may encounter similar issues, this patch adds LSM return value check in verifier, to ensure no unexpected value is returned.(CVE-2024-47703)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check linkres->hpodplinkenc before using it [WHAT & HOW] Functions dpenablelinkphy and dpdisablelinkphy can pass linkres without initializing hpodplinkenc and it is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.(CVE-2024-47704)

In the Linux kernel, the following vulnerability has been resolved: block: fix potential invalid pointer dereference in blkaddpartition The blkaddpartition() function initially used a single if-condition (ISERR(part)) to check for errors when adding a partition. This was modified to handle the specific case of -ENXIO separately, allowing the function to proceed without logging the error in this case. However, this change unintentionally left a path where mdautodetectdev() could be called without confirming that part is a valid pointer. This commit separates the error handling logic by splitting the initial if-condition, improving code readability and handling specific error scenarios explicitly. The function now distinguishes the general error case from -ENXIO without altering the existing behavior of mdautodetect_dev() calls.(CVE-2024-47705)

In the Linux kernel, the following vulnerability has been resolved: iommufd: Protect against overflow of ALIGN() during iova allocation Userspace can supply an iova and uptr such that the target iova alignment becomes really big and ALIGN() overflows which corrupts the selected area range during allocation. CONFIGIOMMUFDTEST can detect this: WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/iopagetable.c:268 ioptallocareapages drivers/iommu/iommufd/iopagetable.c:268 [inline] WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/iopagetable.c:268 ioptmappages+0xf95/0x1050 drivers/iommu/iommufd/iopagetable.c:352 Modules linked in: CPU: 1 PID: 5092 Comm: syz-executor294 Not tainted 6.10.0-rc5-syzkaller-00294-g3ffea9a7a6f7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 RIP: 0010:ioptallocareapages drivers/iommu/iommufd/iopagetable.c:268 [inline] RIP: 0010:ioptmappages+0xf95/0x1050 drivers/iommu/iommufd/iopagetable.c:352 Code: fc e9 a4 f3 ff ff e8 1a 8b 4c fc 41 be e4 ff ff ff e9 8a f3 ff ff e8 0a 8b 4c fc 90 0f 0b 90 e9 37 f5 ff ff e8 fc 8a 4c fc 90 <0f> 0b 90 e9 68 f3 ff ff 48 c7 c1 ec 82 ad 8f 80 e1 07 80 c1 03 38 RSP: 0018:ffffc90003ebf9e0 EFLAGS: 00010293 RAX: ffffffff85499fa4 RBX: 00000000ffffffef RCX: ffff888079b49e00 RDX: 0000000000000000 RSI: 00000000ffffffef RDI: 0000000000000000 RBP: ffffc90003ebfc50 R08: ffffffff85499b30 R09: ffffffff85499942 R10: 0000000000000002 R11: ffff888079b49e00 R12: ffff8880228e0010 R13: 0000000000000000 R14: 1ffff920007d7f68 R15: ffffc90003ebfd00 FS: 000055557d760380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000005fdeb8 CR3: 000000007404a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> iommufdioascopy+0x610/0x7b0 drivers/iommu/iommufd/ioas.c:274 iommufdfopsioctl+0x4d9/0x5a0 drivers/iommu/iommufd/main.c:421 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:907 [inline] _sesysioctl+0xfc/0x170 fs/ioctl.c:893 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f Cap the automatic alignment to the huge page size, which is probably a better idea overall. Huge automatic alignments can fragment and chew up the available IOVA space without any reason.(CVE-2024-47719)

In the Linux kernel, the following vulnerability has been resolved: x86/tdx: Fix "in-kernel MMIO" check TDX only supports kernel-initiated MMIO operations. The handlemmio() function checks if the #VE exception occurred in the kernel and rejects the operation if it did not. However, userspace can deceive the kernel into performing MMIO on its behalf. For example, if userspace can point a syscall to an MMIO address, syscall does getuser() or put_user() on it, triggering MMIO #VE. The kernel will treat the #VE as in-kernel MMIO. Ensure that the target MMIO address is within the kernel before decoding instruction.(CVE-2024-47727)

In the Linux kernel, the following vulnerability has been resolved: padata: use integer wrap around to prevent deadlock on seqnr overflow When submitting more than 2^32 padata objects to padatadoserial, the current sorting implementation incorrectly sorts padata objects with overflowed seqnr, causing them to be placed before existing objects in the reorder list. This leads to a deadlock in the serialization process as padatafindnext cannot match padata->seqnr and pd->processed because the padata instance with overflowed seqnr will be selected next. To fix this, we use an unsigned integer wrap around to correctly sort padata objects in scenarios with integer overflow.(CVE-2024-47739)

In the Linux kernel, the following vulnerability has been resolved: firmwareloader: Block path traversal Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such. However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are: - lpfcsli4requestfirmwareupdate() seems to construct the firmware filename from "ModelName", a string that was previously parsed out of some descriptor ("Vital Product Data") in lpfcfillvpd() - nfpnetfwfind() seems to construct a firmware filename from a model name coming from nfphwinfolookup(pf->hwinfo, "nffw.partno"), which I think parses some descriptor that was read from the device. (But this case likely isn't exploitable because the format string looks like "netronome/nic%s", and there shouldn't be any *folders* starting with "netronome/nic". The previous case was different because there, the "%s" is at the start of the format string.) - moduleflashfwschedule() is reachable from the ETHTOOLMSGMODULEFWFLASHACT netlink command, which is marked as GENLUNSADMINPERM (meaning CAPNETADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-provided firmware name. (But I think to reach this case, you need to have CAPNET_ADMIN over a network namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack path in practice.) Fix it by rejecting any firmware names containing ".." path components. For what it's worth, I went looking and haven't found any USB device drivers that use the firmware loader dangerously.(CVE-2024-47742)

In the Linux kernel, the following vulnerability has been resolved: KVM: Use dedicated mutex to protect kvmusagecount to avoid deadlock Use a dedicated mutex to guard kvmusagecount to fix a potential deadlock on x86 due to a chain of locks and SRCU synchronizations. Translating the below lockdep splat, CPU1 #6 will wait on CPU0 #1, CPU0 #8 will wait on CPU2 #3, and CPU2 #7 will wait on CPU1 #4 (if there's a writer, due to the fairness of r/w semaphores). CPU0 CPU1 CPU2 1 lock(&kvm->slotslock); 2 lock(&vcpu->mutex); 3 lock(&kvm->srcu); 4 lock(cpuhotpluglock); 5 lock(kvmlock); 6 lock(&kvm->slotslock); 7 lock(cpuhotpluglock); 8 sync(&kvm->srcu); Note, there are likely more potential deadlocks in KVM x86, e.g. the same pattern of taking cpuhotpluglock outside of kvmlock likely exists with _kvmclockcpufreqnotifier(): cpuhpcpufreqonline() | -> cpufreqonline() | -> cpufreqgovperformancelimits() | -> _cpufreqdrivertarget() | -> _targetindex() | -> cpufreqfreqtransitionbegin() | -> cpufreqnotifytransition() | -> ... _kvmclockcpufreqnotifier() But, actually triggering such deadlocks is beyond rare due to the combination of dependencies and timings involved. E.g. the cpufreq notifier is only used on older CPUs without a constant TSC, mucking with the NX hugepage mitigation while VMs are running is very uncommon, and doing so while also onlining/offlining a CPU (necessary to generate contention on cpuhotpluglock) would be even more unusual. The most robust solution to the general cpuhotpluglock issue is likely to switch vmlist to be an RCU-protected list, e.g. so that x86's cpufreq notifier doesn't to take kvmlock. For now, settle for fixing the most blatant deadlock, as switching to an RCU-protected list is a much more involved change, but add a comment in locking.rst to call out that care needs to be taken when walking holding kvmlock and walking vmlist. ====================================================== WARNING: possible circular locking dependency detected 6.10.0-smp--c257535a0c9d-pip #330 Tainted: G S O ------------------------------------------------------ tee/35048 is trying to acquire lock: ff6a80eced71e0a8 (&kvm->slotslock){+.+.}-{3:3}, at: setnxhugepages+0x179/0x1e0 [kvm] but task is already holding lock: ffffffffc07abb08 (kvmlock){+.+.}-{3:3}, at: setnxhugepages+0x14a/0x1e0 [kvm] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (kvmlock){+.+.}-{3:3}: _mutexlock+0x6a/0xb40 mutexlocknested+0x1f/0x30 kvmdevioctl+0x4fb/0xe50 [kvm] _sesysioctl+0x7b/0xd0 _x64sysioctl+0x21/0x30 x64syscall+0x15d0/0x2e60 dosyscall64+0x83/0x160 entrySYSCALL64afterhwframe+0x76/0x7e -> #2 (cpuhotpluglock){++++}-{0:0}: cpusreadlock+0x2e/0xb0 statickeyslowinc+0x16/0x30 kvmlapicsetbase+0x6a/0x1c0 [kvm] kvmsetapicbase+0x8f/0xe0 [kvm] kvmsetmsrcommon+0x9ae/0xf80 [kvm] vmxsetmsr+0xa54/0xbe0 [kvmintel] _kvmsetmsr+0xb6/0x1a0 [kvm] kvmarchvcpuioctl+0xeca/0x10c0 [kvm] kvmvcpuioctl+0x485/0x5b0 [kvm] _sesysioctl+0x7b/0xd0 _x64sysioctl+0x21/0x30 x64syscall+0x15d0/0x2e60 dosyscall64+0x83/0x160 entrySYSCALL64afterhwframe+0x76/0x7e -> #1 (&kvm->srcu){.+.+}-{0:0}: _synchronizesrcu+0x44/0x1a0 ---truncated---(CVE-2024-47744)

In the Linux kernel, the following vulnerability has been resolved: vhostvdpa: assign irq bypass producer token correctly We used to call irqbypassunregisterproducer() in vhostvdpasetupvqirq() which is problematic as we don't know if the token pointer is still valid or not. Actually, we use the eventfdctx as the token so the life cycle of the token should be bound to the VHOSTSETVRINGCALL instead of vhostvdpasetupvqirq() which could be called by setstatus(). Fixing this by setting up irq bypass producer's token when handling VHOSTSETVRINGCALL and un-registering the producer before calling vhostvringioctl() to prevent a possible use after free as eventfd could have been released in vhostvringioctl(). And such registering and unregistering will only be done if DRIVER_OK is set.(CVE-2024-47748)

In the Linux kernel, the following vulnerability has been resolved: PCI: kirin: Fix buffer overflow in kirinpcieparseport() Within kirinpcieparseport(), the pcie->numslots is compared to pcie->gpioidreset size (MAXPCISLOTS) which is correct and would lead to an overflow. Thus, fix condition to pcie->numslots + 1 >= MAXPCISLOTS and move pcie->num_slots increment below the if-statement to avoid out-of-bounds array access. Found by Linux Verification Center (linuxtesting.org) with SVACE. kwilczynski: commit log

In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 stateless decoder smatch warning Fix a smatch static checker warning on vdech264req_if.c. Which leads to a kernel crash when fb is NULL.(CVE-2024-47752)

In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning Fix a smatch static checker warning on vdecvp8req_if.c. Which leads to a kernel crash when fb is NULL.(CVE-2024-47753)

In the Linux kernel, the following vulnerability has been resolved: PCI: keystone: Fix if-statement expression in kspciequirk() This code accidentally uses && where || was intended. It potentially results in a NULL dereference. Thus, fix the if-statement expression to use the correct condition. kwilczynski: commit log

In the Linux kernel, the following vulnerability has been resolved: bpf: correctly handle malformed BPFCORETYPEIDLOCAL relos In case of malformed relocation record of kind BPFCORETYPEIDLOCAL referencing a non-existing BTF type, function bpfcorecalcreloinsn would cause a null pointer deference. Fix this by adding a proper check upper in call stack, as malformed relocation records could be passed from user space. Simplest reproducer is a program: r0 = 0 exit With a single relocation record: .insnoff = 0, /* patch first instruction */ .typeid = 100500, /* this type id does not exist / .access_str_off = 6, / offset of string "0" */ .kind = BPFCORETYPEIDLOCAL, See the link for original reproducer or next commit for a test case.(CVE-2024-49850)

In the Linux kernel, the following vulnerability has been resolved: scsi: elx: libefc: Fix potential use after free in efcnportvportdel() The krefput() function will call nport->release if the refcount drops to zero. The nport->release release function is efcnport_free() which frees "nport". But then we dereference "nport" on the next line which is a use after free. Re-order these lines to avoid the use after free.(CVE-2024-49852)

In the Linux kernel, the following vulnerability has been resolved: efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption The TPM event log table is a Linux specific construct, where the data produced by the GetEventLog() boot service is cached in memory, and passed on to the OS using an EFI configuration table. The use of EFILOADERDATA here results in the region being left unreserved in the E820 memory map constructed by the EFI stub, and this is the memory description that is passed on to the incoming kernel by kexec, which is therefore unaware that the region should be reserved. Even though the utility of the TPM2 event log after a kexec is questionable, any corruption might send the parsing code off into the weeds and crash the kernel. So let's use EFIACPIRECLAIM_MEMORY instead, which is always treated as reserved by the E820 conversion logic.(CVE-2024-49858)

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to check atomicfile in f2fs ioctl interfaces Some f2fs ioctl interfaces like f2fsiocsetpinfile(), f2fsmovefilerange(), and f2fsdefragmentrange() missed to check atomic_write status, which may cause potential race issue, fix it.(CVE-2024-49859)

In the Linux kernel, the following vulnerability has been resolved: ACPI: sysfs: validate return type of STR method Only buffer objects are valid return values of _STR. If something else is returned descriptionshow() will access invalid memory.(CVE-2024-49860)

In the Linux kernel, the following vulnerability has been resolved: powercap: intelrapl: Fix off by one in getrpi() The rp->priv->rpi array is either rpimsr or rpitpmi which have NRRAPLPRIMITIVES number of elements. Thus the > needs to be >= to prevent an off by one access.(CVE-2024-49862)

In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix dentry leak in cachefilesopenfile() A dentry leak may be caused when a lookup cookie and a cull are concurrent: P1 | P2 ----------------------------------------------------------- cachefileslookupcookie cachefileslookupobject lookuponepositiveunlocked // get dentry cachefilescull inode->iflags |= SKERNELFILE; cachefilesopenfile cachefilesmarkinodeinuse _cachefilesmarkinodeinuse canuse = false if (!(inode->iflags & SKERNELFILE)) canuse = true return false return false // Returns an error but doesn't put dentry After that the following WARNING will be triggered when the backend folder is umounted: ================================================================== BUG: Dentry 000000008ad87947{i=7a,n=Dx11.img} still in use (1) [unmount of ext4 sda] WARNING: CPU: 4 PID: 359261 at fs/dcache.c:1767 umountcheck+0x5d/0x70 CPU: 4 PID: 359261 Comm: umount Not tainted 6.6.0-dirty #25 RIP: 0010:umountcheck+0x5d/0x70 Call Trace: <TASK> dwalk+0xda/0x2b0 doonetree+0x20/0x40 shrinkdcacheforumount+0x2c/0x90 genericshutdownsuper+0x20/0x160 killblocksuper+0x1a/0x40 ext4killsb+0x22/0x40 deactivatelockedsuper+0x35/0x80 cleanupmnt+0x104/0x160 ================================================================== Whether cachefilesopenfile() returns true or false, the reference count obtained by lookuppositiveunlocked() in cachefileslookupobject() should be released. Therefore release that reference count in cachefileslookup_object() to fix the above issue and simplify the code.(CVE-2024-49870)

In the Linux kernel, the following vulnerability has been resolved: Input: adp5589-keys - fix NULL pointer dereference We register a devm action to call adp5589clearconfig() and then pass the i2c client as argument so that we can call i2cgetclientdata() in order to get our device object. However, i2csetclientdata() is only being set at the end of the probe function which means that we'll get a NULL pointer dereference in case the probe function fails early.(CVE-2024-49871)

In the Linux kernel, the following vulnerability has been resolved: i3c: master: svc: Fix use after free vulnerability in svci3cmaster Driver Due to Race Condition In the svci3cmasterprobe function, &master->hjwork is bound with svci3cmasterhjwork, &master->ibiwork is bound with svci3cmasteribiwork. And svci3cmasteribiwork can start the hjwork, svci3cmasterirqhandler can start the ibiwork. If we remove the module which will call svci3cmasterremove to make cleanup, it will free master->base through i3cmasterunregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | svci3cmasterhjwork svci3cmasterremove | i3cmasterunregister(&master->base)| deviceunregister(&master->dev) | devicerelease | //free master->base | | i3cmasterdodaa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in svci3cmaster_remove.(CVE-2024-49874)

In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible null-ptr-deref in ocfs2setbufferuptodate When doing cleanup, if flags without OCFS2BHREADAHEAD, it may trigger NULL pointer dereference in the following ocfs2setbufferuptodate() if bh is NULL.(CVE-2024-49877)

In the Linux kernel, the following vulnerability has been resolved: drm: omapdrm: Add missing check for allocorderedworkqueue As it may return NULL pointer and cause NULL pointer dereference. Add check for the return value of allocorderedworkqueue.(CVE-2024-49879)

In the Linux kernel, the following vulnerability has been resolved: ext4: update origpath in ext4findextent() In ext4findextent(), if the path is not big enough, we free it and set *origpath to NULL. But after reallocating and successfully initializing the path, we don't update orig_path, in which case the caller gets a valid path but a NULL ppath, and this may cause a NULL pointer dereference or a path memory leak. For example: ext4_split_extent path = *ppath = 2000 ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path = 2000); *orig_path = path = NULL; path = kcalloc() = 3000 ext4_split_extent_at(ppath = NULL) path = *ppath; ex = path[depth].pext; // NULL pointer dereference! ================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847 RIP: 0010:ext4splitextentat+0x6d/0x560 Call Trace: <TASK> ext4splitextent.isra.0+0xcb/0x1b0 ext4extconverttoinitialized+0x168/0x6c0 ext4exthandleunwrittenextents+0x325/0x4d0 ext4extmapblocks+0x520/0xdb0 ext4mapblocks+0x2b0/0x690 ext4iomapbegin+0x20e/0x2c0 [...] ================================================================== Therefore, *origpath is updated when the extent lookup succeeds, so that the caller can safely use path or *ppath.(CVE-2024-49881)

In the Linux kernel, the following vulnerability has been resolved: ext4: fix double brelse() the buffer of the extents path In ext4exttrytomergeup(), set path[1].pbh to NULL after it has been released, otherwise it may be released twice. An example of what triggers this is as follows: split2 map split1 |--------|-------|--------| ext4extmapblocks ext4exthandleunwrittenextents ext4splitconvertextents // path->pdepth == 0 ext4splitextent // 1. do split1 ext4splitextentat |ext4extinsertextent | ext4extcreatenewleaf | ext4extgrowindepth | le16addcpu(&neh->ehdepth, 1) | ext4findextent | // return -ENOMEM |// get error and try zeroout |path = ext4findextent | path->pdepth = 1 |ext4exttrytomerge | ext4exttrytomergeup | path->pdepth = 0 | brelse(path[1].pbh) ---> not set to NULL here |// zeroout success // 2. update path ext4findextent // 3. do split2 ext4splitextentat ext4extinsertextent ext4extcreatenewleaf ext4extgrowindepth le16addcpu(&neh->ehdepth, 1) ext4findextent path[0].pbh = NULL; path->pdepth = 1 readextenttreeblock ---> return err // path[1].pbh is still the old value ext4freeextpath ext4extdroprefs // path->pdepth == 1 brelse(path[1].pbh) ---> brelse a buffer twice Finally got the following WARRNING when removing the buffer from lru: ============================================ VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716 RIP: 0010:brelse+0x58/0x90 Call Trace: <TASK> _findgetblock+0x6e7/0x810 bdevgetblk+0x2b/0x480 _ext4getinodeloc+0x48a/0x1240 ext4getinodeloc+0xb2/0x150 ext4reserveinodewrite+0xb7/0x230 _ext4markinodedirty+0x144/0x6a0 ext4extinsertextent+0x9c8/0x3230 ext4extmapblocks+0xf45/0x2dc0 ext4mapblocks+0x724/0x1700 ext4do_writepages+0x12d6/0x2a70 [...] ============================================(CVE-2024-49882)

In the Linux kernel, the following vulnerability has been resolved: ext4: aovid use-after-free in ext4extinsertextent() As Ojaswin mentioned in Link, in ext4extinsertextent(), if the path is reallocated in ext4extcreatenewleaf(), we'll use the stale path and cause UAF. Below is a sample trace with dummy values: ext4extinsertextent path = *ppath = 2000 ext4extcreatenewleaf(ppath) ext4findextent(ppath) path = *ppath = 2000 if (depth > path[0].pmaxdepth) kfree(path = 2000); ppath = path = NULL; path = kcalloc() = 3000 *ppath = 3000; return path; / here path is still 2000, UAF! */ eh = path[depth].phdr ================================================================== BUG: KASAN: slab-use-after-free in ext4extinsertextent+0x26d4/0x3330 Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866 Call Trace: <TASK> ext4extinsertextent+0x26d4/0x3330 ext4extmapblocks+0xe22/0x2d40 ext4mapblocks+0x71e/0x1700 ext4dowritepages+0x1290/0x2800 [...] Allocated by task 179: ext4findextent+0x81c/0x1f70 ext4extmapblocks+0x146/0x2d40 ext4mapblocks+0x71e/0x1700 ext4dowritepages+0x1290/0x2800 ext4writepages+0x26d/0x4e0 dowritepages+0x175/0x700 [...] Freed by task 179: kfree+0xcb/0x240 ext4findextent+0x7c0/0x1f70 ext4extinsertextent+0xa26/0x3330 ext4extmapblocks+0xe22/0x2d40 ext4mapblocks+0x71e/0x1700 ext4dowritepages+0x1290/0x2800 ext4writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] ================================================================== So use *ppath to update the path to avoid the above problem.(CVE-2024-49883)

In the Linux kernel, the following vulnerability has been resolved: ext4: fix slab-use-after-free in ext4splitextentat() We hit the following use-after-free: ================================================================== BUG: KASAN: slab-use-after-free in ext4splitextentat+0xba8/0xcc0 Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40 CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724 Call Trace: <TASK> kasanreport+0x93/0xc0 ext4splitextentat+0xba8/0xcc0 ext4splitextent.isra.0+0x18f/0x500 ext4splitconvertextents+0x275/0x750 ext4exthandleunwrittenextents+0x73e/0x1580 ext4extmapblocks+0xe20/0x2dc0 ext4mapblocks+0x724/0x1700 ext4dowritepages+0x12d6/0x2a70 [...] Allocated by task 40: _kmallocnoprof+0x1ac/0x480 ext4findextent+0xf3b/0x1e70 ext4extmapblocks+0x188/0x2dc0 ext4mapblocks+0x724/0x1700 ext4dowritepages+0x12d6/0x2a70 [...] Freed by task 40: kfree+0xf1/0x2b0 ext4findextent+0xa71/0x1e70 ext4extinsertextent+0xa22/0x3260 ext4splitextentat+0x3ef/0xcc0 ext4splitextent.isra.0+0x18f/0x500 ext4splitconvertextents+0x275/0x750 ext4exthandleunwrittenextents+0x73e/0x1580 ext4extmapblocks+0xe20/0x2dc0 ext4mapblocks+0x724/0x1700 ext4dowritepages+0x12d6/0x2a70 [...] ================================================================== The flow of issue triggering is as follows: ext4splitextentat path = *ppath ext4extinsertextent(ppath) ext4extcreatenewleaf(ppath) ext4findextent(origpath) path = *origpath readextenttreeblock // return -ENOMEM or -EIO ext4freeextpath(path) kfree(path) *origpath = NULL a. If err is -ENOMEM: ext4extdirty(path + path->pdepth) // path use-after-free !!! b. If err is -EIO and we have EXTDEBUG defined: ext4extshowleaf(path) eh = path[depth].phdr // path also use-after-free !!! So when trying to zeroout or fix the extent length, call ext4findextent() to update the path. In addition we use *ppath directly as an ext4extshowleaf() input to avoid possible use-after-free when EXTDEBUG is defined, and to avoid unnecessary path updates.(CVE-2024-49884)

In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug Attaching SST PCI device to VM causes "BUG: KASAN: slab-out-of-bounds". kasan report: [ 19.411889] ================================================================== [ 19.413702] BUG: KASAN: slab-out-of-bounds in isstifgetpcidev+0x3d5/0x400 [isstifcommon] [ 19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113 [ 19.417368] [ 19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G E 6.9.0 #10 [ 19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022 [ 19.422687] Call Trace: [ 19.424091] <TASK> [ 19.425448] dumpstacklvl+0x5d/0x80 [ 19.426963] ? _isstifgetpcidev+0x3d5/0x400 [isstifcommon] [ 19.428694] printreport+0x19d/0x52e [ 19.430206] ? pfxrawspinlockirqsave+0x10/0x10 [ 19.431837] ? _isstifgetpcidev+0x3d5/0x400 [isstifcommon] [ 19.433539] kasanreport+0xf0/0x170 [ 19.435019] ? isstifgetpcidev+0x3d5/0x400 [isstifcommon] [ 19.436709] _isstifgetpcidev+0x3d5/0x400 [isstifcommon] [ 19.438379] ? _pfxschedclockcpu+0x10/0x10 [ 19.439910] isstifcpuonline+0x406/0x58f [isstifcommon] [ 19.441573] ? _pfxisstifcpuonline+0x10/0x10 [isstifcommon] [ 19.443263] ? ttwuqueuewakelist+0x2c1/0x360 [ 19.444797] cpuhpinvokecallback+0x221/0xec0 [ 19.446337] cpuhpthreadfun+0x21b/0x610 [ 19.447814] ? _pfxcpuhpthreadfun+0x10/0x10 [ 19.449354] smpbootthreadfn+0x2e7/0x6e0 [ 19.450859] ? _pfxsmpbootthreadfn+0x10/0x10 [ 19.452405] kthread+0x29c/0x350 [ 19.453817] ? _pfxkthread+0x10/0x10 [ 19.455253] retfromfork+0x31/0x70 [ 19.456685] ? _pfxkthread+0x10/0x10 [ 19.458114] retfromforkasm+0x1a/0x30 [ 19.459573] </TASK> [ 19.460853] [ 19.462055] Allocated by task 1198: [ 19.463410] kasansavestack+0x30/0x50 [ 19.464788] kasansavetrack+0x14/0x30 [ 19.466139] _kasankmalloc+0xaa/0xb0 [ 19.467465] _kmalloc+0x1cd/0x470 [ 19.468748] isstifcdevregister+0x1da/0x350 [isstifcommon] [ 19.470233] isstifmboxinit+0x108/0xff0 [isstifmboxmsr] [ 19.471670] dooneinitcall+0xa4/0x380 [ 19.472903] doinitmodule+0x238/0x760 [ 19.474105] loadmodule+0x5239/0x6f00 [ 19.475285] initmodulefromfile+0xd1/0x130 [ 19.476506] idempotentinitmodule+0x23b/0x650 [ 19.477725] _x64sysfinitmodule+0xbe/0x130 [ 19.476506] idempotentinitmodule+0x23b/0x650 [ 19.477725] _x64sysfinitmodule+0xbe/0x130 [ 19.478920] dosyscall64+0x82/0x160 [ 19.480036] entrySYSCALL64afterhwframe+0x76/0x7e [ 19.481292] [ 19.482205] The buggy address belongs to the object at ffff888829e65000 which belongs to the cache kmalloc-512 of size 512 [ 19.484818] The buggy address is located 0 bytes to the right of allocated 512-byte region [ffff888829e65000, ffff888829e65200) [ 19.487447] [ 19.488328] The buggy address belongs to the physical page: [ 19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60 [ 19.491140] head: order:3 entiremapcount:0 nrpagesmapped:0 pincount:0 [ 19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [ 19.493914] pagetype: 0xffffffff() [ 19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff [ 19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000 [ 19.503784] page dumped because: k ---truncated---(CVE-2024-49886)

In the Linux kernel, the following vulnerability has been resolved: ext4: avoid use-after-free in ext4extshowleaf() In ext4findextent(), path may be freed by error or be reallocated, so using a previously saved *ppath may have been freed and thus may trigger use-after-free, as follows: ext4splitextent path = *ppath; ext4splitextentat(ppath) path = ext4findextent(ppath) ext4splitextentat(ppath) // ext4findextent fails to free path // but zeroout succeeds ext4extshowleaf(inode, path) eh = path[depth].phdr // path use-after-free !!! Similar to ext4splitextentat(), we use *ppath directly as an input to ext4extshowleaf(). Fix a spelling error by the way. Same problem in ext4exthandleunwrittenextents(). Since 'path' is only used in ext4extshowleaf(), remove 'path' and use *ppath directly. This issue is triggered only when EXT_DEBUG is defined and therefore does not affect functionality.(CVE-2024-49889)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize getbytesperelement's default to 1 Variables, used as denominators and maybe not assigned to other values, should not be 0. bytesperelementy & bytesperelementc are initialized by getbytesperelement() which should never return 0. This fixes 10 DIVIDEBYZERO issues reported by Coverity.(CVE-2024-49892)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream before comparing them [WHAT & HOW] amdgpudm can pass a null stream to dcisstreamunchanged. It is necessary to check for null before dereferencing them. This fixes 1 FORWARD_NULL issue reported by Coverity.(CVE-2024-49896)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null-initialized variables [WHAT & HOW] drrtiming and subvppipe are initialized to null and they are not always assigned new values. It is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.(CVE-2024-49898)

(CVE-2024-49901)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn32setoutputtransferfunc This commit adds a null check for the setoutputgamma function pointer in the dcn32setoutputtransferfunc function. Previously, setoutputgamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if setoutputgamma is null. To fix this, we now ensure that setoutputgamma is not null before dereferencing it. We do this by adding a null check for setoutputgamma before the call to setoutputgamma.(CVE-2024-49909)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle null 'streamstatus' in 'planeschangedforexistingstream' This commit adds a null check for 'streamstatus' in the function 'planeschangedforexistingstream'. Previously, the code assumed 'streamstatus' could be null, but did not handle the case where it was actually null. This could lead to a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dcresource.c:3784 planeschangedforexistingstream() error: we previously assumed 'stream_status' could be null (see line 3774)(CVE-2024-49912)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for toppipetoprogram in commitplanesforstream This commit addresses a null pointer dereference issue in the commit_planes_for_stream function at line 4140. The issue could occur when top_pipe_to_program is null. The fix adds a check to ensure top_pipe_to_program is not null before accessing its streamres. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commitplanesforstream() error: we previously assumed 'toppipeto_program' could be null (see line 3906)(CVE-2024-49913)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clkmgr and clkmgr->funcs in dcn30inithw This commit addresses a potential null pointer dereference issue in the dcn30_init_hw function. The issue could occur when dc->clk_mgr or dc->clk_mgr->funcs is null. The fix adds a check to ensure dc->clk_mgr and dc->clk_mgr->funcs is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30hwseq.c:789 dcn30inithw() error: we previously assumed 'dc->clkmgr' could be null (see line 628)(CVE-2024-49917)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using them [WHAT & HOW] These pointers are null checked previously in the same function, indicating they might be null as reported by Coverity. As a result, they need to be checked when used again. This fixes 3 FORWARD_NULL issue reported by Coverity.(CVE-2024-49922)

In the Linux kernel, the following vulnerability has been resolved: fbdev: pxafb: Fix possible use after free in pxafbtask() In the pxafbprobe function, it calls the pxafbinitfbinfo function, after which &fbi->task is associated with pxafbtask. Moreover, within this pxafbinitfbinfo function, the pxafbblank function within the &pxafbops struct is capable of scheduling work. If we remove the module which will call pxafbremove to make cleanup, it will call unregisterframebuffer function which can call dounregisterframebuffer to free fbi->fb through putfbinfo(fbinfo), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | pxafbtask pxafbremove | unregisterframebuffer(info) | dounregisterframebuffer(fbinfo) | putfbinfo(fbinfo) | // free fbi->fb | setctrlrstate(fbi, state) | _pxafblcdpower(fbi, 0) | fbi->lcdpower(on, &fbi->fb.var) | //use fbi->fb Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafbremove. Note that only root user can remove the driver at runtime.(CVE-2024-49924)

In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix array out-of-bound access in SoC stats Currently, the ath12ksocdpstats::halreoerror array is defined with a maximum size of DPREODSTRINGMAX. However, the ath12kdprxprocess() function access ath12ksocdpstats::halreoerror using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath12kdprxprocess() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1(CVE-2024-49931)

In the Linux kernel, the following vulnerability has been resolved: blkiocost: fix more out of bound shifts Recently running UBSAN caught few out of bound shifts in the iocforgivedebts() function: UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... Call Trace: <IRQ> dumpstacklvl+0xca/0x130 _ubsanhandleshiftoutofbounds+0x22c/0x280 ? _lockacquire+0x6441/0x7c10 ioctimerfn+0x6cec/0x7750 ? blkiocostinit+0x720/0x720 ? calltimerfn+0x5d/0x470 calltimerfn+0xfa/0x470 ? blkiocostinit+0x720/0x720 _runtimerbase+0x519/0x700 ... Actual impact of this issue was not identified but I propose to fix the undefined behaviour. The proposed fix to prevent those out of bound shifts consist of precalculating exponent before using it the shift operations by taking min value from the actual exponent and maximum possible number of bits.(CVE-2024-49933)

In the Linux kernel, the following vulnerability has been resolved: fs/inode: Prevent dumpmapping() accessing invalid dentry.dname.name It's observed that a crash occurs during hot-remove a memory device, in which user is accessing the hugetlb. See calltrace as following: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 douseraddrfault+0x2a0/0x790 Modules linked in: kmem devicedax cxlmem cxlpmem cxlport cxlpci daxhmem daxpmem ndpmem cxlacpi ndbtt cxlcore crc32cintel nvme virtiofs fuse nvmecore nfit libnvdimm dmmultipath scsidhrdac scsidhemc s mirror dmregionhash dmlog dmmod CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:douseraddrfault+0x2a0/0x790 Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff <0f> 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41 RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046 RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658 R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000 FS: 00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? _warn+0x8d/0x190 ? douseraddrfault+0x2a0/0x790 ? reportbug+0x1c3/0x1d0 ? handlebug+0x3c/0x70 ? excinvalidop+0x14/0x70 ? asmexcinvalidop+0x16/0x20 ? douseraddrfault+0x2a0/0x790 ? excpagefault+0x31/0x200 excpagefault+0x68/0x200 <...snip...> BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: G W 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dentryname+0x1f4/0x440 <...snip...> ? dentryname+0x2fa/0x440 vsnprintf+0x1f3/0x4f0 vprintkstore+0x23a/0x540 vprintkemit+0x6d/0x330 printk+0x58/0x80 dumpmapping+0x10b/0x1a0 ? _pfxfreeobjectrcu+0x10/0x10 _dumppage+0x26b/0x3e0 ? vprintkemit+0xe0/0x330 ? _printk+0x58/0x80 ? dumppage+0x17/0x50 dumppage+0x17/0x50 domigraterange+0x2f7/0x7f0 ? domigraterange+0x42/0x7f0 ? offlinepages+0x2f4/0x8c0 offlinepages+0x60a/0x8c0 memorysubsysoffline+0x9f/0x1c0 ? lockdephardirqson+0x77/0x100 ? _rawspinunlockirqrestore+0x38/0x60 deviceoffline+0xe3/0x110 statestore+0x6e/0xc0 kernfsfopwriteiter+0x143/0x200 vfswrite+0x39f/0x560 ksyswrite+0x65/0xf0 dosyscall64+0x62/0x130 Previously, some sanity check have been done in dumpmapping() before the print facility parsing '%pd' though, it's still possible to run into an invalid dentry.dname.name. Since dumpmapping() only needs to dump the filename only, retrieve it by itself in a safer way to prevent an unnecessary crash. Note that either retrieving the filename with '%pd' or strncpyfromkernel_nofault(), the filename could be unreliable.(CVE-2024-49934)

In the Linux kernel, the following vulnerability has been resolved: net/xen-netback: prevent UAF in xenvifflushhash() During the listforeachentryrcu iteration call of xenvifflushhash, kfreercu does not exist inside the rcu read critical section, so if kfreercu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head->next after the entry becomes free. Therefore, to solve this, you need to change it to listforeachentrysafe.(CVE-2024-49936)

In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Set correct chandef when starting CAC When starting CAC in a mode other than AP mode, it return a "WARNING: CPU: 0 PID: 63 at cfg80211chandefdfsusable+0x20/0xaf [cfg80211]" caused by the chandef.chan being null at the end of CAC. Solution: Ensure the channel definition is set for the different modes when starting CAC to avoid getting a NULL 'chan' at the end of CAC. Call Trace: ? showregs.part.0+0x14/0x16 ? _warn+0x67/0xc0 ? cfg80211chandefdfsusable+0x20/0xaf [cfg80211] ? reportbug+0xa7/0x130 ? excoverflow+0x30/0x30 ? handlebug+0x27/0x50 ? excinvalidop+0x18/0x60 ? handleexception+0xf6/0xf6 ? excoverflow+0x30/0x30 ? cfg80211chandefdfsusable+0x20/0xaf [cfg80211] ? excoverflow+0x30/0x30 ? cfg80211chandefdfsusable+0x20/0xaf [cfg80211] ? regulatorypropagatedfsstate.cold+0x1b/0x4c [cfg80211] ? cfg80211propagatecacdonewk+0x1a/0x30 [cfg80211] ? processonework+0x165/0x280 ? workerthread+0x120/0x3f0 ? kthread+0xc2/0xf0 ? processonework+0x280/0x280 ? kthreadcompleteandexit+0x20/0x20 ? retfrom_fork+0x19/0x24 shorten subject, remove OCB, reorder cases to match previous list

In the Linux kernel, the following vulnerability has been resolved: l2tp: prevent possible tunnel refcount underflow When a session is created, it sets a backpointer to its tunnel. When the session refcount drops to 0, l2tpsessionfree drops the tunnel refcount if session->tunnel is non-NULL. However, session->tunnel is set in l2tpsessioncreate, before the tunnel refcount is incremented by l2tpsessionregister, which leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn't been bumped. Moving the assignment to l2tpsessionregister is trivial but l2tpsessioncreate calls l2tpsessionsetheaderlen which uses session->tunnel to get the tunnel's encap. Add an encap arg to l2tpsessionsetheaderlen to avoid using session->tunnel. If l2tpv3 sessions have colliding IDs, it is possible for l2tpv3sessionget to race with l2tpsession_register and fetch a session which doesn't yet have session->tunnel set. Add a check for this case.(CVE-2024-49940)

In the Linux kernel, the following vulnerability has been resolved: staticcall: Replace pointless WARNON() in staticcallmodulenotify() staticcallmodulenotify() triggers a WARNON(), when memory allocation fails in _staticcalladdmodule(). That's not really justified, because the failure case must be correctly handled by the well known call chain and the error code is passed through to the initiating userspace application. A memory allocation fail is not a fatal problem, but the WARNON() takes the machine out when paniconwarn is set. Replace it with a pr_warn().(CVE-2024-49954)

In the Linux kernel, the following vulnerability has been resolved: ACPI: battery: Fix possible crash when unregistering a battery hook When a battery hook returns an error when adding a new battery, then the battery hook is automatically unregistered. However the battery hook provider cannot know that, so it will later call batteryhookunregister() on the already unregistered battery hook, resulting in a crash. Fix this by using the list head to mark already unregistered battery hooks as already being unregistered so that they can be ignored by batteryhookunregister().(CVE-2024-49955)

In the Linux kernel, the following vulnerability has been resolved: ocfs2: reserve space for inline xattr before attaching reflink tree One of our customers reported a crash and a corrupted ocfs2 filesystem. The crash was due to the detection of corruption. Upon troubleshooting, the fsck -fn output showed the below corruption [EXTENTLISTFREE] Extent list in owner 33080590 claims 230 as the next free chain record, but fsck believes the largest valid value is 227. Clamp the next record value? n The stat output from the debugfs.ocfs2 showed the following corruption where the "Next Free Rec:" had overshot the "Count:" in the root metadata block. Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856) FS Generation: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Type: Regular Attr: 0x0 Flags: Valid Dynamic Features: (0x16) HasXattr InlineXattr Refcounted Extended Attributes Block: 0 Extended Attributes Inline Size: 256 User: 0 (root) Group: 0 (root) Size: 281320357888 Links: 1 Clusters: 141738 ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Wed Dec 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## Offset Clusters Block# 0 0 2310 2776351 1 2310 2139 2777375 2 4449 1221 2778399 3 5670 731 2779423 4 6401 566 2780447 ....... .... ....... ....... .... ....... The issue was in the reflink workfow while reserving space for inline xattr. The problematic function is ocfs2reflinkxattrinline(). By the time this function is called the reflink tree is already recreated at the destination inode from the source inode. At this point, this function reserves space for inline xattrs at the destination inode without even checking if there is space at the root metadata block. It simply reduces the lcount from 243 to 227 thereby making space of 256 bytes for inline xattr whereas the inode already has extents beyond this index (in this case up to 230), thereby causing corruption. The fix for this is to reserve space for inline metadata at the destination inode before the reflink tree gets recreated. The customer has verified the fix.(CVE-2024-49958)

In the Linux kernel, the following vulnerability has been resolved: ext4: fix timer use-after-free on failed mount Syzbot has found an ODEBUG bug in ext4fillsuper The deltimersync function cancels the serrreport timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi). When filesystem mounting fails, the flow goes to failedmount3, where an error occurs when ext4stopmmpd is called, causing a read I/O failure. This triggers the ext4handleerror function that ultimately re-arms the timer, leaving the serrreport timer active before kfree(sbi) is called. Fix the issue by canceling the serrreport timer after calling ext4stop_mmpd.(CVE-2024-49960)

In the Linux kernel, the following vulnerability has been resolved: media: i2c: ar0521: Use cansleep version of gpiodsetvalue() If we use GPIO reset from I2C port expander, we must use *cansleep() variant of GPIO functions. This was not done in ar0521poweron()/ar0521poweroff() functions. Let's fix that. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at drivers/gpio/gpiolib.c:3496 gpiodsetvalue+0x74/0x7c Modules linked in: CPU: 0 PID: 11 Comm: kworker/u16:0 Not tainted 6.10.0 #53 Hardware name: Diasom DS-RK3568-SOM-EVB (DT) Workqueue: eventsunbound deferredprobeworkfunc pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : gpiodsetvalue+0x74/0x7c lr : ar0521poweron+0xcc/0x290 sp : ffffff8001d7ab70 x29: ffffff8001d7ab70 x28: ffffff80027dcc90 x27: ffffff8003c82000 x26: ffffff8003ca9250 x25: ffffffc080a39c60 x24: ffffff8003ca9088 x23: ffffff8002402720 x22: ffffff8003ca9080 x21: ffffff8003ca9088 x20: 0000000000000000 x19: ffffff8001eb2a00 x18: ffffff80efeeac80 x17: 756d2d6332692f30 x16: 0000000000000000 x15: 0000000000000000 x14: ffffff8001d91d40 x13: 0000000000000016 x12: ffffffc080e98930 x11: ffffff8001eb2880 x10: 0000000000000890 x9 : ffffff8001d7a9f0 x8 : ffffff8001d92570 x7 : ffffff80efeeac80 x6 : 000000003fc6e780 x5 : ffffff8001d91c80 x4 : 0000000000000002 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: gpiodsetvalue+0x74/0x7c ar0521power_on+0xcc/0x290 ...(CVE-2024-49961)

In the Linux kernel, the following vulnerability has been resolved: ocfs2: cancel dqisyncwork before freeing oinfo ocfs2globalreadinfo() will initialize and schedule dqisyncwork at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIGDEBUGOBJECTS* enabled: ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timerlist hint: qsyncworkfn+0x0/0x16c This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqisyncwork first. BTW, return status instead of -1 when .readfile_info fails.(CVE-2024-49966)

In the Linux kernel, the following vulnerability has been resolved: ext4: no need to continue when the number of entries is 1(CVE-2024-49967)

In the Linux kernel, the following vulnerability has been resolved: ext4: filesystems without casefold feature cannot be mounted with siphash When mounting the ext4 filesystem, if the default hash version is set to DXHASHSIPHASH but the casefold feature is not set, exit the mounting.(CVE-2024-49968)

In the Linux kernel, the following vulnerability has been resolved: r8169: add tally counter fields added with RTL8125 RTL8125 added fields to the tally counter, what may result in the chip dma'ing these new fields to unallocated memory. Therefore make sure that the allocated memory area is big enough to hold all of the tally counter values, even if we use only parts of it.(CVE-2024-49973)

In the Linux kernel, the following vulnerability has been resolved: uprobes: fix kernel info leak via "[uprobes]" vma xoladdvma() maps the uninitialized page allocated by _createxolarea() into userspace. On some architectures (x86) this memory is readable even without VMREAD, VMEXEC results in the same pgprott as VMEXEC|VMREAD, although this doesn't really matter, debugger can read this memory anyway.(CVE-2024-49975)

In the Linux kernel, the following vulnerability has been resolved: gso: fix udp gso fraglist segmentation after pull from fraglist Detect gso fraglist skbs with corrupted geometry (see below) and pass these to skbsegment instead of skbsegmentlist, as the first can segment them correctly. Valid SKBGSOFRAGLIST skbs - consist of two or more segments - the headskb holds the protocol headers plus first gsosize - one or more fraglist skbs hold exactly one segment - all but the last must be gsosize Optional datapath hooks such as NAT and BPF (bpfskbpulldata) can modify these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For UDP, this causes a NULL ptr deref in _udpv4gsosegmentlistcsum at udphdr(seg->next)->dest. Detect invalid geometry due to pull, by checking headskb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment.(CVE-2024-49978)

In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free bug in venusremove due to race condition in venusprobe, core->work is bound with venussyserrorhandler, which is used to handle error. The code use core->syserrdone to make sync work. The core->work is started in venuseventnotify. If we call venusremove, there might be an unfished work. The possible sequence is as follows: CPU0 CPU1 |venussyserrorhandler venusremove | hfidestroy | venushfidestroy | kfree(hdev); | |hfireinit |venushfiqueuesreinit |//use hdev Fix it by canceling the work in venusremove.(CVE-2024-49981)

In the Linux kernel, the following vulnerability has been resolved: ext4: drop ppath from ext4extreplayupdateex() to avoid double-free When calling ext4forcesplitextentat() in ext4extreplayupdateex(), the 'ppath' is updated but it is the 'path' that is freed, thus potentially triggering a double-free in the following process: ext4extreplayupdateex ppath = path ext4forcesplitextentat(&ppath) ext4splitextentat ext4extinsertextent ext4extcreatenewleaf ext4extgrowindepth ext4findextent if (depth > path[0].pmaxdepth) kfree(path) ---> path First freed *origpath = path = NULL ---> null ppath kfree(path) ---> path double-free !!! So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4findextent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4find_extent() instead of using strange error codes.(CVE-2024-49983)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix double free issue during amdgpu module unload Flexible endpoints use DIGs from available inflexible endpoints, so only the encoders of inflexible links need to be freed. Otherwise, a double free issue may occur when unloading the amdgpu module. [ 279.190523] RIP: 0010:_slabfree+0x152/0x2f0 [ 279.190577] Call Trace: [ 279.190580] <TASK> [ 279.190582] ? showregs+0x69/0x80 [ 279.190590] ? die+0x3b/0x90 [ 279.190595] ? dotrap+0xc8/0xe0 [ 279.190601] ? doerrortrap+0x73/0xa0 [ 279.190605] ? _slabfree+0x152/0x2f0 [ 279.190609] ? excinvalidop+0x56/0x70 [ 279.190616] ? _slabfree+0x152/0x2f0 [ 279.190642] ? asmexcinvalidop+0x1f/0x30 [ 279.190648] ? dcn10linkencoderdestroy+0x19/0x30 [amdgpu] [ 279.191096] ? _slabfree+0x152/0x2f0 [ 279.191102] ? dcn10linkencoderdestroy+0x19/0x30 [amdgpu] [ 279.191469] kfree+0x260/0x2b0 [ 279.191474] dcn10linkencoderdestroy+0x19/0x30 [amdgpu] [ 279.191821] linkdestroy+0xd7/0x130 [amdgpu] [ 279.192248] dcdestruct+0x90/0x270 [amdgpu] [ 279.192666] dcdestroy+0x19/0x40 [amdgpu] [ 279.193020] amdgpudmfini+0x16e/0x200 [amdgpu] [ 279.193432] dmhwfini+0x26/0x40 [amdgpu] [ 279.193795] amdgpudevicefinihw+0x24c/0x400 [amdgpu] [ 279.194108] amdgpudriverunloadkms+0x4f/0x70 [amdgpu] [ 279.194436] amdgpupciremove+0x40/0x80 [amdgpu] [ 279.194632] pcideviceremove+0x3a/0xa0 [ 279.194638] deviceremove+0x40/0x70 [ 279.194642] devicereleasedriverinternal+0x1ad/0x210 [ 279.194647] driverdetach+0x4e/0xa0 [ 279.194650] busremovedriver+0x6f/0xf0 [ 279.194653] driverunregister+0x33/0x60 [ 279.194657] pciunregisterdriver+0x44/0x90 [ 279.194662] amdgpuexit+0x19/0x1f0 [amdgpu] [ 279.194939] _dosysdeletemodule.isra.0+0x198/0x2f0 [ 279.194946] _x64sysdeletemodule+0x16/0x20 [ 279.194950] dosyscall64+0x58/0x120 [ 279.194954] entrySYSCALL64afterhwframe+0x6e/0x76 [ 279.194980] </TASK>(CVE-2024-49989)

In the Linux kernel, the following vulnerability has been resolved: drm/stm: Avoid use-after-free issues with crtc and plane ltdcload() calls functions drmcrtcinitwithplanes(), drmuniversalplaneinit() and drmencoderinit(). These functions should not be called with parameters allocated with devm_kzalloc() to avoid use-after-free issues [1]. Use allocations managed by the DRM framework. Found by Linux Verification Center (linuxtesting.org). [1] https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/(CVE-2024-49992)

In the Linux kernel, the following vulnerability has been resolved: block: fix integer overflow in BLKSECDISCARD I independently rediscovered commit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 block: fix overflow in blkioctldiscard() but for secure erase. Same problem: uint64t r[2] = {512, 18446744073709551104ULL}; ioctl(fd, BLKSECDISCARD, r); will enter near infinite loop inside blkdevissuesecureerase(): a.out: attempt to access beyond end of device loop0: rw=5, sector=3399043073, nrsectors = 1024 limit=2048 biocheck_eod: 3286214 callbacks suppressed(CVE-2024-49994)

In the Linux kernel, the following vulnerability has been resolved: tipc: guard against string buffer overrun Smatch reports that copying medianame and ifname to nameparts may overwrite the destination. .../bearer.c:166 bearernamevalidate() error: strcpy() 'medianame' too large for 'nameparts->medianame' (32 vs 16) .../bearer.c:167 bearernamevalidate() error: strcpy() 'ifname' too large for 'nameparts->if_name' (1010102 vs 16) This does seem to be the case so guard against this possibility by using strscpy() and failing if truncation occurs. Introduced by commit b97bf3fd8f6a ("[TIPC] Initial merge") Compile tested only.(CVE-2024-49995)

In the Linux kernel, the following vulnerability has been resolved: cifs: Fix buffer overflow when parsing NFS reparse points ReparseDataLength is sum of the InodeType size and DataBuffer size. So to get DataBuffer size it is needed to subtract InodeType's size from ReparseDataLength. Function cifsstrndupfromutf16() is currentlly accessing buf->DataBuffer at position after the end of the buffer because it does not subtract InodeType size from the length. Fix this problem and correctly subtract variable len. Member InodeType is present only when reparse buffer is large enough. Check for ReparseDataLength before accessing InodeType to prevent another invalid memory access. Major and minor rdev values are present also only when reparse buffer is large enough. Check for reparse buffer size before calling reparsemkdev().(CVE-2024-49996)

In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix NULL deref in mlx5etirbuilderalloc() In mlx5etirbuilderalloc() kvzalloc() may return NULL which is dereferenced on the next line in a reference to the modify field. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50000)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix system hang while resume with TBT monitor [Why] Connected with a Thunderbolt monitor and do the suspend and the system may hang while resume. The TBT monitor HPD will be triggered during the resume procedure and call the drmclientmodesetprobe() while struct drmconnector connector->dev->master is NULL. It will mess up the pipe topology after resume. [How] Skip the TBT monitor HPD during the resume procedure because we currently will probe the connectors after resume by default. (cherry picked from commit 453f86a26945207a16b8f66aaed5962dc2b95b85)(CVE-2024-50003)

In the Linux kernel, the following vulnerability has been resolved: ext4: fix idatasem unlock order in ext4indmigrate() Fuzzing reports a possible deadlock in jbd2logwaitcommit. This issue is triggered when an EXT4IOCMIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with OSYNC. This can lead to the jbd2journalstop() function calling jbd2mightwaitforcommit(), potentially causing a deadlock if the EXT4IOCMIGRATE call races with a write(2) system call. This problem only arises when CONFIGPROVELOCKING is enabled. In this case, the jbd2mightwaitforcommit macro locks jbd2handle in the jbd2journalstop function while idatasem is locked. This triggers lockdep because the jbd2journalstart function might also lock the same jbd2handle simultaneously. Found by Linux Verification Center (linuxtesting.org) with syzkaller. Rule: add(CVE-2024-50006)

In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiexcmd80211scanext() Replace one-element array with a flexible-array member in struct host_cmd_ds_802_11_scan_ext. With this, fix the following warning: elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------ elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field "extscan->tlvbuffer" at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1) elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiexcmd80211scanext+0x83/0x90 mwifiex

In the Linux kernel, the following vulnerability has been resolved: cpufreq: amd-pstate: add check for cpufreqcpuget's return value cpufreqcpuget may return NULL. To avoid NULL-dereference check it and return in case of error. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50009)

In the Linux kernel, the following vulnerability has been resolved: exfat: fix memory leak in exfatloadbitmap() If the first directory entry in the root directory is not a bitmap directory entry, 'bh' will not be released and reassigned, which will cause a memory leak.(CVE-2024-50013)

In the Linux kernel, the following vulnerability has been resolved: ext4: fix access to uninitialised lock in fc replay path The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x66/0x90 registerlockclass+0x759/0x7d0 _lockacquire+0x85/0x2630 ? _findgetblock+0xb4/0x380 lockacquire+0xd1/0x2d0 ? _ext4journalgetwriteaccess+0xd5/0x160 _rawspinlock+0x33/0x40 ? _ext4journalgetwriteaccess+0xd5/0x160 _ext4journalgetwriteaccess+0xd5/0x160 ext4reserveinodewrite+0x61/0xb0 _ext4markinodedirty+0x79/0x270 ? ext4extreplaysetiblocks+0x2f8/0x450 ext4extreplaysetiblocks+0x330/0x450 ext4fcreplay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcuiswatching+0x11/0x40 doonepass+0x447/0xd00 jbd2journalrecover+0x139/0x1b0 jbd2journalload+0x96/0x390 ext4loadandinitjournal+0x253/0xd40 ext4fillsuper+0x2cc6/0x3180 ... In the replay path there's an attempt to lock sbi->sbdevwblock in function ext4checkbdevwriteerror(). Unfortunately, at this point this spinlock has not been initialized yet. Moving it's initialization to an earlier point in _ext4fillsuper() fixes this splat.(CVE-2024-50014)

In the Linux kernel, the following vulnerability has been resolved: ext4: dax: fix overflowing extents beyond inode size when partially writing The daxiomaprw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in daxiomapiter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as: dd if=/dev/urandom of=file bs=4M count=1 daxiomaprw iomapiter // round 1 ext4iomapbegin ext4iomapalloc // allocate 0~2M extents(written flag) daxiomapiter // copy 2M data iomapiter // round 2 iomapiteradvance iter->pos += iter->processed // iter->pos = 2M ext4iomapbegin ext4iomapalloc // allocate 2~4M extents(written flag) daxiomapiter fatalsignalpending done = iter->pos - iocb->kipos // done = 2M ext4handleinodeextension ext4updateinodesize // inode size = 2M fsck reports: Inode 13, isize is 2097152, should be 4194304. Fix? Fix the problem by truncating extents if the written length is smaller than expected.(CVE-2024-50015)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid overflow assignment in linkdpcts samplingrate is an uint8t but is assigned an unsigned int, and thus it can overflow. As a result, samplingrate is changed to uint32t. Similarly, LINKQUALPATTERNSET has a size of 2 bits, and it should only be assigned to a value less or equal than 4. This fixes 2 INTEGEROVERFLOW issues reported by Coverity.(CVE-2024-50016)

In the Linux kernel, the following vulnerability has been resolved: kthread: unpark only parked kthread Calling into kthread unparking unconditionally is mostly harmless when the kthread is already unparked. The wake up is then simply ignored because the target is not in TASKPARKED state. However if the kthread is per CPU, the wake up is preceded by a call to kthreadbind() which expects the task to be inactive and in TASKPARKED state, which obviously isn't the case if it is unparked. As a result, calling kthreadstop() on an unparked per-cpu kthread triggers such a warning: WARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 _kthreadbindmask kernel/kthread.c:525 <TASK> kthreadstop+0x17a/0x630 kernel/kthread.c:707 destroyworkqueue+0x136/0xc40 kernel/workqueue.c:5810 wgdestruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257 netdevruntodo+0xe1a/0x1000 net/core/dev.c:10693 defaultdeviceexitbatch+0xa14/0xa90 net/core/dev.c:11769 opsexitlist net/core/netnamespace.c:178 [inline] cleanupnet+0x89d/0xcc0 net/core/netnamespace.c:640 processonework kernel/workqueue.c:3231 [inline] processscheduledworks+0xa2c/0x1830 kernel/workqueue.c:3312 workerthread+0x86d/0xd70 kernel/workqueue.c:3393 kthread+0x2f0/0x390 kernel/kthread.c:389 retfromfork+0x4b/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Fix this with skipping unecessary unparking while stopping a kthread.(CVE-2024-50019)

In the Linux kernel, the following vulnerability has been resolved: device-dax: correct pgoff align in daxsetmapping() pgoff should be aligned using ALIGNDOWN() instead of ALIGN(). Otherwise, vmf->address not aligned to faultsize will be aligned to the next alignment, that can result in memory failure getting the wrong address. It's a subtle situation that only can be observed in pagemappedinvma() after the page is page fault handled by devdaxhugefault. Generally, there is little chance to perform pagemappedinvma in dev-dax's page unless in specific error injection to the dax device to trigger an MCE - memory-failure. In that case, pagemappedinvma() will be triggered to determine which task is accessing the failure address and kill that task in the end. We used self-developed dax device (which is 2M aligned mapping) , to perform error injection to random address. It turned out that error injected to non-2M-aligned address was causing endless MCE until panic. Because pagemappedin_vma() kept resulting wrong address and the task accessing the failure address was never killed properly: [ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.049006] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.448042] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.792026] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.162502] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.461116] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.764730] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.042128] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.464293] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.818090] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3787.085297] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page: Recovered It took us several weeks to pinpoint this problem,  but we eventually used bpftrace to trace the page fault and mce address and successfully identified the issue. Joao added: ; Likely we never reproduce in production because we always pin : device-dax regions in the region align they provide (Qemu does : similarly with prealloc in hugetlb/file backed memory). I think this : bug requires that we touch unpinned device-dax regions unaligned to : the device-dax selected alignment (page size i.e. 4K/2M/1G)(CVE-2024-50022)

In the Linux kernel, the following vulnerability has been resolved: scsi: fnic: Move flushwork initialization out of if block After commit 379a58caa199 ("scsi: fnic: Move fnicfnicflushtx() to a work queue"), it can happen that a work item is sent to an uninitialized work queue. This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed. The following warning is observed while the fnic driver is loaded: kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 _queuework+0x373/0x410 kernel: <IRQ> kernel: queueworkon+0x3a/0x50 kernel: fnicwqcopycmplhandler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: fnicisrmsixwqcopy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: _handleirqeventpercpu+0x36/0x1a0 kernel: handleirqeventpercpu+0x30/0x70 kernel: handleirqevent+0x34/0x60 kernel: handleedgeirq+0x7e/0x1a0 kernel: _commoninterrupt+0x3b/0xb0 kernel: commoninterrupt+0x58/0xa0 kernel: </IRQ> It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure. This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().(CVE-2024-50025)

In the Linux kernel, the following vulnerability has been resolved: scsi: wd33c93: Don't use stale scsipointer value A regression was introduced with commit dbb2da557a6a ("scsi: wd33c93: Move the SCSI pointer to private command data") which results in an oops in wd33c93intr(). That commit added the scsipointer variable and initialized it from hostdata->connected. However, during selection, hostdata->connected is not yet valid. Fix this by getting the current scsipointer from hostdata->selecting.(CVE-2024-50026)

In the Linux kernel, the following vulnerability has been resolved: thermal: core: Reference count the zone in thermalzonegetbyid() There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermalzonegetbyid(). To address this, make thermalzonegetbyid() get a reference on the thermal zone device object to be returned with the help of getdevice(), under thermallist_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure.(CVE-2024-50028)

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hciconn: Fix UAF in hcienhancedsetupsync This checks if the ACL connection remains valid as it could be destroyed while hcienhancedsetupsync is pending on cmdsync leading to the following trace: BUG: KASAN: slab-use-after-free in hcienhancedsetupsync+0x91b/0xa60 Read of size 1 at addr ffff888002328ffd by task kworker/u5:2/37 CPU: 0 UID: 0 PID: 37 Comm: kworker/u5:2 Not tainted 6.11.0-rc6-01300-g810be445d8d6 #7099 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Workqueue: hci0 hcicmdsyncwork Call Trace: <TASK> dumpstacklvl+0x5d/0x80 ? hcienhancedsetupsync+0x91b/0xa60 printreport+0x152/0x4c0 ? hcienhancedsetupsync+0x91b/0xa60 ? virtaddrvalid+0x1fa/0x420 ? hcienhancedsetupsync+0x91b/0xa60 kasanreport+0xda/0x1b0 ? hcienhancedsetupsync+0x91b/0xa60 hcienhancedsetupsync+0x91b/0xa60 ? _pfxhcienhancedsetupsync+0x10/0x10 ? _pfxmutexlock+0x10/0x10 hcicmdsyncwork+0x1c2/0x330 processonework+0x7d9/0x1360 ? _pfxlockacquire+0x10/0x10 ? _pfxprocessonework+0x10/0x10 ? assignwork+0x167/0x240 workerthread+0x5b7/0xf60 ? _kthreadparkme+0xac/0x1c0 ? _pfxworkerthread+0x10/0x10 ? _pfxworkerthread+0x10/0x10 kthread+0x293/0x360 ? _pfxkthread+0x10/0x10 retfromfork+0x2f/0x70 ? _pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK> Allocated by task 34: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 _kasankmalloc+0x8f/0xa0 _hciconnadd+0x187/0x17d0 hciconnectsco+0x2e1/0xb90 scosockconnect+0x2a2/0xb80 _sysconnect+0x227/0x2a0 _x64sysconnect+0x6d/0xb0 dosyscall64+0x71/0x140 entrySYSCALL64afterhwframe+0x76/0x7e Freed by task 37: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3b/0x60 _kasanslabfree+0x101/0x160 kfree+0xd0/0x250 devicerelease+0x9a/0x210 kobjectput+0x151/0x280 hciconndel+0x448/0xbf0 hciabortconnsync+0x46f/0x980 hcicmdsyncwork+0x1c2/0x330 processonework+0x7d9/0x1360 workerthread+0x5b7/0xf60 kthread+0x293/0x360 retfromfork+0x2f/0x70 retfromforkasm+0x1a/0x30(CVE-2024-50029)

In the Linux kernel, the following vulnerability has been resolved: slip: make slhcremember() more robust against malicious packets syzbot found that slhcremember() was missing checks against malicious packets [1]. slhcremember() only checked the size of the packet was at least 20, which is not good enough. We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried. Add iph and th pointers to make the code more readable. [1] BUG: KMSAN: uninit-value in slhcremember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 slhcremember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 pppreceivenonmpframe+0xe45/0x35e0 drivers/net/ppp/pppgeneric.c:2455 pppreceiveframe drivers/net/ppp/pppgeneric.c:2372 [inline] pppdorecv+0x65f/0x40d0 drivers/net/ppp/pppgeneric.c:2212 pppinput+0x7dc/0xe60 drivers/net/ppp/pppgeneric.c:2327 pppoercvcore+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 skbacklogrcv+0x13b/0x420 include/net/sock.h:1113 releasesock+0x1da/0x330 net/core/sock.c:3072 releasesock+0x6b/0x250 net/core/sock.c:3626 pppoesendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 socksendmsgnosec net/socket.c:729 [inline] _socksendmsg+0x30f/0x380 net/socket.c:744 syssendmsg+0x903/0xb60 net/socket.c:2602 syssendmsg+0x28d/0x3c0 net/socket.c:2656 _syssendmmsg+0x3c1/0x960 net/socket.c:2742 _dosyssendmmsg net/socket.c:2771 [inline] _sesyssendmmsg net/socket.c:2768 [inline] _x64syssendmmsg+0xbc/0x120 net/socket.c:2768 x64syscall+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls64.h:308 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f Uninit was created at: slabpostallochook mm/slub.c:4091 [inline] slaballocnode mm/slub.c:4134 [inline] kmemcacheallocnodenoprof+0x6bf/0xb80 mm/slub.c:4186 kmallocreserve+0x13d/0x4a0 net/core/skbuff.c:587 _allocskb+0x363/0x7b0 net/core/skbuff.c:678 allocskb include/linux/skbuff.h:1322 [inline] sockwmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoesendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 socksendmsgnosec net/socket.c:729 [inline] _socksendmsg+0x30f/0x380 net/socket.c:744 syssendmsg+0x903/0xb60 net/socket.c:2602 _syssendmsg+0x28d/0x3c0 net/socket.c:2656 _syssendmmsg+0x3c1/0x960 net/socket.c:2742 _dosyssendmmsg net/socket.c:2771 [inline] _sesyssendmmsg net/socket.c:2768 [inline] _x64syssendmmsg+0xbc/0x120 net/socket.c:2768 x64syscall+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls64.h:308 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024(CVE-2024-50033)

In the Linux kernel, the following vulnerability has been resolved: net: do not delay dstentriesadd() in dstrelease() dstentriesadd() uses per-cpu data that might be freed at netns dismantle from ip6routenetexit() calling dstentriesdestroy() Before ip6routenetexit() can be called, we release all the dsts associated with this netns, via calls to dstrelease(), which waits an rcu grace period before calling dstdestroy() dstentriesadd() use in dstdestroy() is racy, because dstentriesdestroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIGXFRM case, dstdestroy() can call dstreleaseimmediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.(CVE-2024-50036)

In the Linux kernel, the following vulnerability has been resolved: igb: Do not bring the device up after non-fatal error Commit 004d25060c78 ("igb: Fix igbdown hung on surprise removal") changed igbioerrordetected() to ignore non-fatal pcie errors in order to avoid hung task that can happen when igbdown() is called multiple times. This caused an issue when processing transient non-fatal errors. igbioresume(), which is called after igbioerrordetected(), assumes that device is brought down by igbioerrordetected() if the interface is up. This resulted in panic with stacktrace below. [ T3256] igb 0000:09:00.0 haeth0: igb: haeth0 NIC Link is Down [ T292] pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:09:00.0 [ T292] igb 0000:09:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID) [ T292] igb 0000:09:00.0: device [8086:1537] error status/mask=00004000/00000000 [ T292] igb 0000:09:00.0: [14] CmpltTO [ 200.105524,009][ T292] igb 0000:09:00.0: AER: TLP Header: 00000000 00000000 00000000 00000000 [ T292] pcieport 0000:00:1c.5: AER: broadcast errordetected message [ T292] igb 0000:09:00.0: Non-correctable non-fatal error reported. [ T292] pcieport 0000:00:1c.5: AER: broadcast mmioenabled message [ T292] pcieport 0000:00:1c.5: AER: broadcast resume message [ T292] ------------[ cut here ]------------ [ T292] kernel BUG at net/core/dev.c:6539! [ T292] invalid opcode: 0000 [#1] PREEMPT SMP [ T292] RIP: 0010:napienable+0x37/0x40 [ T292] Call Trace: [ T292] <TASK> [ T292] ? die+0x33/0x90 [ T292] ? dotrap+0xdc/0x110 [ T292] ? napienable+0x37/0x40 [ T292] ? doerrortrap+0x70/0xb0 [ T292] ? napienable+0x37/0x40 [ T292] ? napienable+0x37/0x40 [ T292] ? excinvalidop+0x4e/0x70 [ T292] ? napienable+0x37/0x40 [ T292] ? asmexcinvalidop+0x16/0x20 [ T292] ? napienable+0x37/0x40 [ T292] igbup+0x41/0x150 [ T292] igbioresume+0x25/0x70 [ T292] reportresume+0x54/0x70 [ T292] ? reportfrozendetected+0x20/0x20 [ T292] pciwalkbus+0x6c/0x90 [ T292] ? aerprintportinfo+0xa0/0xa0 [ T292] pciedorecovery+0x22f/0x380 [ T292] aerprocesserrdevices+0x110/0x160 [ T292] aerisr+0x1c1/0x1e0 [ T292] ? disableirqnosync+0x10/0x10 [ T292] irqthreadfn+0x1a/0x60 [ T292] irqthread+0xe3/0x1a0 [ T292] ? irqsetaffinitynotifier+0x120/0x120 [ T292] ? irqaffinitynotify+0x100/0x100 [ T292] kthread+0xe2/0x110 [ T292] ? kthreadcompleteandexit+0x20/0x20 [ T292] retfromfork+0x2d/0x50 [ T292] ? kthreadcompleteandexit+0x20/0x20 [ T292] retfromforkasm+0x11/0x20 [ T292] </TASK> To fix this issue igbioresume() checks if the interface is running and the device is not down this means igbioerrordetected() did not bring the device down and there is no need to bring it up.(CVE-2024-50040)

In the Linux kernel, the following vulnerability has been resolved: i40e: Fix macvlan leak by synchronizing access to macfilterhash This patch addresses a macvlan leak issue in the i40e driver caused by concurrent access to vsi->macfilterhash. The leak occurs when multiple threads attempt to modify the macfilterhash simultaneously, leading to inconsistent state and potential memory leaks. To fix this, we now wrap the calls to i40edelmacfilter() and zeroing vf->defaultlanaddr.addr with spinlock/unlockbh(&vsi->macfilterhashlock), ensuring atomic operations and preventing concurrent access. Additionally, we add lockdepassertheld(&vsi->macfilterhashlock) in i40eaddmacfilter() to help catch similar issues in the future. Reproduction steps: 1. Spawn VFs and configure port vlan on them. 2. Trigger concurrent macvlan operations (e.g., adding and deleting portvlan and/or mac filters). 3. Observe the potential memory leak and inconsistent state in the macfilterhash. This synchronization ensures the integrity of the macfilterhash and prevents the described leak.(CVE-2024-50041)

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix UAF in async decryption Doing an async decryption (large read) crashes with a slab-use-after-free way down in the crypto API. Reproducer: # mount.cifs -o ...,seal,esize=1 //srv/share /mnt # dd if=/mnt/largefile of=/dev/null ... [ 194.196391] ================================================================== [ 194.196844] BUG: KASAN: slab-use-after-free in gf128mul4klle+0xc1/0x110 [ 194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899 [ 194.197707] [ 194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty #43 [ 194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 [ 194.199046] Workqueue: smb3decryptd smb2decryptoffload [cifs] [ 194.200032] Call Trace: [ 194.200191] <TASK> [ 194.200327] dumpstacklvl+0x4e/0x70 [ 194.200558] ? gf128mul4klle+0xc1/0x110 [ 194.200809] printreport+0x174/0x505 [ 194.201040] ? pfxrawspinlockirqsave+0x10/0x10 [ 194.201352] ? srsoreturnthunk+0x5/0x5f [ 194.201604] ? _virtaddrvalid+0xdf/0x1c0 [ 194.201868] ? gf128mul4klle+0xc1/0x110 [ 194.202128] kasanreport+0xc8/0x150 [ 194.202361] ? gf128mul4klle+0xc1/0x110 [ 194.202616] gf128mul4klle+0xc1/0x110 [ 194.202863] ghashupdate+0x184/0x210 [ 194.203103] shashahashupdate+0x184/0x2a0 [ 194.203377] ? _pfxshashahashupdate+0x10/0x10 [ 194.203651] ? srsoreturnthunk+0x5/0x5f [ 194.203877] ? cryptogcminitcommon+0x1ba/0x340 [ 194.204142] gcmhashassocremaincontinue+0x10a/0x140 [ 194.204434] cryptmessage+0xec1/0x10a0 [cifs] [ 194.206489] ? _pfxcryptmessage+0x10/0x10 [cifs] [ 194.208507] ? srsoreturnthunk+0x5/0x5f [ 194.209205] ? srsoreturnthunk+0x5/0x5f [ 194.209925] ? srsoreturnthunk+0x5/0x5f [ 194.210443] ? srsoreturnthunk+0x5/0x5f [ 194.211037] decryptrawdata+0x15f/0x250 [cifs] [ 194.212906] ? _pfxdecryptrawdata+0x10/0x10 [cifs] [ 194.214670] ? srsoreturnthunk+0x5/0x5f [ 194.215193] smb2decryptoffload+0x12a/0x6c0 [cifs] This is because TFM is being used in parallel. Fix this by allocating a new AEAD TFM for async decryption, but keep the existing one for synchronous READ cases (similar to what is done in smb3calcsignature()). Also remove the calls to aeadrequestsetcallback() and cryptowait_req() since it's always going to be a synchronous operation.(CVE-2024-50047)

In the Linux kernel, the following vulnerability has been resolved: driver core: bus: Fix double free in driver API busregister() For busregister(), any error which happens after kset_register() will cause that @priv are freed twice, fixed by setting @priv with NULL after the first free.(CVE-2024-50055)

In the Linux kernel, the following vulnerability has been resolved: serial: protect uartportdtrrts() in uartshutdown() too Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uartshutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected "uartportdtrrts(uport, false);" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks.(CVE-2024-50058)

In the Linux kernel, the following vulnerability has been resolved: ntb: ntbhwswitchtec: Fix use after free vulnerability in switchtecntbremove due to race condition In the switchtecntbadd function, it can call switchtecntbinitsndev function, then &sndev->checklinkstatuswork is bound with checklinkstatuswork. switchtecntblinknotification may be called to start the work. If we remove the module which will call switchtecntbremove to make cleanup, it will free sndev through kfree(sndev), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | checklinkstatuswork switchtecntbremove | kfree(sndev); | | if (sndev->linkforcedown) | // use sndev Fix it by ensuring that the work is canceled before proceeding with the cleanup in switchtecntb_remove.(CVE-2024-50059)

In the Linux kernel, the following vulnerability has been resolved: io_uring: check if we need to reschedule during overflow flush In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it'll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while. Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There's no state to maintain here as overflows always prune from head-of-list, hence it's fine to drop and reacquire the locks at the end of the loop.(CVE-2024-50060)

In the Linux kernel, the following vulnerability has been resolved: bpf: Prevent tail call between progs attached to different hooks bpf progs can be attached to kernel functions, and the attached functions can take different parameters or return different return values. If prog attached to one kernel function tail calls prog attached to another kernel function, the ctx access or return value verification could be bypassed. For example, if prog1 is attached to func1 which takes only 1 parameter and prog2 is attached to func2 which takes two parameters. Since verifier assumes the bpf ctx passed to prog2 is constructed based on func2's prototype, verifier allows prog2 to access the second parameter from the bpf ctx passed to it. The problem is that verifier does not prevent prog1 from passing its bpf ctx to prog2 via tail call. In this case, the bpf ctx passed to prog2 is constructed from func1 instead of func2, that is, the assumption for ctx access verification is bypassed. Another example, if BPF LSM prog1 is attached to hook fileallocsecurity, and BPF LSM prog2 is attached to hook bpflsmauditruleknown. Verifier knows the return value rules for these two hooks, e.g. it is legal for bpflsmauditruleknown to return positive number 1, and it is illegal for fileallocsecurity to return positive number. So verifier allows prog2 to return positive number 1, but does not allow prog1 to return positive number. The problem is that verifier does not prevent prog1 from calling prog2 via tail call. In this case, prog2's return value 1 will be used as the return value for prog1's hook fileallocsecurity. That is, the return value rule is bypassed. This patch adds restriction for tail call to prevent such bypasses.(CVE-2024-50063)

In the Linux kernel, the following vulnerability has been resolved: zram: free secondary algorithms names We need to kfree() secondary algorithms names when reset zram device that had multi-streams, otherwise we leak memory. [senozhatsky@chromium.org: kfree(NULL) is legal] Link: https://lkml.kernel.org/r/20240917013021.868769-1-senozhatsky@chromium.org(CVE-2024-50064)

In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix movenormalpmd/retractpagetables race In mremap(), movepagetables() looks at the type of the PMD entry and the specified address range to figure out by which method the next chunk of page table entries should be moved. At that point, the mmaplock is held in write mode, but no rmap locks are held yet. For PMD entries that point to page tables and are fully covered by the source address range, movepgtentry(NORMALPMD, ...) is called, which first takes rmap locks, then does movenormalpmd(). movenormalpmd() takes the necessary page table locks at source and destination, then moves an entire page table from the source to the destination. The problem is: The rmap locks, which protect against concurrent page table removal by retractpagetables() in the THP code, are only taken after the PMD entry has been read and it has been decided how to move it. So we can race as follows (with two processes that have mappings of the same tmpfs file that is stored on a tmpfs mount with huge=advise); note that process A accesses page tables through the MM while process B does it through the file rmap: process A process B ========= ========= mremap mremapto movevma movepagetables getoldpmd allocnewpmd * PREEMPT * madvise(MADVCOLLAPSE) domadvise madvisewalkvmas madvisevmabehavior madvisecollapse hpagecollapsescanfile collapsefile retractpagetables immaplockread(mapping) pmdpcollapseflush immapunlockread(mapping) movepgtentry(NORMALPMD, ...) takermaplocks movenormalpmd droprmaplocks When this happens, movenormalpmd() can end up creating bogus PMD entries in the line pmd_populate(mm, new_pmd, pmd_pgtable(pmd)). The effect depends on arch-specific and machine-specific details; on x86, you can end up with physical page 0 mapped as a page table, which is likely exploitable for user->kernel privilege escalation. Fix the race by letting process B recheck that the PMD still points to a page table after the rmap locks have been taken. Otherwise, we bail and let the caller fall back to the PTE-level copying path, which will then bail immediately at the pmdnone() check. Bug reachability: Reaching this bug requires that you can create shmem/file THP mappings - anonymous THP uses different code that doesn't zap stuff under rmap locks. File THP is gated on an experimental config flag (CONFIGREADONLYTHPFORFS), so on normal distro kernels you need shmem THP to hit this bug. As far as I know, getting shmem THP normally requires that you can mount your own tmpfs with the right mount flags, which would require creating your own user+mount namespace; though I don't know if some distros maybe enable shmem THP by default or something like that. Bug impact: This issue can likely be used for user->kernel privilege escalation when it is reachable.(CVE-2024-50066)

In the Linux kernel, the following vulnerability has been resolved: uprobe: avoid out-of-bounds memory access of fetching args Uprobe needs to fetch args into a percpu buffer, and then copy to ring buffer to avoid non-atomic context problem. Sometimes user-space strings, arrays can be very large, but the size of percpu buffer is only page size. And storetraceargs() won't check whether these data exceeds a single page or not, caused out-of-bounds memory access. It could be reproduced by following steps: 1. build kernel with CONFIGKASAN enabled 2. save follow program as test.c \#include <stdio.h> \#include <stdlib.h> \#include <string.h> // If string length large than MAX_STRING_SIZE, the fetch_store_strlen() // will return 0, cause __get_data_size() return shorter size, and // store_trace_args() will not trigger out-of-bounds access. // So make string length less than 4096. \#define STRLEN 4093 void generate_string(char *str, int n) { int i; for (i = 0; i < n; ++i) { char c = i % 26 + 'a'; str[i] = c; } str[n-1] = '\0'; } void print_string(char *str) { printf("%s\n", str); } int main() { char tmp[STRLEN]; generate_string(tmp, STRLEN); print_string(tmp); return 0; } 3. compile program gcc -o test test.c 4. get the offset of print_string() objdump -t test | grep -w print_string 0000000000401199 g F .text 000000000000001b print_string 5. configure uprobe with offset 0x1199 off=0x1199 cd /sys/kernel/debug/tracing/ echo "p /root/test:${off} arg1=+0(%di):ustring arg2=\$comm arg3=+0(%di):ustring" > uprobe_events echo 1 > events/uprobes/enable echo 1 > tracing_on 6. run test, and kasan will report error. ================================================================== BUG: KASAN: use-after-free in strncpyfromuser+0x1d6/0x1f0 Write of size 8 at addr ffff88812311c004 by task test/499CPU: 0 UID: 0 PID: 499 Comm: test Not tainted 6.12.0-rc3+ #18 Hardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x55/0x70 printaddressdescription.constprop.0+0x27/0x310 kasanreport+0x10f/0x120 ? strncpyfromuser+0x1d6/0x1f0 strncpyfromuser+0x1d6/0x1f0 ? rmqueue.constprop.0+0x70d/0x2ad0 processfetchinsn+0xb26/0x1470 ? pfxprocessfetchinsn+0x10/0x10 ? _rawspinlock+0x85/0xe0 ? _pfxrawspinlock+0x10/0x10 ? pteoffsetmap+0x1f/0x2d0 ? unwindnextframe+0xc5f/0x1f80 ? archstackwalk+0x68/0xf0 ? isbpftextaddress+0x23/0x30 ? kerneltextaddress.part.0+0xbb/0xd0 ? _kerneltextaddress+0x66/0xb0 ? unwindgetreturnaddress+0x5e/0xa0 ? _pfxstacktraceconsumeentry+0x10/0x10 ? archstackwalk+0xa2/0xf0 ? rawspinlockirqsave+0x8b/0xf0 ? _pfxrawspinlockirqsave+0x10/0x10 ? depotallocstack+0x4c/0x1f0 ? rawspinunlockirqrestore+0xe/0x30 ? stackdepotsaveflags+0x35d/0x4f0 ? kasansavestack+0x34/0x50 ? kasansavestack+0x24/0x50 ? mutexlock+0x91/0xe0 ? _pfxmutexlock+0x10/0x10 prepareuprobebuffer.part.0+0x2cd/0x500 uprobedispatcher+0x2c3/0x6a0 ? _pfxuprobedispatcher+0x10/0x10 ? _kasanslaballoc+0x4d/0x90 handlerchain+0xdd/0x3e0 handleswbp+0x26e/0x3d0 ? _pfxhandleswbp+0x10/0x10 ? uprobepresstepnotifier+0x151/0x1b0 irqentryexittousermode+0xe2/0x1b0 asmexcint3+0x39/0x40 RIP: 0033:0x401199 Code: 01 c2 0f b6 45 fb 88 02 83 45 fc 01 8b 45 fc 3b 45 e4 7c b7 8b 45 e4 48 98 48 8d 50 ff 48 8b 45 e8 48 01 d0 ce RSP: 002b:00007ffdf00576a8 EFLAGS: 00000206 RAX: 00007ffdf00576b0 RBX: 0000000000000000 RCX: 0000000000000ff2 RDX: 0000000000000ffc RSI: 0000000000000ffd RDI: 00007ffdf00576b0 RBP: 00007ffdf00586b0 R08: 00007feb2f9c0d20 R09: 00007feb2f9c0d20 R10: 0000000000000001 R11: 0000000000000202 R12: 0000000000401040 R13: 00007ffdf0058780 R14: 0000000000000000 R15: 0000000000000000 </TASK> This commit enforces the buffer's maxlen less than a page-size to avoid storetraceargs() out-of-memory access.(CVE-2024-50067)

In the Linux kernel, the following vulnerability has been resolved: pinctrl: stm32: check devmkasprintf() returned value devmkasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.(CVE-2024-50070)

In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Use code segment selector for VERW operand Robert Gill reported below #GP in 32-bit mode when dosemu software was executing vm86() system call: general protection fault: 0000 [#1] PREEMPT SMP CPU: 4 PID: 4610 Comm: dosemu.bin Not tainted 6.6.21-gentoo-x86 #1 Hardware name: Dell Inc. PowerEdge 1950/0H723K, BIOS 2.7.0 10/30/2010 EIP: restoreallswitchstack+0xbe/0xcf EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: 00000000 ESP: ff8affdc DS: 0000 ES: 0000 FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010046 CR0: 80050033 CR2: 00c2101c CR3: 04b6d000 CR4: 000406d0 Call Trace: showregs+0x70/0x78 dieaddr+0x29/0x70 excgeneralprotection+0x13c/0x348 excbounds+0x98/0x98 handleexception+0x14d/0x14d excbounds+0x98/0x98 restoreallswitchstack+0xbe/0xcf excbounds+0x98/0x98 restoreallswitchstack+0xbe/0xcf This only happens in 32-bit mode when VERW based mitigations like MDS/RFDS are enabled. This is because segment registers with an arbitrary user value can result in #GP when executing VERW. Intel SDM vol. 2C documents the following behavior for VERW instruction: #GP(0) - If a memory operand effective address is outside the CS, DS, ES, FS, or GS segment limit. CLEARCPU_BUFFERS macro executes VERW instruction before returning to user space. Use %cs selector to reference VERW operand. This ensures VERW will not #GP for an arbitrary user %ds. mingo: Fixed the SOB chain.

In the Linux kernel, the following vulnerability has been resolved: parport: Proper fix for array out-of-bounds access The recent fix for array out-of-bounds accesses replaced sprintf() calls blindly with snprintf(). However, since snprintf() returns the would-be-printed size, not the actually output size, the length calculation can still go over the given limit. Use scnprintf() instead of snprintf(), which returns the actually output letters, for addressing the potential out-of-bounds access properly.(CVE-2024-50074)

In the Linux kernel, the following vulnerability has been resolved: vt: prevent kernel-infoleak in confontget() font.data may not initialize all memory spaces depending on the implementation of vc->vcsw->confont_get. This may cause info-leak, so to prevent this, it is safest to modify it to initialize the allocated memory space to 0, and it generally does not affect the overall performance of the system.(CVE-2024-50076)

In the Linux kernel, the following vulnerability has been resolved: tcp: fix mptcp DSS corruption due to large pmtu xmit Syzkaller was able to trigger a DSS corruption: TCP: requestsocksubflowv4: Possible SYN flooding on port [::]:20002. Sending cookies. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 mptcpmoveskbsfromsubflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Modules linked in: CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:mptcpmoveskbsfromsubflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 <0f> 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff RSP: 0018:ffffc90000006db8 EFLAGS: 00010246 RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00 RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0 RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8 R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000 R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5 FS: 000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> moveskbstomsk net/mptcp/protocol.c:811 [inline] mptcpdataready+0x29c/0xa90 net/mptcp/protocol.c:854 subflowdataready+0x34a/0x920 net/mptcp/subflow.c:1490 tcpdataqueue+0x20fd/0x76c0 net/ipv4/tcpinput.c:5283 tcprcvestablished+0xfba/0x2020 net/ipv4/tcpinput.c:6237 tcpv4dorcv+0x96d/0xc70 net/ipv4/tcpipv4.c:1915 tcpv4rcv+0x2dc0/0x37f0 net/ipv4/tcpipv4.c:2350 ipprotocoldeliverrcu+0x22e/0x440 net/ipv4/ipinput.c:205 iplocaldeliverfinish+0x341/0x5f0 net/ipv4/ipinput.c:233 NFHOOK+0x3a4/0x450 include/linux/netfilter.h:314 NFHOOK+0x3a4/0x450 include/linux/netfilter.h:314 _netifreceiveskbonecore net/core/dev.c:5662 [inline] _netifreceiveskb+0x2bf/0x650 net/core/dev.c:5775 processbacklog+0x662/0x15b0 net/core/dev.c:6107 _napipoll+0xcb/0x490 net/core/dev.c:6771 napipoll net/core/dev.c:6840 [inline] netrxaction+0x89b/0x1240 net/core/dev.c:6962 handlesoftirqs+0x2c5/0x980 kernel/softirq.c:554 dosoftirq+0x11b/0x1e0 kernel/softirq.c:455 </IRQ> <TASK> _localbhenableip+0x1bb/0x200 kernel/softirq.c:382 localbhenable include/linux/bottomhalf.h:33 [inline] rcureadunlockbh include/linux/rcupdate.h:919 [inline] _devqueuexmit+0x1764/0x3e80 net/core/dev.c:4451 devqueuexmit include/linux/netdevice.h:3094 [inline] neighhhoutput include/net/neighbour.h:526 [inline] neighoutput include/net/neighbour.h:540 [inline] ipfinishoutput2+0xd41/0x1390 net/ipv4/ipoutput.c:236 iplocalout net/ipv4/ipoutput.c:130 [inline] _ipqueuexmit+0x118c/0x1b80 net/ipv4/ipoutput.c:536 _tcptransmitskb+0x2544/0x3b30 net/ipv4/tcpoutput.c:1466 tcptransmitskb net/ipv4/tcpoutput.c:1484 [inline] tcpmtuprobe net/ipv4/tcpoutput.c:2547 [inline] tcpwritexmit+0x641d/0x6bf0 net/ipv4/tcpoutput.c:2752 _tcppushpendingframes+0x9b/0x360 net/ipv4/tcpoutput.c:3015 tcppushpendingframes include/net/tcp.h:2107 [inline] tcpdatasndcheck net/ipv4/tcpinput.c:5714 [inline] tcprcvestablished+0x1026/0x2020 net/ipv4/tcpinput.c:6239 tcpv4dorcv+0x96d/0xc70 net/ipv4/tcpipv4.c:1915 skbacklogrcv include/net/sock.h:1113 [inline] _releasesock+0x214/0x350 net/core/sock.c:3072 releasesock+0x61/0x1f0 net/core/sock.c:3626 mptcppush ---truncated---(CVE-2024-50083)

In the Linux kernel, the following vulnerability has been resolved: net: microchip: vcap api: Fix memory leaks in vcapapiencoderuletest() Commit a3c1e45156ad ("net: microchip: vcap: Fix use-after-free error in kunit test") fixed the use-after-free error, but introduced below memory leaks by removing necessary vcapfreerule(), add it to fix it. unreferenced object 0xffffff80ca58b700 (size 192): comm "kunittrycatch", pid 1215, jiffies 4294898264 hex dump (first 32 bytes): 00 12 7a 00 05 00 00 00 0a 00 00 00 64 00 00 00 ..z.........d... 00 00 00 00 00 00 00 00 00 04 0b cc 80 ff ff ff ................ backtrace (crc 9c09c3fe): [<0000000052a0be73>] kmemleakalloc+0x34/0x40 [<0000000043605459>] _kmalloccachenoprof+0x26c/0x2f4 [<0000000040a01b8d>] vcapallocrule+0x3cc/0x9c4 [<000000003fe86110>] vcapapiencoderuletest+0x1ac/0x16b0 [<00000000b3595fc4>] kunittryruncase+0x13c/0x3ac [<0000000010f5d2bf>] kunitgenericrunthreadfnadapter+0x80/0xec [<00000000c5d82c9a>] kthread+0x2e8/0x374 [<00000000f4287308>] retfromfork+0x10/0x20 unreferenced object 0xffffff80cc0b0400 (size 64): comm "kunittrycatch", pid 1215, jiffies 4294898265 hex dump (first 32 bytes): 80 04 0b cc 80 ff ff ff 18 b7 58 ca 80 ff ff ff ..........X..... 39 00 00 00 02 00 00 00 06 05 04 03 02 01 ff ff 9............... backtrace (crc daf014e9): [<0000000052a0be73>] kmemleakalloc+0x34/0x40 [<0000000043605459>] _kmalloccachenoprof+0x26c/0x2f4 [<000000000ff63fd4>] vcapruleaddkey+0x2cc/0x528 [<00000000dfdb1e81>] vcapapiencoderuletest+0x224/0x16b0 [<00000000b3595fc4>] kunittryruncase+0x13c/0x3ac [<0000000010f5d2bf>] kunitgenericrunthreadfnadapter+0x80/0xec [<00000000c5d82c9a>] kthread+0x2e8/0x374 [<00000000f4287308>] retfromfork+0x10/0x20 unreferenced object 0xffffff80cc0b0700 (size 64): comm "kunittrycatch", pid 1215, jiffies 4294898265 hex dump (first 32 bytes): 80 07 0b cc 80 ff ff ff 28 b7 58 ca 80 ff ff ff ........(.X..... 3c 00 00 00 00 00 00 00 01 2f 03 b3 ec ff ff ff <......../...... backtrace (crc 8d877792): [<0000000052a0be73>] kmemleakalloc+0x34/0x40 [<0000000043605459>] _kmalloccachenoprof+0x26c/0x2f4 [<000000006eadfab7>] vcapruleaddaction+0x2d0/0x52c [<00000000323475d1>] vcapapiencoderuletest+0x4d4/0x16b0 [<00000000b3595fc4>] kunittryruncase+0x13c/0x3ac [<0000000010f5d2bf>] kunitgenericrunthreadfnadapter+0x80/0xec [<00000000c5d82c9a>] kthread+0x2e8/0x374 [<00000000f4287308>] retfromfork+0x10/0x20 unreferenced object 0xffffff80cc0b0900 (size 64): comm "kunittrycatch", pid 1215, jiffies 4294898266 hex dump (first 32 bytes): 80 09 0b cc 80 ff ff ff 80 06 0b cc 80 ff ff ff ................ 7d 00 00 00 01 00 00 00 00 00 00 00 ff 00 00 00 }............... backtrace (crc 34181e56): [<0000000052a0be73>] kmemleakalloc+0x34/0x40 [<0000000043605459>] _kmalloccachenoprof+0x26c/0x2f4 [<000000000ff63fd4>] vcapruleaddkey+0x2cc/0x528 [<00000000991e3564>] vcapvalrule+0xcf0/0x13e8 [<00000000fc9868e5>] vcapapiencoderuletest+0x678/0x16b0 [<00000000b3595fc4>] kunittryruncase+0x13c/0x3ac [<0000000010f5d2bf>] kunitgenericrunthreadfnadapter+0x80/0xec [<00000000c5d82c9a>] kthread+0x2e8/0x374 [<00000000f4287308>] retfromfork+0x10/0x20 unreferenced object 0xffffff80cc0b0980 (size 64): comm "kunittrycatch", pid 1215, jiffies 4294898266 hex dump (first 32 bytes): 18 b7 58 ca 80 ff ff ff 00 09 0b cc 80 ff ff ff ..X............. 67 00 00 00 00 00 00 00 01 01 74 88 c0 ff ff ff g.........t..... backtrace (crc 275fd9be): [<0000000052a0be73>] kmemleakalloc+0x34/0x40 [<0000000043605459>] _kmalloccachenoprof+0x26c/0x2f4 [<000000000ff63fd4>] vcapruleaddkey+0x2cc/0x528 [<000000001396a1a2>] testaddde ---truncated---(CVE-2024-50084)

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free on readalloconename() error The function readalloconename() does not initialize the name field of the passed fscryptstr struct if kmalloc fails to allocate the corresponding buffer. Thus, it is not guaranteed that fscryptstr.name is initialized when freeing it. This is a follow-up to the linked patch that fixes the remaining instances of the bug introduced by commit e43eec81c516 ("btrfs: use struct qstr instead of name and namelen pairs").(CVE-2024-50087)

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free in addinoderef() The addinoderef() function does not initialize the "name" struct when it is declared. If any of the following calls to "readoneinode() returns NULL, dir = readoneinode(root, parentobjectid); if (!dir) { ret = -ENOENT; goto out; } inode = readoneinode(root, inodeobjectid); if (!inode) { ret = -EIO; goto out; } then "name.name" would be freed on "out" before being initialized. out: ... kfree(name.name); This issue was reported by Coverity with CID 1526744.(CVE-2024-50088)