The Linux Kernel, the operating system core itself.

Security Fix(es):

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

ext4: don't set SB_RDONLY after filesystem errors

When the filesystem is mounted with errors=remount-ro, we were setting SBRDONLY flag to stop all filesystem modifications. We knew this misses proper locking (sb->sumount) and does not go through proper filesystem remount procedure but it has been the way this worked since early ext2 days and it was good enough for catastrophic situation damage mitigation. Recently, syzbot has found a way (see link) to trigger warnings in filesystem freezing because the code got confused by SBRDONLY changing under its hands. Since these days we set EXT4FLAGSSHUTDOWN on the superblock which is enough to stop all filesystem modifications, modifying SBRDONLY shouldn't be needed. So stop doing that.(CVE-2024-50191)

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

drm/i915/hdcp: Add encoder check in hdcp2getcapability

Add encoder check in intelhdcp2get_capability to avoid null pointer error.(CVE-2024-53050)

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

sched/taskstack: fix objectisonstack() for KASAN tagged pointers

When CONFIGKASANSWTAGS and CONFIGKASANSTACK are enabled, the objectisonstack() function may produce incorrect results due to the presence of tags in the obj pointer, while the stack pointer does not have tags. This discrepancy can lead to incorrect stack object detection and subsequently trigger warnings if CONFIGDEBUGOBJECTS is also enabled.

Example of the warning:

ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:557 _debugobjectinit+0x330/0x364 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5 #4 Hardware name: linux,dummy-virt (DT) pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : _debugobjectinit+0x330/0x364 lr : _debugobjectinit+0x330/0x364 sp : ffff800082ea7b40 x29: ffff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534 x26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c00172a0 x23: 0000000000000000 x22: ffff800082d93ed0 x21: ffff800081a24418 x20: 3eff800082ea7bb0 x19: efff800000000000 x18: 0000000000000000 x17: 00000000000000ff x16: 0000000000000047 x15: 206b63617473206e x14: 0000000000000018 x13: ffff800082ea7780 x12: 0ffff800082ea78e x11: 0ffff800082ea790 x10: 0ffff800082ea79d x9 : 34d77febe173e800 x8 : 34d77febe173e800 x7 : 0000000000000001 x6 : 0000000000000001 x5 : feff800082ea74b8 x4 : ffff800082870a90 x3 : ffff80008018d3c4 x2 : 0000000000000001 x1 : ffff800082858810 x0 : 0000000000000050 Call trace: _debugobjectinit+0x330/0x364 debugobjectinitonstack+0x30/0x3c schedulehrtimeoutrangeclock+0xac/0x26c schedulehrtimeout+0x1c/0x30 waittaskinactive+0x1d4/0x25c kthreadbindmask+0x28/0x98 initrescuer+0x1e8/0x280 workqueueinit+0x1a0/0x3cc kernelinitfreeable+0x118/0x200 kernelinit+0x28/0x1f0 retfrom_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------(CVE-2024-53128)

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

ALSA: usb-audio: Fix out of bounds reads when finding clock sources

The current USB-audio driver code doesn't check bLength of each descriptor at traversing for clock descriptors. That is, when a device provides a bogus descriptor with a shorter bLength, the driver might hit out-of-bounds reads.

For addressing it, this patch adds sanity checks to the validator functions for the clock descriptor traversal. When the descriptor length is shorter than expected, it's skipped in the loop.

For the clock source and clock multiplier descriptors, we can just check bLength against the sizeof() of each descriptor type. OTOH, the clock selector descriptor of UAC2 and UAC3 has an array of bNrInPins elements and two more fields at its tail, hence those have to be checked in addition to the sizeof() check.(CVE-2024-53150)

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

ocfs2: fix uninitialized value in ocfs2fileread_iter()

Syzbot has reported the following KMSAN splat:

BUG: KMSAN: uninit-value in ocfs2filereaditer+0x9a4/0xf80 ocfs2filereaditer+0x9a4/0xf80 _ioread+0x8d4/0x20f0 ioread+0x3e/0xf0 ioissuesqe+0x42b/0x22c0 iowqsubmitwork+0xaf9/0xdc0 ioworkerhandlework+0xd13/0x2110 iowqworker+0x447/0x1410 retfromfork+0x6f/0x90 retfromforkasm+0x1a/0x30

Uninit was created at: allocpagesnoprof+0x9a7/0xe00 allocpagesmpolnoprof+0x299/0x990 allocpagesnoprof+0x1bf/0x1e0 allocateslab+0x33a/0x1250 slaballoc+0x12ef/0x35e0 kmemcacheallocbulknoprof+0x486/0x1330 _ioallocreqrefill+0x84/0x560 iosubmitsqes+0x172f/0x2f30 _sesysiouringenter+0x406/0x41c0 _x64sysiouringenter+0x11f/0x1a0 x64syscall+0x2b54/0x3ba0 dosyscall64+0xcd/0x1e0 entrySYSCALL64afterhwframe+0x77/0x7f

Since an instance of 'struct kiocb' may be passed from the block layer with 'private' field uninitialized, introduce 'ocfs2iocbinitrwlocked()' and use it from where 'ocfs2dioendio()' might take care, i.e. in 'ocfs2filereaditer()' and 'ocfs2filewrite_iter()'.(CVE-2024-53155)

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

firmware: arm_scpi: Check the DVFS OPP count returned by the firmware

Fix a kernel crash with the below call trace when the SCPI firmware returns OPP count of zero.

dvfsinfo.oppcount may be zero on some platforms during the reboot test, and the kernel will crash after dereferencing the pointer to kcalloc(info->count, sizeof(*opp), GFP_KERNEL).

| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028 | Mem abort info: | ESR = 0x96000004 | Exception class = DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | Data abort info: | ISV = 0, ISS = 0x00000004 | CM = 0, WnR = 0 | user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000faefa08c | [0000000000000028] pgd=0000000000000000 | Internal error: Oops: 96000004 [#1] SMP | scpi-hwmon: probe of PHYT000D:00 failed with error -110 | Process systemd-udevd (pid: 1701, stack limit = 0x00000000aaede86c) | CPU: 2 PID: 1701 Comm: systemd-udevd Not tainted 4.19.90+ #1 | Hardware name: PHYTIUM LTD Phytium FT2000/4/Phytium FT2000/4, BIOS | pstate: 60000005 (nZCv daif -PAN -UAO) | pc : scpidvfsrecalcrate+0x40/0x58 [clkscpi] | lr : clkregister+0x438/0x720 | Call trace: | scpidvfsrecalcrate+0x40/0x58 [clkscpi] | devmclkhwregister+0x50/0xa0 | scpiclkopsinit.isra.2+0xa0/0x138 [clkscpi] | scpiclocksprobe+0x528/0x70c [clkscpi] | platformdrvprobe+0x58/0xa8 | reallyprobe+0x260/0x3d0 | driverprobedevice+0x12c/0x148 | devicedriverattach+0x74/0x98 | _driverattach+0xb4/0xe8 | busforeachdev+0x88/0xe0 | driverattach+0x30/0x40 | busadddriver+0x178/0x2b0 | driverregister+0x64/0x118 | _platformdriverregister+0x54/0x60 | scpiclocksdriverinit+0x24/0x1000 [clkscpi] | dooneinitcall+0x54/0x220 | doinitmodule+0x54/0x1c8 | loadmodule+0x14a4/0x1668 | _sesysfinitmodule+0xf8/0x110 | _arm64sysfinitmodule+0x24/0x30 | el0svccommon+0x78/0x170 | el0svchandler+0x38/0x78 | el0svc+0x8/0x340 | Code: 937d7c00 a94153f3 a8c27bfd f9400421 (b8606820) | ---[ end trace 06feb22469d89fa8 ]--- | Kernel panic - not syncing: Fatal exception | SMP: stopping secondary CPUs | Kernel Offset: disabled | CPU features: 0x10,a0002008 | Memory Limit: none(CVE-2024-53157)

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

soc: qcom: geni-se: fix array underflow in geniseclktblget()

This loop is supposed to break if the frequency returned from clkroundrate() is the same as on the previous iteration. However, that check doesn't make sense on the first iteration through the loop. It leads to reading before the start of these->clkperftbl[] array.(CVE-2024-53158)

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-53159)

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

rcu/kvfree: Fix data-race in _modtimer / kvfreecallrcu

KCSAN reports a data race when access the krcp->monitorwork.timer.expires variable in the scheduledelayedmonitorwork() function:

<snip> BUG: KCSAN: data-race in _modtimer / kvfreecallrcu

read to 0xffff888237d1cce8 of 8 bytes by task 10149 on cpu 1: scheduledelayedmonitorwork kernel/rcu/tree.c:3520 [inline] kvfreecallrcu+0x3b8/0x510 kernel/rcu/tree.c:3839 trieupdateelem+0x47c/0x620 kernel/bpf/lpmtrie.c:441 bpfmapupdatevalue+0x324/0x350 kernel/bpf/syscall.c:203 genericmapupdatebatch+0x401/0x520 kernel/bpf/syscall.c:1849 bpfmapdobatch+0x28c/0x3f0 kernel/bpf/syscall.c:5143 _sysbpf+0x2e5/0x7a0 _dosysbpf kernel/bpf/syscall.c:5741 [inline] _sesysbpf kernel/bpf/syscall.c:5739 [inline] _x64sysbpf+0x43/0x50 kernel/bpf/syscall.c:5739 x64syscall+0x2625/0x2d60 arch/x86/include/generated/asm/syscalls64.h:322 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xc9/0x1c0 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f

write to 0xffff888237d1cce8 of 8 bytes by task 56 on cpu 0: _modtimer+0x578/0x7f0 kernel/time/timer.c:1173 addtimerglobal+0x51/0x70 kernel/time/timer.c:1330 _queuedelayedwork+0x127/0x1a0 kernel/workqueue.c:2523 queuedelayedworkon+0xdf/0x190 kernel/workqueue.c:2552 queuedelayedwork include/linux/workqueue.h:677 [inline] scheduledelayedmonitorwork kernel/rcu/tree.c:3525 [inline] kfreercumonitor+0x5e8/0x660 kernel/rcu/tree.c:3643 processonework kernel/workqueue.c:3229 [inline] processscheduledworks+0x483/0x9a0 kernel/workqueue.c:3310 workerthread+0x51d/0x6f0 kernel/workqueue.c:3391 kthread+0x1d1/0x210 kernel/kthread.c:389 retfromfork+0x4b/0x60 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:244

Reported by Kernel Concurrency Sanitizer on: CPU: 0 UID: 0 PID: 56 Comm: kworker/u8:4 Not tainted 6.12.0-rc2-syzkaller-00050-g5b7c893ed5ed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: eventsunbound kfreercu_monitor <snip>

kfreercumonitor() rearms the work if a "krcp" has to be still offloaded and this is done without holding krcp->lock, whereas the kvfreecallrcu() holds it.

Fix it by acquiring the "krcp->lock" for kfreercumonitor() so both functions do not race anymore.(CVE-2024-53160)

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

ubifs: authentication: Fix use-after-free in ubifstncend_commit

After an insertion in TNC, the tree might split and cause a node to change its znode->parent. A further deletion of other nodes in the tree (which also could free the nodes), the aforementioned node's znode->cparent could still point to a freed node. This znode->cparent may not be updated when getting nodes to commit in ubifs_tnc_start_commit(). This could then trigger a use-after-free when accessing the znode->cparent in write_index() in ubifs_tnc_end_commit().

This can be triggered by running

rm -f /etc/test-file.bin dd if=/dev/urandom of=/etc/test-file.bin bs=1M count=60 conv=fsync

in a loop, and with CONFIG_UBIFS_FS_AUTHENTICATION. KASAN then reports:

BUG: KASAN: use-after-free in ubifstncendcommit+0xa5c/0x1950 Write of size 32 at addr ffffff800a3af86c by task ubifsbgt0_20/153

Call trace: dumpbacktrace+0x0/0x340 showstack+0x18/0x24 dumpstacklvl+0x9c/0xbc printaddressdescription.constprop.0+0x74/0x2b0 kasanreport+0x1d8/0x1f0 kasancheckrange+0xf8/0x1a0 memcpy+0x84/0xf4 ubifstncendcommit+0xa5c/0x1950 docommit+0x4e0/0x1340 ubifsbgthread+0x234/0x2e0 kthread+0x36c/0x410 retfrom_fork+0x10/0x20

Allocated by task 401: kasansavestack+0x38/0x70 _kasankmalloc+0x8c/0xd0 _kmalloc+0x34c/0x5bc tncinsert+0x140/0x16a4 ubifstncadd+0x370/0x52c ubifsjnlwritedata+0x5d8/0x870 dowritepage+0x36c/0x510 ubifswritepage+0x190/0x4dc _writepage+0x58/0x154 writecachepages+0x394/0x830 dowritepages+0x1f0/0x5b0 filemapfdatawritewbc+0x170/0x25c filewriteandwaitrange+0x140/0x190 ubifsfsync+0xe8/0x290 vfsfsyncrange+0xc0/0x1e4 dofsync+0x40/0x90 _arm64sysfsync+0x34/0x50 invokesyscall.constprop.0+0xa8/0x260 doel0svc+0xc8/0x1f0 el0svc+0x34/0x70 el0t64synchandler+0x108/0x114 el0t64_sync+0x1a4/0x1a8

Freed by task 403: kasansavestack+0x38/0x70 kasansettrack+0x28/0x40 kasansetfreeinfo+0x28/0x4c _kasanslabfree+0xd4/0x13c kfree+0xc4/0x3a0 tncdelete+0x3f4/0xe40 ubifstncremoverange+0x368/0x73c ubifstncremoveino+0x29c/0x2e0 ubifsjnldeleteinode+0x150/0x260 ubifsevictinode+0x1d4/0x2e4 evict+0x1c8/0x450 iput+0x2a0/0x3c4 dounlinkat+0x2cc/0x490 _arm64sysunlinkat+0x90/0x100 invokesyscall.constprop.0+0xa8/0x260 doel0svc+0xc8/0x1f0 el0svc+0x34/0x70 el0t64synchandler+0x108/0x114 el0t64_sync+0x1a4/0x1a8

The offending memcpy() in ubifs_copy_hash() has a use-after-free when a node becomes root in TNC but still has a cparent to an already freed node. More specifically, consider the following TNC:

     zroot
     /
    /
  zp1
  /
 /
zn

Inserting a new node zn_new with a key smaller then zn will trigger a split in tnc_insert() if zp1 is full:

     zroot
     /   \
    /     \
  zp1     zp2
  /         \
 /           \

zn_new zn

zn->parent has now been moved to zp2, but zn->cparent still points to zp1.

Now, consider a removal of all the nodes except zn. Just when tnc_delete() is about to delete zroot and zp2:

     zroot
         \
          \
          zp2
            \
             \
             zn

zroot and zp2 get freed and the tree collapses:

       zn

zn now becomes the new zroot.

get_znodes_to_commit() will now only find zn, the new zroot, and write_index() will check its znode->cparent that wrongly points to the already freed zp1. ubifs_copy_hash() thus gets wrongly called with znode->cparent->zbranch[znode->iip].hash that triggers the use-after-free!

Fix this by explicitly setting znode->cparent to NULL in get_znodes_to_commit() for the root node. The search for the dirty nodes ---truncated---(CVE-2024-53171)

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

ALSA: pcm: Add sanity NULL check for the default mmap fault handler

A driver might allow the mmap access before initializing its runtime->dmaarea properly. Add a proper NULL check before passing to virtto_page() for avoiding a panic.(CVE-2024-53180)

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

iouring: check for overflows in iopin_pages

WARNING: CPU: 0 PID: 5834 at iouring/memmap.c:144 iopinpages+0x149/0x180 iouring/memmap.c:144 CPU: 0 UID: 0 PID: 5834 Comm: syz-executor825 Not tainted 6.12.0-next-20241118-syzkaller #0 Call Trace: <TASK> _iouaddrmap+0xfb/0x2d0 iouring/memmap.c:183 ioringsmap iouring/iouring.c:2611 [inline] ioallocatescqurings+0x1c0/0x650 iouring/iouring.c:3470 iouringcreate+0x5b5/0xc00 iouring/iouring.c:3692 iouringsetup iouring/io_uring.c:3781 [inline] ... </TASK>

iopinpages()'s uaddr parameter came directly from the user and can be garbage. Don't just add size to it as it can overflow.(CVE-2024-53187)

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

wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failures

Syzkaller reported a hung task with uevent_show() on stack trace. That specific issue was addressed by another commit [0], but even with that fix applied (for example, running v6.12-rc5) we face another type of hung task that comes from the same reproducer [1]. By investigating that, we could narrow it to the following path:

(a) Syzkaller emulates a Realtek USB WiFi adapter using raw-gadget and dummy_hcd infrastructure.

(b) During the probe of rtl8192cu, the driver ends-up performing an efuse read procedure (which is related to EEPROM load IIUC), and here lies the issue: the function readefuse() calls readefuse_byte() many times, as loop iterations depending on the efuse size (in our example, 512 in total).

This procedure for reading efuse bytes relies in a loop that performs an I/O read up to 10k times in case of failures. We measured the time of the loop inside readefusebyte() alone, and in this reproducer (which involves the dummy_hcd emulation layer), it takes 15 seconds each. As a consequence, we have the driver stuck in its probe routine for big time, exposing a stack trace like below if we attempt to reboot the system, for example:

task:kworker/0:3 state:D stack:0 pid:662 tgid:662 ppid:2 flags:0x00004000 Workqueue: usbhubwq hubevent Call Trace: _schedule+0xe22/0xeb6 scheduletimeout+0xe7/0x132 _waitforcommon+0xb5/0x12e usbstartwaiturb+0xc5/0x1ef ? usballocurb+0x95/0xa4 usbcontrolmsg+0xff/0x184 _usbctrlvendorreqsync+0xa0/0x161 _usbreadsync+0xb3/0xc5 readefusebyte+0x13c/0x146 readefuse+0x351/0x5f0 efusereadallmap+0x42/0x52 rtlefuseshadowmapupdate+0x60/0xef rtlgethwinfo+0x5d/0x1c2 rtl92cureadeeprominfo+0x10a/0x8d5 ? rtl92creadchipversion+0x14f/0x17e rtlusbprobe+0x323/0x851 usbprobeinterface+0x278/0x34b reallyprobe+0x202/0x4a4 _driverprobedevice+0x166/0x1b2 driverprobe_device+0x2f/0xd8 [...]

We propose hereby to drastically reduce the attempts of doing the I/O reads in case of failures, restricted to USB devices (given that they're inherently slower than PCIe ones). By retrying up to 10 times (instead of 10000), we got reponsiveness in the reproducer, while seems reasonable to believe that there's no sane USB device implementation in the field requiring this amount of retries at every I/O read in order to properly work. Based on that assumption, it'd be good to have it backported to stable but maybe not since driver implementation (the 10k number comes from day 0), perhaps up to 6.x series makes sense.

[0] Commit 15fffc6a5624 ("driver core: Fix uevent_show() vs driver detach race")

[1] A note about that: this syzkaller report presents multiple reproducers that differs by the type of emulated USB device. For this specific case, check the entry from 2024/08/08 06:23 in the list of crashes; the C repro is available at https://syzkaller.appspot.com/text?tag=ReproC&x=1521fc83980000.(CVE-2024-53190)

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

wifi: ath12k: fix warning when unbinding

If there is an error during some initialization related to firmware, the buffers dp->txring[i].txstatus are released. However this is released again when the device is unbinded (ath12kpci), and we get: WARNING: CPU: 0 PID: 2098 at mm/slub.c:4689 freelargekmalloc+0x4d/0x80 Call Trace: freelargekmalloc ath12kdpfree ath12kcoredeinit ath12kpci_remove ...

The issue is always reproducible from a VM because the MSI addressing initialization is failing.

In order to fix the issue, just set the buffers to NULL after releasing in order to avoid the double free.(CVE-2024-53191)

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

PCI: Fix use-after-free of slot->bus on hot remove

Dennis reports a boot crash on recent Lenovo laptops with a USB4 dock.

Since commit 0fc70886569c ("thunderbolt: Reset USB4 v2 host router") and commit 59a54c5f3dbd ("thunderbolt: Reset topology created by the boot firmware"), USB4 v2 and v1 Host Routers are reset on probe of the thunderbolt driver.

The reset clears the Presence Detect State and Data Link Layer Link Active bits at the USB4 Host Router's Root Port and thus causes hot removal of the dock.

The crash occurs when pciehp is unbound from one of the dock's Downstream Ports: pciehp creates a pcislot on bind and destroys it on unbind. The pcislot contains a pointer to the pcibus below the Downstream Port, but a reference on that pcibus is never acquired. The pcibus is destroyed before the pcislot, so a use-after-free ensues when pcislotrelease() accesses slot->bus.

In principle this should not happen because pcistopbusdevice() unbinds pciehp (and therefore destroys the pcislot) before the pcibus is destroyed by pciremovebusdevice().

However the stacktrace provided by Dennis shows that pciehp is unbound from pciremovebusdevice() instead of pcistopbusdevice(). To understand the significance of this, one needs to know that the PCI core uses a two step process to remove a portion of the hierarchy: It first unbinds all drivers in the sub-hierarchy in pcistopbusdevice() and then actually removes the devices in pciremovebusdevice(). There is no precaution to prevent driver binding in-between pcistopbusdevice() and pciremovebusdevice().

In Dennis' case, it seems removal of the hierarchy by pciehp races with driver binding by pcibusadddevices(). pciehp is bound to the Downstream Port after pcistopbusdevice() has run, so it is unbound by pciremovebusdevice() instead of pcistopbusdevice(). Because the pci_bus has already been destroyed at that point, accesses to it result in a use-after-free.

One might conclude that driver binding needs to be prevented after pcistopbusdevice() has run. However it seems risky that pcislot points to pcibus without holding a reference. Solely relying on correct ordering of driver unbind versus pcibus destruction is certainly not defensive programming.

If pcislot has a need to access data in pcibus, it ought to acquire a reference. Amend pcicreateslot() accordingly. Dennis reports that the crash is not reproducible with this change.

Abridged stacktrace:

pcieport 0000:00:07.0: PME: Signaling with IRQ 156 pcieport 0000:00:07.0: pciehp: Slot #12 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+ pcibus 0000:20: dev 00, created physical slot 12 pcieport 0000:00:07.0: pciehp: Slot(12): Card not present ... pcieport 0000:21:02.0: pciehp: pciedisablenotification: SLOTCTRL d8 write cmd 0 Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI CPU: 13 UID: 0 PID: 134 Comm: irq/156-pciehp Not tainted 6.11.0-devel+ #1 RIP: 0010:devdriverstring+0x12/0x40 pcidestroyslot pciehpremove pcieportremoveservice devicereleasedriverinternal busremovedevice devicedel deviceunregister removeiter deviceforeachchild pcieportdrvremove pcideviceremove devicereleasedriverinternal busremovedevice devicedel pciremovebusdevice (recursive invocation) pciremovebusdevice pciehpunconfiguredevice pciehpdisableslot pciehphandlepresenceorlinkchange pciehpist(CVE-2024-53194)

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

KVM: arm64: Don't retire aborted MMIO instruction

Returning an abort to the guest for an unsupported MMIO access is a documented feature of the KVM UAPI. Nevertheless, it's clear that this plumbing has seen limited testing, since userspace can trivially cause a WARN in the MMIO return:

WARNING: CPU: 0 PID: 30558 at arch/arm64/include/asm/kvmemulate.h:536 kvmhandlemmioreturn+0x46c/0x5c4 arch/arm64/include/asm/kvmemulate.h:536 Call trace: kvmhandlemmioreturn+0x46c/0x5c4 arch/arm64/include/asm/kvmemulate.h:536 kvmarchvcpuioctlrun+0x98/0x15b4 arch/arm64/kvm/arm.c:1133 kvmvcpuioctl+0x75c/0xa78 virt/kvm/kvmmain.c:4487 _dosysioctl fs/ioctl.c:51 [inline] _sesysioctl fs/ioctl.c:893 [inline] _arm64sysioctl+0x14c/0x1c8 fs/ioctl.c:893 _invokesyscall arch/arm64/kernel/syscall.c:35 [inline] invokesyscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0svccommon+0x1e0/0x23c arch/arm64/kernel/syscall.c:132 doel0svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0svc+0x38/0x68 arch/arm64/kernel/entry-common.c:712 el0t64synchandler+0x90/0xfc arch/arm64/kernel/entry-common.c:730 el0t64sync+0x190/0x194 arch/arm64/kernel/entry.S:598

The splat is complaining that KVM is advancing PC while an exception is pending, i.e. that KVM is retiring the MMIO instruction despite a pending synchronous external abort. Womp womp.

Fix the glaring UAPI bug by skipping over all the MMIO emulation in case there is a pending synchronous exception. Note that while userspace is capable of pending an asynchronous exception (SError, IRQ, or FIQ), it is still safe to retire the MMIO instruction in this case as (1) they are by definition asynchronous, and (2) KVM relies on hardware support for pending/delivering these exceptions instead of the software state machine for advancing PC.(CVE-2024-53196)

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

usb: typec: fix potential array underflow in ucsiccgsync_control()

The "command" variable can be controlled by the user via debugfs. The worry is that if conindex is zero then "&uc->ucsi->connector[conindex - 1]" would be an array underflow.(CVE-2024-53203)

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

net: usb: lan78xx: Fix double free issue with interrupt buffer allocation

In lan78xx_probe(), the buffer buf was being freed twice: once implicitly through usb_free_urb(dev->urb_intr) with the URB_FREE_BUFFER flag and again explicitly by kfree(buf). This caused a double free issue.

To resolve this, reordered kmalloc() and usb_alloc_urb() calls to simplify the initialization sequence and removed the redundant kfree(buf). Now, buf is allocated after usb_alloc_urb(), ensuring it is correctly managed by usb_fill_int_urb() and freed by usb_free_urb() as intended.(CVE-2024-53213)

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

svcrdma: fix miss destroy percpucounter in svcrdmaprocinit()

There's issue as follows: RPC: Registered rdma transport module. RPC: Registered rdma backchannel transport module. RPC: Unregistered rdma transport module. RPC: Unregistered rdma backchannel transport module. BUG: unable to handle page fault for address: fffffbfff80c609a PGD 123fee067 P4D 123fee067 PUD 123fea067 PMD 10c624067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI RIP: 0010:percpucounterdestroymany+0xf7/0x2a0 Call Trace: <TASK> _die+0x1f/0x70 pagefaultoops+0x2cd/0x860 spuriouskernelfault+0x36/0x450 dokernaddrfault+0xca/0x100 excpagefault+0x128/0x150 asmexcpagefault+0x26/0x30 percpucounterdestroymany+0xf7/0x2a0 mmdrop+0x209/0x350 finishtaskswitch.isra.0+0x481/0x840 scheduletail+0xe/0xd0 retfromfork+0x23/0x80 retfromfork_asm+0x1a/0x30 </TASK>

If registersysctl() return NULL, then svcrdmaproccleanup() will not destroy the percpu counters which init in svcrdmaprocinit(). If CONFIGHOTPLUGCPU is enabled, residual nodes may be in the 'percpucounters' list. The above issue may occur once the module is removed. If the CONFIGHOTPLUGCPU configuration is not enabled, memory leakage occurs. To solve above issue just destroy all percpu counters when register_sysctl() return NULL.(CVE-2024-53215)

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

f2fs: fix race in concurrent f2fsstopgc_thread

In my test case, concurrent calls to f2fs shutdown report the following stack trace:

Oops: general protection fault, probably for non-canonical address 0xc6cfff63bb5513fc: 0000 [#1] PREEMPT SMP PTI CPU: 0 UID: 0 PID: 678 Comm: f2fsrepshutdo Not tainted 6.12.0-rc5-next-20241029-g6fb2fa9805c5-dirty #85 Call Trace: <TASK> ? showregs+0x8b/0xa0 ? _diebody+0x26/0xa0 ? dieaddr+0x54/0x90 ? excgeneralprotection+0x24b/0x5c0 ? asmexcgeneralprotection+0x26/0x30 ? kthreadstop+0x46/0x390 f2fsstopgcthread+0x6c/0x110 f2fsdoshutdown+0x309/0x3a0 f2fsiocshutdown+0x150/0x1c0 _f2fsioctl+0xffd/0x2ac0 f2fsioctl+0x76/0xe0 vfsioctl+0x23/0x60 _x64sysioctl+0xce/0xf0 x64syscall+0x2b1b/0x4540 dosyscall64+0xa7/0x240 entrySYSCALL64afterhwframe+0x76/0x7e

The root cause is a race condition in f2fsstopgc_thread() called from different f2fs shutdown paths:

[CPU0] [CPU1] ---------------------- ----------------------- f2fsstopgcthread f2fsstopgcthread gcth = sbi->gcthread gcth = sbi->gcthread kfree(gcth) sbi->gcthread = NULL < gcth != NULL > kthreadstop(gcth->f2fsgc_task) //UAF

The commit c7f114d864ac ("f2fs: fix to avoid use-after-free in f2fsstopgc_thread()") attempted to fix this issue by using a read semaphore to prevent races between shutdown and remount threads, but it fails to prevent all race conditions.

Fix it by converting to write lock of sumount in f2fsdo_shutdown().(CVE-2024-53218)

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

virtiofs: use pages instead of pointer for kernel direct IO

When trying to insert a 10MB kernel module kept in a virtio-fs with cache disabled, the following warning was reported:

------------[ cut here ]------------ WARNING: CPU: 1 PID: 404 at mm/pagealloc.c:4551 ...... Modules linked in: CPU: 1 PID: 404 Comm: insmod Not tainted 6.9.0-rc5+ #123 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...... RIP: 0010:allocpages+0x2bf/0x380 ...... Call Trace: <TASK> ? _warn+0x8e/0x150 ? _allocpages+0x2bf/0x380 _kmalloclargenode+0x86/0x160 _kmalloc+0x33c/0x480 virtiofsenqueuereq+0x240/0x6d0 virtiofswakependingandunlock+0x7f/0x190 queuerequestandunlock+0x55/0x60 fusesimplerequest+0x152/0x2b0 fusedirectio+0x5d2/0x8c0 fusefilereaditer+0x121/0x160 _kernelread+0x151/0x2d0 kernelread+0x45/0x50 kernelreadfile+0x1a9/0x2a0 initmodulefromfile+0x6a/0xe0 idempotentinitmodule+0x175/0x230 _x64sysfinitmodule+0x5d/0xb0 x64syscall+0x1c3/0x9e0 dosyscall64+0x3d/0xc0 entrySYSCALL64after_hwframe+0x4b/0x53 ...... </TASK> ---[ end trace 0000000000000000 ]---

The warning is triggered as follows:

1) syscall finitmodule() handles the module insertion and it invokes kernelread_file() to read the content of the module first.

2) kernelreadfile() allocates a 10MB buffer by using vmalloc() and passes it to kernelread(). kernelread() constructs a kvec iter by using ioviterkvec() and passes it to fusefileread_iter().

3) virtio-fs disables the cache, so fusefilereaditer() invokes fusedirectio(). As for now, the maximal read size for kvec iter is only limited by fc->maxread. For virtio-fs, maxread is UINTMAX, so fusedirectio() doesn't split the 10MB buffer. It saves the address and the size of the 10MB-sized buffer in outargs[0] of a fuse request and passes the fuse request to virtiofswakependingandunlock().

4) virtiofswakependingandunlock() uses virtiofsenqueuereq() to queue the request. Because virtiofs need DMA-able address, so virtiofsenqueuereq() uses kmalloc() to allocate a bounce buffer for all fuse args, copies these args into the bounce buffer and passed the physical address of the bounce buffer to virtiofsd. The total length of these fuse args for the passed fuse request is about 10MB, so copyargstoargbuf() invokes kmalloc() with a 10MB size parameter and it triggers the warning in _allocpages():

if (WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp))
    return NULL;

5) virtiofsenqueuereq() will retry the memory allocation in a kworker, but it won't help, because kmalloc() will always return NULL due to the abnormal size and finitmodule() will hang forever.

A feasible solution is to limit the value of maxread for virtio-fs, so the length passed to kmalloc() will be limited. However it will affect the maximal read size for normal read. And for virtio-fs write initiated from kernel, it has the similar problem but now there is no way to limit fc->maxwrite in kernel.

So instead of limiting both the values of maxread and maxwrite in kernel, introducing usepagesforkvecio in fuseconn and setting it as true in virtiofs. When usepagesforkvecio is enabled, fuse will use pages instead of pointer to pass the KVECIO data.

After switching to pages for KVECIO data, these pages will be used for DMA through virtio-fs. If these pages are backed by vmalloc(), {flush|invalidate}kernelvmaprange() are necessary to flush or invalidate the cache before the DMA operation. So add two new fields in fuseargspages to record the base address of vmalloc area and the condition indicating whether invalidation is needed. Perform the flush in fusegetuserpages() for write operations and the invalidation in fusereleaseuserpages() for read operations.

It may seem necessary to introduce another fie ---truncated---(CVE-2024-53219)

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

RDMA/mlx5: Move events notifier registration to be after device registration

Move pkey change work initialization and cleanup from device resources stage to notifier stage, since this is the stage which handles this work events.

Fix a race between the device deregistration and pkey change work by moving MLX5IBSTAGEDEVICENOTIFIER to be after MLX5IBSTAGEIBREG in order to ensure that the notifier is deregistered before the device during cleanup. Which ensures there are no works that are being executed after the device has already unregistered which can cause the panic below.

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

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

RDMA/rxe: Fix the qp flush warnings in req

When the qp is in error state, the status of WQEs in the queue should be set to error. Or else the following will appear.

[ 920.617269] WARNING: CPU: 1 PID: 21 at drivers/infiniband/sw/rxe/rxecomp.c:756 rxecompleter+0x989/0xcc0 [rdmarxe] [ 920.617744] Modules linked in: rnbdclient(O) rtrsclient(O) rtrscore(O) rdmaucm rdmacm iwcm ibcm crc32generic rdmarxe ip6udptunnel udptunnel ibuverbs ibcore loop brd nullblk ipv6 [ 920.618516] CPU: 1 PID: 21 Comm: ksoftirqd/1 Tainted: G O 6.1.113-storage+ #65 [ 920.618986] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 920.619396] RIP: 0010:rxecompleter+0x989/0xcc0 [rdmarxe] [ 920.619658] Code: 0f b6 84 24 3a 02 00 00 41 89 84 24 44 04 00 00 e9 2a f7 ff ff 39 ca bb 03 00 00 00 b8 0e 00 00 00 48 0f 45 d8 e9 15 f7 ff ff <0f> 0b e9 cb f8 ff ff 41 bf f5 ff ff ff e9 08 f8 ff ff 49 8d bc 24 [ 920.620482] RSP: 0018:ffff97b7c00bbc38 EFLAGS: 00010246 [ 920.620817] RAX: 0000000000000000 RBX: 000000000000000c RCX: 0000000000000008 [ 920.621183] RDX: ffff960dc396ebc0 RSI: 0000000000005400 RDI: ffff960dc4e2fbac [ 920.621548] RBP: 0000000000000000 R08: 0000000000000001 R09: ffffffffac406450 [ 920.621884] R10: ffffffffac4060c0 R11: 0000000000000001 R12: ffff960dc4e2f800 [ 920.622254] R13: ffff960dc4e2f928 R14: ffff97b7c029c580 R15: 0000000000000000 [ 920.622609] FS: 0000000000000000(0000) GS:ffff960ef7d00000(0000) knlGS:0000000000000000 [ 920.622979] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 920.623245] CR2: 00007fa056965e90 CR3: 00000001107f1000 CR4: 00000000000006e0 [ 920.623680] Call Trace: [ 920.623815] <TASK> [ 920.623933] ? _warn+0x79/0xc0 [ 920.624116] ? rxecompleter+0x989/0xcc0 [rdmarxe] [ 920.624356] ? reportbug+0xfb/0x150 [ 920.624594] ? handlebug+0x3c/0x60 [ 920.624796] ? excinvalidop+0x14/0x70 [ 920.624976] ? asmexcinvalidop+0x16/0x20 [ 920.625203] ? rxecompleter+0x989/0xcc0 [rdmarxe] [ 920.625474] ? rxecompleter+0x329/0xcc0 [rdmarxe] [ 920.625749] rxedotask+0x80/0x110 [rdmarxe] [ 920.626037] rxerequester+0x625/0xde0 [rdmarxe] [ 920.626310] ? rxecqpost+0xe2/0x180 [rdmarxe] [ 920.626583] ? docomplete+0x18d/0x220 [rdmarxe] [ 920.626812] ? rxecompleter+0x1a3/0xcc0 [rdmarxe] [ 920.627050] rxedotask+0x80/0x110 [rdmarxe] [ 920.627285] taskletactioncommon.constprop.0+0xa4/0x120 [ 920.627522] handlesoftirqs+0xc2/0x250 [ 920.627728] ? sortrange+0x20/0x20 [ 920.627942] runksoftirqd+0x1f/0x30 [ 920.628158] smpbootthreadfn+0xc7/0x1b0 [ 920.628334] kthread+0xd6/0x100 [ 920.628504] ? kthreadcompleteandexit+0x20/0x20 [ 920.628709] retfrom_fork+0x1f/0x30 [ 920.628892] </TASK>(CVE-2024-53229)

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

cpufreq: CPPC: Fix possible null-ptr-deref for cpufreqcpuget_raw()

cpufreqcpuget_raw() may return NULL if the cpu is not in policy->cpus cpu mask and it will cause null pointer dereference.(CVE-2024-53231)

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

erofs: handle NONHEAD !delta[1] lclusters gracefully

syzbot reported a WARNING in iomapiterdone: iomapfiemap+0x73b/0x9b0 fs/iomap/fiemap.c:80 ioctlfiemap fs/ioctl.c:220 [inline]

Generally, NONHEAD lclusters won't have delta[1]==0, except for crafted images and filesystems created by pre-1.0 mkfs versions.

Previously, it would immediately bail out if delta[1]==0, which led to inadequate decompressed lengths (thus FIEMAP is impacted). Treat it as delta[1]=1 to work around these legacy mkfs versions.

lclusterbits > 14 is illegal for compact indexes, error out too.(CVE-2024-53234)

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

ALSA: 6fire: Release resources at card release

The current 6fire code tries to release the resources right after the call of usb6firechipabort(). But at this moment, the card object might be still in use (as we're calling sndcardfreewhenclosed()).

For avoid potential UAFs, move the release of resources to the card's privatefree instead of the manual call of usb6firechip_destroy() at the USB disconnect callback.(CVE-2024-53239)

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

x86/xen: don't do PV iret hypercall through hypercall page

Instead of jumping to the Xen hypercall page for doing the iret hypercall, directly code the required sequence in xen-asm.S.

This is done in preparation of no longer using hypercall page at all, as it has shown to cause problems with speculation mitigations.

This is part of XSA-466 / CVE-2024-53241.(CVE-2024-53241)

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

net: renesas: rswitch: avoid use-after-put for a device tree node

The device tree node saved in the rswitchdevice structure is used at several driver locations. So passing this node to ofnode_put() after the first use is wrong.

Move ofnodeput() for this node to exit paths.(CVE-2024-55639)

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

wifi: ath12k: Skip Rx TID cleanup for self peer

During peer create, dp setup for the peer is done where Rx TID is updated for all the TIDs. Peer object for self peer will not go through dp setup.

When core halts, dp cleanup is done for all the peers. While cleanup, rx_tid::ab is accessed which causes below stack trace for self peer.

WARNING: CPU: 6 PID: 12297 at drivers/net/wireless/ath/ath12k/dprx.c:851 Call Trace: _warn+0x7b/0x1a0 ath12kdprxfragscleanup+0xd2/0xe0 [ath12k] reportbug+0x10b/0x200 handlebug+0x3f/0x70 excinvalidop+0x13/0x60 asmexcinvalidop+0x16/0x20 ath12kdprxfragscleanup+0xd2/0xe0 [ath12k] ath12kdprxfragscleanup+0xca/0xe0 [ath12k] ath12kdprxpeertidcleanup+0x39/0xa0 [ath12k] ath12kmacpeercleanupall+0x61/0x100 [ath12k] ath12kcorehalt+0x3b/0x100 [ath12k] ath12kcorereset+0x494/0x4c0 [ath12k]

sta object in peer will be updated when remote peer is created. Hence use peer::sta to detect the self peer and skip the cleanup.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPLSILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPLV1.0V2.0SILICONZ-3(CVE-2024-56543)

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

drivers: soc: xilinx: add the missing kfree in xlnxaddcbforsuspend()

If we fail to allocate memory for cbdata by kmalloc, the memory allocation for evedata is never freed, add the missing kfree() in the error handling path.(CVE-2024-56546)

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

cachefiles: Fix NULL pointer dereference in object->file

At present, the object->file has the NULL pointer dereference problem in ondemand-mode. The root cause is that the allocated fd and object->file lifetime are inconsistent, and the user-space invocation to anon_fd uses object->file. Following is the process that triggers the issue:

  [write fd]                [umount]

cachefilesondemandfdwriteiter fscachecookiestatemachine cachefileswithdrawcookie if (!file) return -ENOBUFS cachefilescleanupobject cachefilesunmarkinodeinuse fput(object->file) object->file = NULL // file NULL pointer dereference! _cachefileswrite(..., file, ...)

Fix this issue by add an additional reference count to the object->file before write/llseek, and decrement after it finished.(CVE-2024-56549)

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

i3c: master: Fix miss free initdynaddr at i3cmasterputi3caddrs()

if (dev->boardinfo && dev->boardinfo->initdynaddr) ^^^ here check "initdynaddr" i3cbussetaddrslotstatus(&master->bus, dev->info.dynaddr, ...) ^^^^ free "dynaddr" Fix copy/paste error "dynaddr" by replacing it with "initdynaddr".(CVE-2024-56562)

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

ovl: Filter invalid inodes with missing lookup function

Add a check to the ovldentryweird() function to prevent the processing of directory inodes that lack the lookup function. This is important because such inodes can cause errors in overlayfs when passed to the lowerstack.(CVE-2024-56570)

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

media: platform: allegro-dvt: Fix possible memory leak in allocatebuffersinternal()

The buffer in the loop should be released under the exception path, otherwise there may be a memory leak here.

To mitigate this, free the buffer when allegroallocbuffer fails.(CVE-2024-56572)

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

btrfs: fix use-after-free in btrfsencodedread_endio()

Shinichiro reported the following use-after free that sometimes is happening in our CI system when running fstests' btrfs/284 on a TCMU runner device:

BUG: KASAN: slab-use-after-free in lock_release+0x708/0x780 Read of size 8 at addr ffff888106a83f18 by task kworker/u80:6/219

CPU: 8 UID: 0 PID: 219 Comm: kworker/u80:6 Not tainted 6.12.0-rc6-kts+ #15 Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020 Workqueue: btrfs-endio btrfsendbiowork [btrfs] Call Trace: <TASK> dumpstacklvl+0x6e/0xa0 ? lockrelease+0x708/0x780 printreport+0x174/0x505 ? lockrelease+0x708/0x780 ? _virtaddrvalid+0x224/0x410 ? lockrelease+0x708/0x780 kasanreport+0xda/0x1b0 ? lockrelease+0x708/0x780 ? _wakeup+0x44/0x60 lockrelease+0x708/0x780 ? _pfxlockrelease+0x10/0x10 ? _pfxdorawspinlock+0x10/0x10 ? lockisheldtype+0x9a/0x110 rawspinunlockirqrestore+0x1f/0x60 _wakeup+0x44/0x60 btrfsencodedreadendio+0x14b/0x190 [btrfs] btrfscheckreadbio+0x8d9/0x1360 [btrfs] ? lockrelease+0x1b0/0x780 ? tracelockacquire+0x12f/0x1a0 ? _pfxbtrfscheckreadbio+0x10/0x10 [btrfs] ? processonework+0x7e3/0x1460 ? lockacquire+0x31/0xc0 ? processonework+0x7e3/0x1460 processonework+0x85c/0x1460 ? _pfxprocessonework+0x10/0x10 ? assignwork+0x16c/0x240 workerthread+0x5e6/0xfc0 ? _pfxworkerthread+0x10/0x10 kthread+0x2c3/0x3a0 ? _pfxkthread+0x10/0x10 retfromfork+0x31/0x70 ? _pfxkthread+0x10/0x10 retfromfork_asm+0x1a/0x30 </TASK>

Allocated by task 3661: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 _kasankmalloc+0xaa/0xb0 btrfsencodedreadregularfillpages+0x16c/0x6d0 [btrfs] sendextentdata+0xf0f/0x24a0 [btrfs] processextent+0x48a/0x1830 [btrfs] changedcb+0x178b/0x2ea0 [btrfs] btrfsioctlsend+0x3bf9/0x5c20 [btrfs] _btrfsioctlsend+0x117/0x330 [btrfs] btrfsioctl+0x184a/0x60a0 [btrfs] _x64sysioctl+0x12e/0x1a0 dosyscall64+0x95/0x180 entrySYSCALL64after_hwframe+0x76/0x7e

Freed by task 3661: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3b/0x70 _kasanslabfree+0x4f/0x70 kfree+0x143/0x490 btrfsencodedreadregularfillpages+0x531/0x6d0 [btrfs] sendextentdata+0xf0f/0x24a0 [btrfs] processextent+0x48a/0x1830 [btrfs] changedcb+0x178b/0x2ea0 [btrfs] btrfsioctlsend+0x3bf9/0x5c20 [btrfs] _btrfsioctlsend+0x117/0x330 [btrfs] btrfsioctl+0x184a/0x60a0 [btrfs] _x64sysioctl+0x12e/0x1a0 dosyscall64+0x95/0x180 entrySYSCALL64after_hwframe+0x76/0x7e

The buggy address belongs to the object at ffff888106a83f00 which belongs to the cache kmalloc-rnd-07-96 of size 96 The buggy address is located 24 bytes inside of freed 96-byte region [ffff888106a83f00, ffff888106a83f60)

The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888106a83800 pfn:0x106a83 flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff) page_type: f5(slab) raw: 0017ffffc0000000 ffff888100053680 ffffea0004917200 0000000000000004 raw: ffff888106a83800 0000000080200019 00000001f5000000 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffff888106a83e00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ffff888106a83e80: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc >ffff888106a83f00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888106a83f80: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ffff888106a84000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ==================================================================

Further analyzing the trace and ---truncated---(CVE-2024-56582)

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

sched/deadline: Fix warning in migrate_enable for boosted tasks

When running the following command:

while true; do stress-ng --cyclic 30 --timeout 30s --minimize --quiet done

a warning is eventually triggered:

WARNING: CPU: 43 PID: 2848 at kernel/sched/deadline.c:794 setupnewdlentity+0x13e/0x180 ... Call Trace: <TASK> ? showtraceloglvl+0x1c4/0x2df ? enqueuedlentity+0x631/0x6e0 ? setupnewdlentity+0x13e/0x180 ? _warn+0x7e/0xd0 ? reportbug+0x11a/0x1a0 ? handlebug+0x3c/0x70 ? excinvalidop+0x14/0x70 ? asmexcinvalidop+0x16/0x20 enqueuedlentity+0x631/0x6e0 enqueuetaskdl+0x7d/0x120 _dosetcpusallowed+0xe3/0x280 _setcpusallowedptrlocked+0x140/0x1d0 _setcpusallowedptr+0x54/0xa0 migrateenable+0x7e/0x150 rtspinunlock+0x1c/0x90 groupsendsiginfo+0xf7/0x1a0 ? killpidinfo+0x1f/0x1d0 killpidinfo+0x78/0x1d0 killprocinfo+0x5b/0x110 _x64syskill+0x93/0xc0 dosyscall64+0x5c/0xf0 entrySYSCALL64after_hwframe+0x6e/0x76 RIP: 0033:0x7f0dab31f92b

This warning occurs because setcpusallowed dequeues and enqueues tasks with the ENQUEUERESTORE flag set. If the task is boosted, the warning is triggered. A boosted task already had its parameters set by rtmutexsetprio, and a new call to setupnewdlentity is unnecessary, hence the WARN_ON call.

Check if we are requeueing a boosted task and avoid calling setupnewdl_entity if that's the case.(CVE-2024-56583)

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

LoongArch: Fix sleeping in atomic context for PREEMPT_RT

Commit bab1c299f3945ffe79 ("LoongArch: Fix sleeping in atomic context in setuptlbhandler()") changes the gfp flag from GFPKERNEL to GFPATOMIC for allocpagesnode(). However, for PREEMPT_RT kernels we can still get a "sleeping in atomic context" error:

[ 0.372259] BUG: sleeping function called from invalid context at kernel/locking/spinlockrt.c:48 [ 0.372266] inatomic(): 1, irqsdisabled(): 1, nonblock: 0, pid: 0, name: swapper/1 [ 0.372268] preemptcount: 1, expected: 0 [ 0.372270] RCU nest depth: 1, expected: 1 [ 0.372272] 3 locks held by swapper/1/0: [ 0.372274] #0: 900000000c9f5e60 (&pcp->lock){+.+.}-{3:3}, at: getpagefromfreelist+0x524/0x1c60 [ 0.372294] #1: 90000000087013b8 (rcureadlock){....}-{1:3}, at: rtspintrylock+0x50/0x140 [ 0.372305] #2: 900000047fffd388 (&zone->lock){+.+.}-{3:3}, at: _rmqueuepcplist+0x30c/0xea0 [ 0.372314] irq event stamp: 0 [ 0.372316] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [ 0.372322] hardirqs last disabled at (0): [<9000000005947320>] copyprocess+0x9c0/0x26e0 [ 0.372329] softirqs last enabled at (0): [<9000000005947320>] copyprocess+0x9c0/0x26e0 [ 0.372335] softirqs last disabled at (0): [<0000000000000000>] 0x0 [ 0.372341] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.12.0-rc7+ #1891 [ 0.372346] Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022 [ 0.372349] Stack : 0000000000000089 9000000005a0db9c 90000000071519c8 9000000100388000 [ 0.372486] 900000010038b890 0000000000000000 900000010038b898 9000000007e53788 [ 0.372492] 900000000815bcc8 900000000815bcc0 900000010038b700 0000000000000001 [ 0.372498] 0000000000000001 4b031894b9d6b725 00000000055ec000 9000000100338fc0 [ 0.372503] 00000000000000c4 0000000000000001 000000000000002d 0000000000000003 [ 0.372509] 0000000000000030 0000000000000003 00000000055ec000 0000000000000003 [ 0.372515] 900000000806d000 9000000007e53788 00000000000000b0 0000000000000004 [ 0.372521] 0000000000000000 0000000000000000 900000000c9f5f10 0000000000000000 [ 0.372526] 90000000076f12d8 9000000007e53788 9000000005924778 0000000000000000 [ 0.372532] 00000000000000b0 0000000000000004 0000000000000000 0000000000070000 [ 0.372537] ... [ 0.372540] Call Trace: [ 0.372542] [<9000000005924778>] showstack+0x38/0x180 [ 0.372548] [<90000000071519c4>] dumpstacklvl+0x94/0xe4 [ 0.372555] [<900000000599b880>] _mightresched+0x1a0/0x260 [ 0.372561] [<90000000071675cc>] rtspinlock+0x4c/0x140 [ 0.372565] [<9000000005cbb768>] _rmqueuepcplist+0x308/0xea0 [ 0.372570] [<9000000005cbed84>] getpagefromfreelist+0x564/0x1c60 [ 0.372575] [<9000000005cc0d98>] _allocpagesnoprof+0x218/0x1820 [ 0.372580] [<900000000593b36c>] tlbinit+0x1ac/0x298 [ 0.372585] [<9000000005924b74>] percputrapinit+0x114/0x140 [ 0.372589] [<9000000005921964>] cpuprobe+0x4e4/0xa60 [ 0.372592] [<9000000005934874>] startsecondary+0x34/0xc0 [ 0.372599] [<900000000715615c>] smpbootentry+0x64/0x6c

This is because in PREEMPTRT kernels normal spinlocks are replaced by rt spinlocks and rtspinlock() will cause sleeping. Fix it by disabling NUMA optimization completely for PREEMPTRT kernels.(CVE-2024-56585)

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

f2fs: fix f2fsbugon when uninstalling filesystem call f2fsevictinode.

creating a large files during checkpoint disable until it runs out of space and then delete it, then remount to enable checkpoint again, and then unmount the filesystem triggers the f2fsbugon as below:

------------[ cut here ]------------ kernel BUG at fs/f2fs/inode.c:896! CPU: 2 UID: 0 PID: 1286 Comm: umount Not tainted 6.11.0-rc7-dirty #360 Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:f2fsevictinode+0x58c/0x610 Call Trace: _diebody+0x15/0x60 die+0x33/0x50 dotrap+0x10a/0x120 f2fsevictinode+0x58c/0x610 doerrortrap+0x60/0x80 f2fsevictinode+0x58c/0x610 excinvalidop+0x53/0x60 f2fsevictinode+0x58c/0x610 asmexcinvalidop+0x16/0x20 f2fsevictinode+0x58c/0x610 evict+0x101/0x260 disposelist+0x30/0x50 evictinodes+0x140/0x190 genericshutdownsuper+0x2f/0x150 killblocksuper+0x11/0x40 killf2fssuper+0x7d/0x140 deactivatelockedsuper+0x2a/0x70 cleanupmnt+0xb3/0x140 taskwork_run+0x61/0x90

The root cause is: creating large files during disable checkpoint period results in not enough free segments, so when writing back root inode will failed in f2fsenablecheckpoint. When umount the file system after enabling checkpoint, the root inode is dirty in f2fsevictinode function, which triggers BUG_ON. The steps to reproduce are as follows:

dd if=/dev/zero of=f2fs.img bs=1M count=55 mount f2fs.img f2fsdir -o checkpoint=disable:10% dd if=/dev/zero of=big bs=1M count=50 sync rm big mount -o remount,checkpoint=enable f2fsdir umount f2fs_dir

Let's redirty inode when there is not free segments during checkpoint is disable.(CVE-2024-56586)

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

bpf: Call freehtabelem() after htabunlockbucket()

For htab of maps, when the map is removed from the htab, it may hold the last reference of the map. bpfmapfdputptr() will invoke bpfmapfreeid() to free the id of the removed map element. However, bpfmapfdputptr() is invoked while holding a bucket lock (rawspinlockt), and bpfmapfreeid() attempts to acquire mapidrlock (spinlockt), triggering the following lockdep warning:

============================= [ BUG: Invalid wait context ] 6.11.0-rc4+ #49 Not tainted

testmaps/4881 is trying to lock: ffffffff84884578 (mapidrlock){+...}-{3:3}, at: bpfmapfreeid.part.0+0x21/0x70 other info that might help us debug this: context-{5:5} 2 locks held by testmaps/4881: #0: ffffffff846caf60 (rcureadlock){....}-{1:3}, at: bpffdhtabmapupdateelem+0xf9/0x270 #1: ffff888149ced148 (&htab->lockdepkey#2){....}-{2:2}, at: htabmapupdateelem+0x178/0xa80 stack backtrace: CPU: 0 UID: 0 PID: 4881 Comm: testmaps Not tainted 6.11.0-rc4+ #49 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), ... Call Trace: <TASK> dumpstacklvl+0x6e/0xb0 dumpstack+0x10/0x20 _lockacquire+0x73e/0x36c0 lockacquire+0x182/0x450 _rawspinlockirqsave+0x43/0x70 bpfmapfreeid.part.0+0x21/0x70 bpfmapput+0xcf/0x110 bpfmapfdputptr+0x9a/0xb0 freehtabelem+0x69/0xe0 htabmapupdateelem+0x50f/0xa80 bpffdhtabmapupdateelem+0x131/0x270 htabmapupdateelem+0x50f/0xa80 bpffdhtabmapupdateelem+0x131/0x270 bpfmapupdatevalue+0x266/0x380 _sysbpf+0x21bb/0x36b0 _x64sysbpf+0x45/0x60 x64syscall+0x1b2a/0x20d0 dosyscall64+0x5d/0x100 entrySYSCALL64after_hwframe+0x76/0x7e

One way to fix the lockdep warning is using rawspinlockt for mapidrlock as well. However, bpfmapallocid() invokes idralloccyclic() after acquiring mapidrlock, it will trigger a similar lockdep warning because the slab's lock (s->cpuslab->lock) is still a spinlock.

Instead of changing mapidrlock's type, fix the issue by invoking htabputfdvalue() after htabunlockbucket(). However, only deferring the invocation of htabputfdvalue() is not enough, because the old map pointers in htab of maps can not be saved during batched deletion. Therefore, also defer the invocation of freehtabelem(), so these to-be-freed elements could be linked together similar to lru map.

There are four callers for ->mapfdput_ptr:

(1) allochtabelem() (through htabputfdvalue()) It invokes ->mapfdputptr() under a rawspinlockt. The invocation of htabputfdvalue() can not simply move after htabunlockbucket(), because the old element has already been stashed in htab->extraelems. It may be reused immediately after htabunlockbucket() and the invocation of htabputfdvalue() after htabunlockbucket() may release the newly-added element incorrectly. Therefore, saving the map pointer of the old element for htab of maps before unlocking the bucket and releasing the mapptr after unlock. Beside the map pointer in the old element, should do the same thing for the special fields in the old element as well.

(2) freehtabelem() (through htabputfdvalue()) Its caller includes _htabmaplookupanddeleteelem(), htabmapdeleteelem() and _htabmaplookupanddeletebatch().

For htabmapdeleteelem(), simply invoke freehtabelem() after htabunlockbucket(). For _htabmaplookupanddeletebatch(), just like lru map, linking the to-be-freed element into nodetofree list and invoking freehtabelem() for these element after unlock. It is safe to reuse batchflink as the link for nodetofree, because these elements have been removed from the hash llist.

Because htab of maps doesn't support lookupanddelete operation, _htabmaplookupanddeleteelem() doesn't have the problem, so kept it as ---truncated---(CVE-2024-56592)

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

drm/amdgpu: set the right AMDGPU sg segment limitation

The driver needs to set the correct maxsegmentsize; otherwise debugdmamap_sg() will complain about the over-mapping of the AMDGPU sg length as following:

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

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

jfs: add a check to prevent array-index-out-of-bounds in dbAdjTree

When the value of lp is 0 at the beginning of the for loop, it will become negative in the next assignment and we should bail out.(CVE-2024-56595)

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

jfs: fix array-index-out-of-bounds in jfs_readdir

The stbl might contain some invalid values. Added a check to return error code in that case.(CVE-2024-56596)

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

jfs: fix shift-out-of-bounds in dbSplit

When dmt_budmin is less than zero, it causes errors in the later stages. Added a check to return an error beforehand in dbAllocCtl itself.(CVE-2024-56597)

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

Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2capsockcreate()

btsockalloc() allocates the sk object and attaches it to the provided sock object. On error l2capsockalloc() frees the sk object, but the dangling pointer is still attached to the sock object, which may create use-after-free in other code.(CVE-2024-56605)

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

wifi: rtw88: use ieee80211purgetx_queue() to purge TX skb

When removing kernel modules by: rmmod rtw888723cs rtw888703b rtw888723x rtw88sdio rtw88_core

Driver uses skbqueuepurge() to purge TX skb, but not report tx status causing "Have pending ack frames!" warning. Use ieee80211purgetx_queue() to correct this.

Since ieee80211purgetx_queue() doesn't take locks, to prevent racing between TX work and purge TX queue, flush and destroy TX work in advance.

wlan0: deauthenticating from aa:f5:fd:60:4c:a8 by local choice (Reason: 3=DEAUTHLEAVING) ------------[ cut here ]------------ Have pending ack frames! WARNING: CPU: 3 PID: 9232 at net/mac80211/main.c:1691 ieee80211freeackframe+0x5c/0x90 [mac80211] CPU: 3 PID: 9232 Comm: rmmod Tainted: G C 6.10.1-200.fc40.aarch64 #1 Hardware name: pine64 Pine64 PinePhone Braveheart (1.1)/Pine64 PinePhone Braveheart (1.1), BIOS 2024.01 01/01/2024 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ieee80211freeackframe+0x5c/0x90 [mac80211] lr : ieee80211freeackframe+0x5c/0x90 [mac80211] sp : ffff80008c1b37b0 x29: ffff80008c1b37b0 x28: ffff000003be8000 x27: 0000000000000000 x26: 0000000000000000 x25: ffff000003dc14b8 x24: ffff80008c1b37d0 x23: ffff000000ff9f80 x22: 0000000000000000 x21: 000000007fffffff x20: ffff80007c7e93d8 x19: ffff00006e66f400 x18: 0000000000000000 x17: ffff7ffffd2b3000 x16: ffff800083fc0000 x15: 0000000000000000 x14: 0000000000000000 x13: 2173656d61726620 x12: 6b636120676e6964 x11: 0000000000000000 x10: 000000000000005d x9 : ffff8000802af2b0 x8 : ffff80008c1b3430 x7 : 0000000000000001 x6 : 0000000000000001 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000003be8000 Call trace: ieee80211freeackframe+0x5c/0x90 [mac80211] idrforeach+0x74/0x110 ieee80211freehw+0x44/0xe8 [mac80211] rtwsdioremove+0x9c/0xc0 [rtw88sdio] sdiobusremove+0x44/0x180 deviceremove+0x54/0x90 devicereleasedriverinternal+0x1d4/0x238 driverdetach+0x54/0xc0 busremovedriver+0x78/0x108 driverunregister+0x38/0x78 sdiounregisterdriver+0x2c/0x40 rtw8723csdriverexit+0x18/0x1000 [rtw888723cs] _dosysdeletemodule.isra.0+0x190/0x338 _arm64sysdeletemodule+0x1c/0x30 invokesyscall+0x74/0x100 el0svccommon.constprop.0+0x48/0xf0 doel0svc+0x24/0x38 el0svc+0x3c/0x158 el0t64synchandler+0x120/0x138 el0t64_sync+0x194/0x198 ---[ end trace 0000000000000000 ]---(CVE-2024-56609)

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

sched/numa: fix memory leak due to the overwritten vma->numab_state

[Problem Description] When running the hackbench program of LTP, the following memory leak is reported by kmemleak.

# /opt/ltp/testcases/bin/hackbench 20 thread 1000 Running with 20*40 (== 800) tasks.

# dmesg | grep kmemleak ... kmemleak: 480 new suspected memory leaks (see /sys/kernel/debug/kmemleak) kmemleak: 665 new suspected memory leaks (see /sys/kernel/debug/kmemleak)

# cat /sys/kernel/debug/kmemleak unreferenced object 0xffff888cd8ca2c40 (size 64): comm "hackbench", pid 17142, jiffies 4299780315 hex dump (first 32 bytes): ac 74 49 00 01 00 00 00 4c 84 49 00 01 00 00 00 .tI.....L.I..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc bff18fd4): [<ffffffff81419a89>] _kmalloccachenoprof+0x2f9/0x3f0 [<ffffffff8113f715>] tasknumawork+0x725/0xa00 [<ffffffff8110f878>] taskworkrun+0x58/0x90 [<ffffffff81ddd9f8>] syscallexittousermode+0x1c8/0x1e0 [<ffffffff81dd78d5>] dosyscall64+0x85/0x150 [<ffffffff81e0012b>] entrySYSCALL64after_hwframe+0x76/0x7e ...

This issue can be consistently reproduced on three different servers: * a 448-core server * a 256-core server * a 192-core server

[Root Cause] Since multiple threads are created by the hackbench program (along with the command argument 'thread'), a shared vma might be accessed by two or more cores simultaneously. When two or more cores observe that vma->numabstate is NULL at the same time, vma->numabstate will be overwritten.

Although current code ensures that only one thread scans the VMAs in a single 'numascanperiod', there might be a chance for another thread to enter in the next 'numascanperiod' while we have not gotten till numab_state allocation [1].

Note that the command /opt/ltp/testcases/bin/hackbench 50 process 1000 cannot the reproduce the issue. It is verified with 200+ test runs.

[Solution] Use the cmpxchg atomic operation to ensure that only one thread executes the vma->numab_state assignment.

[1] https://lore.kernel.org/lkml/1794be3c-358c-4cdc-a43d-a1f841d91ef7@amd.com/(CVE-2024-56613)

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

nilfs2: fix potential out-of-bounds memory access in nilfsfindentry()

Syzbot reported that when searching for records in a directory where the inode's i_size is corrupted and has a large value, memory access outside the folio/page range may occur, or a use-after-free bug may be detected if KASAN is enabled.

This is because nilfslastbyte(), which is called by nilfsfindentry() and others to calculate the number of valid bytes of directory data in a page from isize and the page index, loses the upper 32 bits of the 64-bit size information due to an inappropriate type of local variable to which the isize value is assigned.

This caused a large byte offset value due to underflow in the end address calculation in the calling nilfsfindentry(), resulting in memory access that exceeds the folio/page size.

Fix this issue by changing the type of the local variable causing the bit loss from "unsigned int" to "u64". The return value of nilfslastbyte() is also of type "unsigned int", but it is truncated so as not to exceed PAGE_SIZE and no bit loss occurs, so no change is required.(CVE-2024-56619)

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

scsi: ufs: core: sysfs: Prevent div by zero

Prevent a division by 0 when monitoring is not enabled.(CVE-2024-56622)

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

ksmbd: fix Out-of-Bounds Write in ksmbdvfsstream_write

An offset from client could be a negative value, It could allows to write data outside the bounds of the allocated buffer. Note that this issue is coming when setting 'vfs objects = streams_xattr parameter' in ksmbd.conf..(CVE-2024-56626)

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

scsi: sg: Fix slab-use-after-free read in sg_release()

Fix a use-after-free bug in sg_release(), detected by syzbot with KASAN:

BUG: KASAN: slab-use-after-free in lockrelease+0x151/0xa30 kernel/locking/lockdep.c:5838 _mutexunlockslowpath+0xe2/0x750 kernel/locking/mutex.c:912 sg_release+0x1f4/0x2e0 drivers/scsi/sg.c:407

In sgrelease(), the function krefput(&sfp->fref, sgremovesfp) is called before releasing the openrellock mutex. The krefput() call may decrement the reference count of sfp to zero, triggering its cleanup through sgremovesfp(). This cleanup includes scheduling deferred work via sgremovesfp_usercontext(), which ultimately frees sfp.

After krefput(), sgrelease() continues to unlock openrellock and may reference sfp or sdp. If sfp has already been freed, this results in a slab-use-after-free error.

Move the krefput(&sfp->fref, sgremovesfp) call after unlocking the openrellock mutex. This ensures:

• No references to sfp or sdp occur after the reference count is decremented.

• Cleanup functions such as sgremovesfp() and sgremovesfpusercontext() can safely execute without impacting the mutex handling in sgrelease().

The fix has been tested and validated by syzbot. This patch closes the bug reported at the following syzkaller link and ensures proper sequencing of resource cleanup and mutex operations, eliminating the risk of use-after-free errors in sg_release().(CVE-2024-56631)

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

tcpbpf: Fix the skmemuncharge logic in tcpbpf_sendmsg

The current sk memory accounting logic in _SKREDIRECT is pre-uncharging tosend bytes, which is either msg->sg.size or a smaller value apply_bytes.

Potential problems with this strategy are as follows:

• If the actual sent bytes are smaller than tosend, we need to charge some bytes back, as in line 487, which is okay but seems not clean.

• When tosend is set to applybytes, as in line 417, and (ret < 0), we may miss uncharging (msg->sg.size - applybytes) bytes.

[...] 415 tosend = msg->sg.size; 416 if (psock->applybytes && psock->applybytes < tosend) 417 tosend = psock->applybytes; [...] 443 skmsgreturn(sk, msg, tosend); 444 releasesock(sk); 446 origsize = msg->sg.size; 447 ret = tcpbpfsendmsgredir(skredir, rediringress, 448 msg, tosend, flags); 449 sent = origsize - msg->sg.size; [...] 454 locksock(sk); 455 if (unlikely(ret < 0)) { 456 int free = skmsgfreenocharge(sk, msg); 458 if (!cork) 459 *copied -= free; 460 } [...] 487 if (eval == _SKREDIRECT) 488 skmem_charge(sk, tosend - sent); [...]

When running the selftest testtxmsgredirwaitsndmem with txmsg_apply, the following warning will be reported:

------------[ cut here ]------------ WARNING: CPU: 6 PID: 57 at net/ipv4/afinet.c:156 inetsockdestruct+0x190/0x1a0 Modules linked in: CPU: 6 UID: 0 PID: 57 Comm: kworker/6:0 Not tainted 6.12.0-rc1.bm.1-amd64+ #43 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Workqueue: events skpsockdestroy RIP: 0010:inetsockdestruct+0x190/0x1a0 RSP: 0018:ffffad0a8021fe08 EFLAGS: 00010206 RAX: 0000000000000011 RBX: ffff9aab4475b900 RCX: ffff9aab481a0800 RDX: 0000000000000303 RSI: 0000000000000011 RDI: ffff9aab4475b900 RBP: ffff9aab4475b990 R08: 0000000000000000 R09: ffff9aab40050ec0 R10: 0000000000000000 R11: ffff9aae6fdb1d01 R12: ffff9aab49c60400 R13: ffff9aab49c60598 R14: ffff9aab49c60598 R15: dead000000000100 FS: 0000000000000000(0000) GS:ffff9aae6fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffec7e47bd8 CR3: 00000001a1a1c004 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? _warn+0x89/0x130 ? inetsockdestruct+0x190/0x1a0 ? reportbug+0xfc/0x1e0 ? handlebug+0x5c/0xa0 ? excinvalidop+0x17/0x70 ? asmexcinvalidop+0x1a/0x20 ? inetsockdestruct+0x190/0x1a0 _skdestruct+0x25/0x220 skpsockdestroy+0x2b2/0x310 processscheduledworks+0xa3/0x3e0 workerthread+0x117/0x240 ? _pfxworkerthread+0x10/0x10 kthread+0xcf/0x100 ? _pfxkthread+0x10/0x10 retfromfork+0x31/0x40 ? _pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK> ---[ end trace 0000000000000000 ]---

In _SKREDIRECT, a more concise way is delaying the uncharging after sent bytes are finalized, and uncharge this value. When (ret < 0), we shall invoke skmsgfree.

Same thing happens in case _SKDROP, when tosend is set to applybytes, we may miss uncharging (msg->sg.size - applybytes) bytes. The same warning will be reported in selftest.

[...] 468 case _SKDROP: 469 default: 470 skmsgfreepartial(sk, msg, tosend); 471 skmsgapplybytes(psock, tosend); 472 *copied -= (tosend + delta); 473 return -EACCES; [...]

So instead of skmsgfreepartial we can do skmsg_free here.(CVE-2024-56633)

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

netfilter: nft_inner: incorrect percpu area handling under softirq

Softirq can interrupt ongoing packet from process context that is walking over the percpu area that contains inner header offsets.

Disable bh and perform three checks before restoring the percpu inner header offsets to validate that the percpu area is valid for this skbuff:

1) If the NFTPKTINFOINNER_FULL flag is set on, then this skbuff has already been parsed before for inner header fetching to register.

2) Validate that the percpu area refers to this skbuff using the skbuff pointer as a cookie. If there is a cookie mismatch, then this skbuff needs to be parsed again.

3) Finally, validate if the percpu area refers to this tunnel type.

Only after these three checks the percpu area is restored to a on-stack copy and bh is enabled again.

After inner header fetching, the on-stack copy is stored back to the percpu area.(CVE-2024-56638)

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

net: enetc: Do not configure preemptible TCs if SIs do not support

Both ENETC PF and VF drivers share enetcsetuptcmqprio() to configure MQPRIO. And enetcsetuptcmqprio() calls enetcchangepreemptible_tcs() to configure preemptible TCs. However, only PF is able to configure preemptible TCs. Because only PF has related registers, while VF does not have these registers. So for VF, its hw->port pointer is NULL. Therefore, VF will access an invalid pointer when accessing a non-existent register, which will cause a crash issue. The simplified log is as follows.

root@ls1028ardb:~# tc qdisc add dev eno0vf0 parent root handle 100: \ mqprio numtc 4 map 0 0 1 1 2 2 3 3 queues 1@0 1@1 1@2 1@3 hw 1 [ 187.290775] Unable to handle kernel paging request at virtual address 0000000000001f00 [ 187.424831] pc : enetcmmcommitpreemptibletcs+0x1c4/0x400 [ 187.430518] lr : enetcmmcommitpreemptibletcs+0x30c/0x400 [ 187.511140] Call trace: [ 187.513588] enetcmmcommitpreemptibletcs+0x1c4/0x400 [ 187.518918] enetcsetuptcmqprio+0x180/0x214 [ 187.523374] enetcvfsetuptc+0x1c/0x30 [ 187.527306] mqprioenableoffload+0x144/0x178 [ 187.531766] mqprioinit+0x3ec/0x668 [ 187.535351] qdisccreate+0x15c/0x488 [ 187.539023] tcmodifyqdisc+0x398/0x73c [ 187.542958] rtnetlinkrcvmsg+0x128/0x378 [ 187.547064] netlinkrcvskb+0x60/0x130 [ 187.550910] rtnetlinkrcv+0x18/0x24 [ 187.554492] netlinkunicast+0x300/0x36c [ 187.558425] netlinksendmsg+0x1a8/0x420 [ 187.606759] ---[ end trace 0000000000000000 ]---

In addition, some PFs also do not support configuring preemptible TCs, such as eno1 and eno3 on LS1028A. It won't crash like it does for VFs, but we should prevent these PFs from accessing these unimplemented registers.(CVE-2024-56649)

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

Bluetooth: hcievent: Fix using rcuread_(un)lock while iterating

The usage of rcuread(un)lock while inside listforeachentryrcu is not safe since for the most part entries fetched this way shall be treated as rcu_dereference:

Note that the value returned by rcu_dereference() is valid
only within the enclosing RCU read-side critical section [1]_.
For example, the following is **not** legal::

    rcu_read_lock();
    p = rcu_dereference(head.next);
    rcu_read_unlock();
    x = p->address;  /* BUG!!! */
    rcu_read_lock();
    y = p->data; /* BUG!!! */
    rcu_read_unlock();(CVE-2024-56654)

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

net/mlx5: DR, prevent potential error pointer dereference

The drdomainaddvportcap() function generally returns NULL on error but sometimes we want it to return ERRPTR(-EBUSY) so the caller can retry. The problem here is that "ret" can be either -EBUSY or -ENOMEM and if it's and -ENOMEM then the error pointer is propogated back and eventually dereferenced in drstev0buildsrcgvmiqpntag().(CVE-2024-56660)

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

acpi: nfit: vmalloc-out-of-bounds Read in acpinfitctl

Fix an issue detected by syzbot with KASAN:

BUG: KASAN: vmalloc-out-of-bounds in cmdtofunc drivers/acpi/nfit/ core.c:416 [inline] BUG: KASAN: vmalloc-out-of-bounds in acpinfitctl+0x20e8/0x24a0 drivers/acpi/nfit/core.c:459

The issue occurs in cmdtofunc when the callpkg->ndreserved2 array is accessed without verifying that callpkg points to a buffer that is appropriately sized as a struct ndcmd_pkg. This can lead to out-of-bounds access and undefined behavior if the buffer does not have sufficient space.

To address this, a check was added in acpinfitctl() to ensure that buf is not NULL and that buflen is less than sizeof(*callpkg) before accessing it. This ensures safe access to the members of callpkg, including the ndreserved2 array.(CVE-2024-56662)

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

wifi: nl80211: fix NL80211ATTRMLOLINKID off-by-one

Since the netlink attribute range validation provides inclusive checking, the max of attribute NL80211ATTRMLOLINKID should be IEEE80211MLDMAXNUMLINKS - 1 otherwise causing an off-by-one.

One crash stack for demonstration:

BUG: KASAN: wild-memory-access in ieee80211txcontrol_port+0x3b6/0xca0 net/mac80211/tx.c:5939 Read of size 6 at addr 001102080000000c by task fuzzer.386/9508

CPU: 1 PID: 9508 Comm: syz.1.386 Not tainted 6.1.70 #2 Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x177/0x231 lib/dumpstack.c:106 printreport+0xe0/0x750 mm/kasan/report.c:398 kasanreport+0x139/0x170 mm/kasan/report.c:495 kasancheckrange+0x287/0x290 mm/kasan/generic.c:189 memcpy+0x25/0x60 mm/kasan/shadow.c:65 ieee80211txcontrolport+0x3b6/0xca0 net/mac80211/tx.c:5939 rdevtxcontrolport net/wireless/rdev-ops.h:761 [inline] nl80211txcontrolport+0x7b3/0xc40 net/wireless/nl80211.c:15453 genlfamilyrcvmsgdoit+0x22e/0x320 net/netlink/genetlink.c:756 genlfamilyrcvmsg net/netlink/genetlink.c:833 [inline] genlrcvmsg+0x539/0x740 net/netlink/genetlink.c:850 netlinkrcvskb+0x1de/0x420 net/netlink/afnetlink.c:2508 genlrcv+0x24/0x40 net/netlink/genetlink.c:861 netlinkunicastkernel net/netlink/afnetlink.c:1326 [inline] netlinkunicast+0x74b/0x8c0 net/netlink/afnetlink.c:1352 netlinksendmsg+0x882/0xb90 net/netlink/afnetlink.c:1874 socksendmsgnosec net/socket.c:716 [inline] _socksendmsg net/socket.c:728 [inline] syssendmsg+0x5cc/0x8f0 net/socket.c:2499 _syssendmsg+0x21c/0x290 net/socket.c:2553 _syssendmsg net/socket.c:2582 [inline] _dosyssendmsg net/socket.c:2591 [inline] _sesyssendmsg+0x19e/0x270 net/socket.c:2589 dosyscallx64 arch/x86/entry/common.c:51 [inline] dosyscall64+0x45/0x90 arch/x86/entry/common.c:81 entrySYSCALL64afterhwframe+0x63/0xcd

Update the policy to ensure correct validation.(CVE-2024-56663)

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

drm/i915: Fix NULL pointer dereference in capture_engine

When the intelcontext structure contains NULL, it raises a NULL pointer dereference error in drminfo().

(cherry picked from commit 754302a5bc1bd8fd3b7d85c168b0a1af6d4bba4d)(CVE-2024-56667)

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

blk-cgroup: Fix UAF in blkcgunpinonline()

blkcgunpinonline() walks up the blkcg hierarchy putting the online pin. To walk up, it uses blkcgparent(blkcg) but it was calling that after blkcgdestroy_blkgs(blkcg) which could free the blkcg, leading to the following UAF:

================================================================== BUG: KASAN: slab-use-after-free in blkcgunpinonline+0x15a/0x270 Read of size 8 at addr ffff8881057678c0 by task kworker/9:1/117

CPU: 9 UID: 0 PID: 117 Comm: kworker/9:1 Not tainted 6.13.0-rc1-work-00182-gb8f52214c61a-dirty #48 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 02/02/2022 Workqueue: cgwbrelease cgwbreleaseworkfn Call Trace: <TASK> dumpstacklvl+0x27/0x80 printreport+0x151/0x710 kasanreport+0xc0/0x100 blkcgunpinonline+0x15a/0x270 cgwbreleaseworkfn+0x194/0x480 processscheduledworks+0x71b/0xe20 workerthread+0x82a/0xbd0 kthread+0x242/0x2c0 retfromfork+0x33/0x70 retfromforkasm+0x1a/0x30 </TASK> ... Freed by task 1944: kasansavetrack+0x2b/0x70 kasansavefreeinfo+0x3c/0x50 _kasanslabfree+0x33/0x50 kfree+0x10c/0x330 cssfreerworkfn+0xe6/0xb30 processscheduledworks+0x71b/0xe20 workerthread+0x82a/0xbd0 kthread+0x242/0x2c0 retfromfork+0x33/0x70 retfromforkasm+0x1a/0x30

Note that the UAF is not easy to trigger as the free path is indirected behind a couple RCU grace periods and a work item execution. I could only trigger it with artifical msleep() injected in blkcgunpinonline().

Fix it by reading the parent pointer before destroying the blkcg's blkg's.(CVE-2024-56672)

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

octeontx2-pf: handle otx2mboxgetrsp errors in otx2common.c

Add error pointer check after calling otx2mboxget_rsp().(CVE-2024-56679)

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

mfd: intelsocpmic_bxtwc: Use IRQ domain for USB Type-C device

While design wise the idea of converting the driver to use the hierarchy of the IRQ chips is correct, the implementation has (inherited) flaws. This was unveiled when platformgetirq() had started WARN() on IRQ 0 that is supposed to be a Linux IRQ number (also known as vIRQ).

Rework the driver to respect IRQ domain when creating each MFD device separately, as the domain is not the same for all of them.(CVE-2024-56691)

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

bpf, sockmap: Several fixes to bpfmsgpop_data

Several fixes to bpfmsgpopdata, 1. In skmsgshiftleft, we should putpage 2. if (len == 0), return early is better 3. pop the entire skmsg (last == msg->sg.size) should be supported 4. Fix for the value of variable "a" 5. In skmsgshiftleft, after shifting, i has already pointed to the next element. Addtional skmsgitervar_next may result in BUG.(CVE-2024-56720)

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

octeontx2-pf: handle otx2mboxget_rsp errors in cn10k.c

Add error pointer check after calling otx2mboxget_rsp().(CVE-2024-56726)

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

rtc: check if _rtcreadtime was successful in rtctimerdowork()

If the _rtcreadtime call fails,, the struct rtctime tm; may contain uninitialized data, or an illegal date/time read from the RTC hardware.

When calling rtctmtoktime later, the result may be a very large value (possibly KTIMEMAX). If there are periodic timers in rtc->timerqueue, they will continually expire, may causing kernel softlockup.(CVE-2024-56739)

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

vfio/mlx5: Fix an unwind issue in mlx5vfaddmigration_pages()

Fix an unwind issue in mlx5vfaddmigration_pages().

If a set of pages is allocated but fails to be added to the SG table, they need to be freed to prevent a memory leak.

Any pages successfully added to the SG table will be freed as part of mlx5vffreedata_buffer().(CVE-2024-56742)

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

PCI: Fix resetmethodstore() memory leak

In resetmethodstore(), a string is allocated via kstrndup() and assigned to the local "options". options is then used in with strsep() to find spaces:

while ((name = strsep(&options, " ")) != NULL) {

If there are no remaining spaces, then options is set to NULL by strsep(), so the subsequent kfree(options) doesn't free the memory allocated via kstrndup().

Fix by using a separate tmp_options to iterate with strsep() so options is preserved.(CVE-2024-56745)

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

scsi: qedi: Fix a possible memory leak in qediallocandinitsb()

Hook "qediops->common->sbinit = qedsbinit" does not release the DMA memory sbvirt when it fails. Add dmafreecoherent() to free it. This is the same way as qedrallocmemsb() and qedeallocmem_sb().(CVE-2024-56747)

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

netfs/fscache: Add a memory barrier for FSCACHEVOLUMECREATING

In fscachecreatevolume(), there is a missing memory barrier between the bit-clearing operation and the wake-up operation. This may cause a situation where, after a wake-up, the bit-clearing operation hasn't been detected yet, leading to an indefinite wait. The triggering process is as follows:

[cookie1] [cookie2] [volumework] fscacheperformlookup fscachecreatevolume fscacheperformlookup fscachecreatevolume fscachecreatevolumework cachefilesacquirevolume clearandwakeupbit testandsetbit testandsetbit goto maybewait goto nowait

In the above process, cookie1 and cookie2 has the same volume. When cookie1 enters the -no_wait- process, it will clear the bit and wake up the waiting process. If a barrier is missing, it may cause cookie2 to remain in the -wait- process indefinitely.

In commit 3288666c7256 ("fscache: Use clearandwakeupbit() in fscachecreatevolumework()"), barriers were added to similar operations in fscachecreatevolumework(), but fscachecreatevolume() was missed.

By combining the clear and wake operations into clearandwakeupbit() to fix this issue.(CVE-2024-56755)

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

nvme-pci: fix freeing of the HMB descriptor table

The HMB descriptor table is sized to the maximum number of descriptors that could be used for a given device, but _nvmeallochostmem could break out of the loop earlier on memory allocation failure and end up using less descriptors than planned for, which leads to an incorrect size passed to dmafreecoherent.

In practice this was not showing up because the number of descriptors tends to be low and the dma coherent allocator always allocates and frees at least a page.(CVE-2024-56756)

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

btrfs: fix use-after-free when COWing tree bock and tracing is enabled

When a COWing a tree block, at btrfscowblock(), and we have the tracepoint tracebtrfscowblock() enabled and preemption is also enabled (CONFIGPREEMPT=y), we can trigger a use-after-free in the COWed extent buffer while inside the tracepoint code. This is because in some paths that call btrfscowblock(), such as btrfssearchslot(), we are holding the last reference on the extent buffer @buf so btrfsforcecowblock() drops the last reference on the @buf extent buffer when it calls freeextentbufferstale(buf), which schedules the release of the extent buffer with RCU. This means that if we are on a kernel with preemption, the current task may be preempted before calling tracebtrfscowblock() and the extent buffer already released by the time tracebtrfscowblock() is called, resulting in a use-after-free.

Fix this by moving the tracebtrfscowblock() from btrfscowblock() to btrfsforcecowblock() before the COWed extent buffer is freed. This also has a side effect of invoking the tracepoint in the tree defrag code, at defrag.c:btrfsreallocnode(), since btrfsforcecow_block() is called there, but this is fine and it was actually missing there.(CVE-2024-56759)

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

tracing: Prevent bad count for tracingcpumaskwrite

If a large count is provided, it will trigger a warning in bitmapparseuser. Also check zero for it.(CVE-2024-56763)