The Linux Kernel, the operating system core itself.

Security Fix(es):

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

net: can: j1939: enhanced error handling for tightly received RTS messages in xtprxrtssessionnew

This patch enhances error handling in scenarios with RTS (Request to Send) messages arriving closely. It replaces the less informative WARNONONCE backtraces with a new error handling method. This provides clearer error messages and allows for the early termination of problematic sessions. Previously, sessions were only released at the end of j1939xtprx_rts().

Potentially this could be reproduced with something like: testj1939 -r vcan0:0x80 & while true; do # send first RTS cansend vcan0 18EC8090#1014000303002301; # send second RTS cansend vcan0 18EC8090#1014000303002301; # send abort cansend vcan0 18EC8090#ff00000000002301; done(CVE-2023-52887)

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

Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_connect()

Extend a critical section to prevent chan from early freeing. Also make the l2cap_connect() return type void. Nothing is using the returned value but it is ugly to return a potentially freed pointer. Making it void will help with backports because earlier kernels did use the return value. Now the compile will break for kernels where this patch is not a complete fix.

Call stack summary:

[use] l2capbredrsigcmd l2capconnect ┌ mutexlock(&conn->chanlock); │ chan = pchan->ops->newconnection(pchan); <- alloc chan │ _l2capchanadd(conn, chan); │ l2capchanhold(chan); │ listadd(&chan->list, &conn->chanl); ... (1) └ mutexunlock(&conn->chanlock); chan->conf_state ... (4) <- use after free

[free] l2capconndel ┌ mutexlock(&conn->chanlock); │ foreach chan in conn->chanl: ... (2) │ l2capchanput(chan); │ l2capchandestroy │ kfree(chan) ... (3) <- chan freed └ mutexunlock(&conn->chan_lock);

================================================================== BUG: KASAN: slab-use-after-free in instrumentatomicread include/linux/instrumented.h:68 [inline] BUG: KASAN: slab-use-after-free in testbit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] BUG: KASAN: slab-use-after-free in l2capconnect+0xa67/0x11a0 net/bluetooth/l2capcore.c:4260 Read of size 8 at addr ffff88810bf040a0 by task kworker/u3:1/311(CVE-2024-36013)

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

net: hns3: fix kernel crash when devlink reload during pf initialization

The devlink reload process will access the hardware resources, but the register operation is done before the hardware is initialized. So, processing the devlink reload during initialization may lead to kernel crash. This patch fixes this by taking devl_lock during initialization.(CVE-2024-36021)

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

bnxtre: avoid shift undefined behavior in bnxtqpliballocinit_hwq

Undefined behavior is triggered when bnxtqpliballocinithwq is called with hwqattr->auxdepth != 0 and hwqattr->auxstride == 0. In that case, "rounduppowoftwo(hwqattr->auxstride)" gets called. rounduppowoftwo is documented as undefined for 0.

Fix it in the one caller that had this combination.

The undefined behavior was detected by UBSAN: UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 24 PID: 1075 Comm: (udev-worker) Not tainted 6.9.0-rc6+ #4 Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.7 10/25/2023 Call Trace: <TASK> dumpstacklvl+0x5d/0x80 ubsanepilogue+0x5/0x30 ubsanhandleshiftoutofbounds.cold+0x61/0xec _rounduppowoftwo+0x25/0x35 [bnxtre] bnxtqpliballocinithwq+0xa1/0x470 [bnxtre] bnxtqplibcreateqp+0x19e/0x840 [bnxtre] bnxtrecreateqp+0x9b1/0xcd0 [bnxtre] ? srsoaliasreturnthunk+0x5/0xfbef5 ? srsoaliasreturnthunk+0x5/0xfbef5 ? _kmalloc+0x1b6/0x4f0 ? createqp.part.0+0x128/0x1c0 [ibcore] ? _pfxbnxtrecreateqp+0x10/0x10 [bnxtre] createqp.part.0+0x128/0x1c0 [ibcore] ibcreateqpkernel+0x50/0xd0 [ibcore] createmadqp+0x8e/0xe0 [ibcore] ? _pfxqpeventhandler+0x10/0x10 [ibcore] ibmadinitdevice+0x2be/0x680 [ibcore] addclientcontext+0x10d/0x1a0 [ibcore] enabledeviceandget+0xe0/0x1d0 [ibcore] ibregisterdevice+0x53c/0x630 [ibcore] ? srsoaliasreturnthunk+0x5/0xfbef5 bnxtreprobe+0xbd8/0xe50 [bnxtre] ? _pfxbnxtreprobe+0x10/0x10 [bnxtre] auxiliarybusprobe+0x49/0x80 ? driversysfsadd+0x57/0xc0 reallyprobe+0xde/0x340 ? pmruntimebarrier+0x54/0x90 ? _pfxdriverattach+0x10/0x10 _driverprobedevice+0x78/0x110 driverprobedevice+0x1f/0xa0 _driverattach+0xba/0x1c0 busforeachdev+0x8f/0xe0 busadddriver+0x146/0x220 driverregister+0x72/0xd0 _auxiliarydriverregister+0x6e/0xd0 ? _pfxbnxtremodinit+0x10/0x10 [bnxtre] bnxtremodinit+0x3e/0xff0 [bnxtre] ? _pfxbnxtremodinit+0x10/0x10 [bnxtre] dooneinitcall+0x5b/0x310 doinitmodule+0x90/0x250 initmodulefromfile+0x86/0xc0 idempotentinitmodule+0x121/0x2b0 _x64sysfinitmodule+0x5e/0xb0 dosyscall64+0x82/0x160 ? srsoaliasreturnthunk+0x5/0xfbef5 ? syscallexittousermodeprepare+0x149/0x170 ? srsoaliasreturnthunk+0x5/0xfbef5 ? syscallexittousermode+0x75/0x230 ? srsoaliasreturnthunk+0x5/0xfbef5 ? dosyscall64+0x8e/0x160 ? srsoaliasreturnthunk+0x5/0xfbef5 ? _countmemcgevents+0x69/0x100 ? srsoaliasreturnthunk+0x5/0xfbef5 ? countmemcgevents.constprop.0+0x1a/0x30 ? srsoaliasreturnthunk+0x5/0xfbef5 ? handlemmfault+0x1f0/0x300 ? srsoaliasreturnthunk+0x5/0xfbef5 ? douseraddrfault+0x34e/0x640 ? srsoaliasreturnthunk+0x5/0xfbef5 ? srsoaliasreturnthunk+0x5/0xfbef5 entrySYSCALL64afterhwframe+0x76/0x7e RIP: 0033:0x7f4e5132821d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e3 db 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffca9c906a8 EFLAGS: 00000246 ORIGRAX: 0000000000000139 RAX: ffffffffffffffda RBX: 0000563ec8a8f130 RCX: 00007f4e5132821d RDX: 0000000000000000 RSI: 00007f4e518fa07d RDI: 000000000000003b RBP: 00007ffca9c90760 R08: 00007f4e513f6b20 R09: 00007ffca9c906f0 R10: 0000563ec8a8faa0 R11: 0000000000000246 R12: 00007f4e518fa07d R13: 0000000000020000 R14: 0000563ec8409e90 R15: 0000563ec8a8fa60 </TASK> ---[ end trace ]---(CVE-2024-38540)

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

media: atomisp: sshcss: Fix a null-pointer dereference in loadvideo_binaries

The allocation failure of mycs->yuvscalerbinary in loadvideobinaries() is followed with a dereference of mycs->yuvscalerbinary after the following call chain:

shcsspipeloadbinaries() |-> loadvideobinaries(mycs->yuvscalerbinary == NULL) | |-> shcsspipeunloadbinaries() |-> unloadvideobinaries()

In unloadvideobinaries(), it calls to iacssbinaryunload with argument &pipe->pipesettings.video.yuvscalerbinary[i], which refers to the same memory slot as mycs->yuvscalerbinary. Thus, a null-pointer dereference is triggered.(CVE-2024-38547)

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

um: Add winch to winch_handlers before registering winch IRQ

Registering a winch IRQ is racy, an interrupt may occur before the winch is added to the winch_handlers list.

If that happens, registerwinchirq() adds to that list a winch that is scheduled to be (or has already been) freed, causing a panic later in winch_cleanup().

Avoid the race by adding the winch to the winchhandlers list before registering the IRQ, and rolling back if umrequest_irq() fails.(CVE-2024-39292)

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

drm/shmem-helper: Fix BUGON() on mmap(PROTWRITE, MAP_PRIVATE)

Lack of check for copy-on-write (COW) mapping in drmgemshmemmmap allows users to call mmap with PROTWRITE and MAPPRIVATE flag causing a kernel panic due to BUGON in vmfinsertpfnprot: BUGON((vma->vmflags & VMPFNMAP) && iscowmapping(vma->vm_flags));

Return -EINVAL early if COW mapping is detected.

This bug affects all drm drivers using default shmem helpers. It can be reproduced by this simple example: void *ptr = mmap(0, size, PROTWRITE, MAPPRIVATE, fd, mmap_offset); ptr[0] = 0;(CVE-2024-39497)

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

wifi: mac80211: mesh: Fix leak of meshpreqqueue objects

The hwmp code use objects of type meshpreqqueue, added to a list in ieee80211ifmesh, to keep track of mpath we need to resolve. If the mpath gets deleted, ex mesh interface is removed, the entries in that list will never get cleaned. Fix this by flushing all corresponding items of the preqqueue in meshpathflushpending().

This should take care of KASAN reports like this:

unreferenced object 0xffff00000668d800 (size 128): comm "kworker/u8:4", pid 67, jiffies 4295419552 (age 1836.444s) hex dump (first 32 bytes): 00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff ..........h..... 8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00 ....>........... backtrace: [<000000007302a0b6>] _kmemcacheallocnode+0x1e0/0x35c [<00000000049bd418>] kmalloctrace+0x34/0x80 [<0000000000d792bb>] meshqueuepreq+0x44/0x2a8 [<00000000c99c3696>] meshnexthopresolve+0x198/0x19c [<00000000926bf598>] ieee80211xmit+0x1d0/0x1f4 [<00000000fc8c2284>] _ieee80211subifstartxmit+0x30c/0x764 [<000000005926ee38>] ieee80211subifstartxmit+0x9c/0x7a4 [<000000004c86e916>] devhardstartxmit+0x174/0x440 [<0000000023495647>] _devqueuexmit+0xe24/0x111c [<00000000cfe9ca78>] batadvsendskbpacket+0x180/0x1e4 [<000000007bacc5d5>] batadvvelpperiodicwork+0x2f4/0x508 [<00000000adc3cd94>] processonework+0x4b8/0xa1c [<00000000b36425d1>] workerthread+0x9c/0x634 [<0000000005852dd5>] kthread+0x1bc/0x1c4 [<000000005fccd770>] retfromfork+0x10/0x20 unreferenced object 0xffff000009051f00 (size 128): comm "kworker/u8:4", pid 67, jiffies 4295419553 (age 1836.440s) hex dump (first 32 bytes): 90 d6 92 0d 00 00 ff ff 00 d8 68 06 00 00 ff ff ..........h..... 36 27 92 e4 02 e0 01 00 00 58 79 06 00 00 ff ff 6'.......Xy..... backtrace: [<000000007302a0b6>] _kmemcacheallocnode+0x1e0/0x35c [<00000000049bd418>] kmalloctrace+0x34/0x80 [<0000000000d792bb>] meshqueuepreq+0x44/0x2a8 [<00000000c99c3696>] meshnexthopresolve+0x198/0x19c [<00000000926bf598>] ieee80211xmit+0x1d0/0x1f4 [<00000000fc8c2284>] _ieee80211subifstartxmit+0x30c/0x764 [<000000005926ee38>] ieee80211subifstartxmit+0x9c/0x7a4 [<000000004c86e916>] devhardstartxmit+0x174/0x440 [<0000000023495647>] _devqueuexmit+0xe24/0x111c [<00000000cfe9ca78>] batadvsendskbpacket+0x180/0x1e4 [<000000007bacc5d5>] batadvvelpperiodicwork+0x2f4/0x508 [<00000000adc3cd94>] processonework+0x4b8/0xa1c [<00000000b36425d1>] workerthread+0x9c/0x634 [<0000000005852dd5>] kthread+0x1bc/0x1c4 [<000000005fccd770>] retfromfork+0x10/0x20(CVE-2024-40942)

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

jfs: don't walk off the end of ealist

Add a check before visiting the members of ea to make sure each ea stays within the ealist.(CVE-2024-41017)

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

drm/amdgpu: Fix signedness bug in sdmav40processtrap_irq()

The "instance" variable needs to be signed for the error handling to work.(CVE-2024-41022)

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

Fix userfaultfd_api to return EINVAL as expected

Currently if we request a feature that is not set in the Kernel config we fail silently and return all the available features. However, the man page indicates we should return an EINVAL.

We need to fix this issue since we can end up with a Kernel warning should a program request the feature UFFDFEATUREWP_UNPOPULATED on a kernel with the config not set with this feature.

[ 200.812896] WARNING: CPU: 91 PID: 13634 at mm/memory.c:1660 zappterange+0x43d/0x660 [ 200.820738] Modules linked in: [ 200.869387] CPU: 91 PID: 13634 Comm: userfaultfd Kdump: loaded Not tainted 6.9.0-rc5+ #8 [ 200.877477] Hardware name: Dell Inc. PowerEdge R6525/0N7YGH, BIOS 2.7.3 03/30/2022 [ 200.885052] RIP: 0010:zappterange+0x43d/0x660(CVE-2024-41027)

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

nilfs2: fix kernel bug on rename operation of broken directory

Syzbot reported that in rename directory operation on broken directory on nilfs2, _blockwritebeginint() called to prepare block write may fail BUG_ON check for access exceeding the folio/page size.

This is because nilfs_dotdot(), which gets parent directory reference entry ("..") of the directory to be moved or renamed, does not check consistency enough, and may return location exceeding folio/page size for broken directories.

Fix this issue by checking required directory entries ("." and "..") in the first chunk of the directory in nilfs_dotdot().(CVE-2024-41034)

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

mm: prevent derefencing NULL ptr in pfnsectionvalid()

Commit 5ec8e8ea8b77 ("mm/sparsemem: fix race in accessing memorysection->usage") changed pfnsectionvalid() to add a READONCE() call around "ms->usage" to fix a race with sectiondeactivate() where ms->usage can be cleared. The READONCE() call, by itself, is not enough to prevent NULL pointer dereference. We need to check its value before dereferencing it.(CVE-2024-41055)

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

powerpc/pseries: Whitelist dtl slub object for copying to userspace

Reading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-* results in a BUG() when the config CONFIGHARDENEDUSERCOPY is enabled as shown below.

kernel BUG at mm/usercopy.c:102!
Oops: Exception in kernel mode, sig: 5 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
Modules linked in: xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc
scsi_transport_fc ibmveth pseries_wdt dm_multipath dm_mirror dm_region_hash dm_log dm_mod fuse
CPU: 27 PID: 1815 Comm: python3 Not tainted 6.10.0-rc3 #85
Hardware name: IBM,9040-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_042) hv:phyp pSeries
NIP:  c0000000005d23d4 LR: c0000000005d23d0 CTR: 00000000006ee6f8
REGS: c000000120c078c0 TRAP: 0700   Not tainted  (6.10.0-rc3)
MSR:  8000000000029033 <SF,EE,ME,IR,DR,RI,LE>  CR: 2828220f  XER: 0000000e
CFAR: c0000000001fdc80 IRQMASK: 0
[ ... GPRs omitted ... ]
NIP [c0000000005d23d4] usercopy_abort+0x78/0xb0
LR [c0000000005d23d0] usercopy_abort+0x74/0xb0
Call Trace:
 usercopy_abort+0x74/0xb0 (unreliable)
 __check_heap_object+0xf8/0x120
 check_heap_object+0x218/0x240
 __check_object_size+0x84/0x1a4
 dtl_file_read+0x17c/0x2c4
 full_proxy_read+0x8c/0x110
 vfs_read+0xdc/0x3a0
 ksys_read+0x84/0x144
 system_call_exception+0x124/0x330
 system_call_vectored_common+0x15c/0x2ec
--- interrupt: 3000 at 0x7fff81f3ab34

Commit 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0") requires that only whitelisted areas in slab/slub objects can be copied to userspace when usercopy hardening is enabled using CONFIGHARDENEDUSERCOPY. Dtl contains hypervisor dispatch events which are expected to be read by privileged users. Hence mark this safe for user access. Specify useroffset=0 and usersize=DISPATCHLOGBYTES to whitelist the entire object.(CVE-2024-41065)

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

KVM: PPC: Book3S HV: Prevent UAF in kvmspaprtceattachiommu_group()

Al reported a possible use-after-free (UAF) in kvmspaprtceattachiommu_group().

It looks up stt from tablefd, but then continues to use it after doing fdput() on the returned fd. After the fdput() the tablefd is free to be closed by another thread. The close calls kvmspaprtcerelease() and then releasespaprtcetable() (via call_rcu()) which frees stt.

Although there are calls to rcureadlock() in kvmspaprtceattachiommu_group() they are not sufficient to prevent the UAF, because stt is used outside the locked regions.

With an artifcial delay after the fdput() and a userspace program which triggers the race, KASAN detects the UAF:

BUG: KASAN: slab-use-after-free in kvmspaprtceattachiommugroup+0x298/0x720 [kvm] Read of size 4 at addr c000200027552c30 by task kvm-vfio/2505 CPU: 54 PID: 2505 Comm: kvm-vfio Not tainted 6.10.0-rc3-next-20240612-dirty #1 Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Call Trace: dumpstacklvl+0xb4/0x108 (unreliable) printreport+0x2b4/0x6ec kasanreport+0x118/0x2b0 _asanload4+0xb8/0xd0 kvmspaprtceattachiommugroup+0x298/0x720 [kvm] kvmvfiosetattr+0x524/0xac0 [kvm] kvmdeviceioctl+0x144/0x240 [kvm] sysioctl+0x62c/0x1810 systemcallexception+0x190/0x440 systemcallvectoredcommon+0x15c/0x2ec ... Freed by task 0: ... kfree+0xec/0x3e0 releasespaprtcetable+0xd4/0x11c [kvm] rcucore+0x568/0x16a0 handlesoftirqs+0x23c/0x920 dosoftirqownstack+0x6c/0x90 dosoftirqownstack+0x58/0x90 _irqexitrcu+0x218/0x2d0 irqexit+0x30/0x80 archlocalirqrestore+0x128/0x230 archlocalirqenable+0x1c/0x30 cpuidleenterstate+0x134/0x5cc cpuidleenter+0x6c/0xb0 callcpuidle+0x7c/0x100 doidle+0x394/0x410 cpustartupentry+0x60/0x70 startsecondary+0x3fc/0x410 startsecondaryprolog+0x10/0x14

Fix it by delaying the fdput() until stt is no longer in use, which is effectively the entire function. To keep the patch minimal add a call to fdput() at each of the existing return paths. Future work can convert the function to goto or __cleanup style cleanup.

With the fix in place the test case no longer triggers the UAF.(CVE-2024-41070)

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

btrfs: qgroup: fix quota root leak after quota disable failure

If during the quota disable we fail when cleaning the quota tree or when deleting the root from the root tree, we jump to the 'out' label without ever dropping the reference on the quota root, resulting in a leak of the root since fsinfo->quotaroot is no longer pointing to the root (we have set it to NULL just before those steps).

Fix this by always doing a btrfsputroot() call under the 'out' label. This is a problem that exists since qgroups were first added in 2012 by commit bed92eae26cc ("Btrfs: qgroup implementation and prototypes"), but back then we missed a kfree on the quota root and freeextentbuffer() calls on its root and commit root nodes, since back then roots were not yet reference counted.(CVE-2024-41078)

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

ila: block BH in ila_output()

As explained in commit 1378817486d6 ("tipc: block BH before using dstcache"), net/core/dstcache.c helpers need to be called with BH disabled.

ilaoutput() is called from lwtunneloutput() possibly from process context, and under rcureadlock().

We might be interrupted by a softirq, re-enter ilaoutput() and corrupt dstcache data structures.

Fix the race by using localbhdisable().(CVE-2024-41081)

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

drm/nouveau/dispnv04: fix null pointer dereference in nv17tvgethdmodes

In nv17tvgethdmodes(), the return value of drmmodeduplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drmmodeduplicate(). The same applies to drmcvtmode(). Add a check to avoid null pointer dereference.(CVE-2024-41089)

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

drm/nouveau/dispnv04: fix null pointer dereference in nv17tvgetldmodes

In nv17tvgetldmodes(), the return value of drmmodeduplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drmmodeduplicate(). Add a check to avoid npd.(CVE-2024-41095)

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

usb: atm: cxacru: fix endpoint checking in cxacru_bind()

Syzbot is still reporting quite an old issue [1] that occurs due to incomplete checking of present usb endpoints. As such, wrong endpoints types may be used at urb sumbitting stage which in turn triggers a warning in usbsubmiturb().

Fix the issue by verifying that required endpoint types are present for both in and out endpoints, taking into account cmd endpoint type.

Unfortunately, this patch has not been tested on real hardware.

[1] Syzbot report: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usbsubmiturb+0xed2/0x18a0 drivers/usb/core/urb.c:502 Modules linked in: CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usbhubwq hubevent RIP: 0010:usbsubmiturb+0xed2/0x18a0 drivers/usb/core/urb.c:502 ... Call Trace: cxacrucm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649 cxacrucardstatus+0x22/0xd0 drivers/usb/atm/cxacru.c:760 cxacrubind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209 usbatmusbprobe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055 cxacruusbprobe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363 usbprobeinterface+0x315/0x7f0 drivers/usb/core/driver.c:396 calldriverprobe drivers/base/dd.c:517 [inline] reallyprobe+0x23c/0xcd0 drivers/base/dd.c:595 _driverprobedevice+0x338/0x4d0 drivers/base/dd.c:747 driverprobedevice+0x4c/0x1a0 drivers/base/dd.c:777 _deviceattachdriver+0x20b/0x2f0 drivers/base/dd.c:894 busforeachdrv+0x15f/0x1e0 drivers/base/bus.c:427 _deviceattach+0x228/0x4a0 drivers/base/dd.c:965 busprobedevice+0x1e4/0x290 drivers/base/bus.c:487 deviceadd+0xc2f/0x2180 drivers/base/core.c:3354 usbsetconfiguration+0x113a/0x1910 drivers/usb/core/message.c:2170 usbgenericdriverprobe+0xba/0x100 drivers/usb/core/generic.c:238 usbprobe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293(CVE-2024-41097)

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

net: can: j1939: Initialize unused data in j1939sendone()

syzbot reported kernel-infoleak in rawrecvmsg() [1]. j1939send_one() creates full frame including unused data, but it doesn't initialize it. This causes the kernel-infoleak issue. Fix this by initializing unused data.

[1] BUG: KMSAN: kernel-infoleak in instrumentcopytouser include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in copytouseriter lib/ioviter.c:24 [inline] BUG: KMSAN: kernel-infoleak in iterateubuf include/linux/ioviter.h:29 [inline] BUG: KMSAN: kernel-infoleak in iterateandadvance2 include/linux/ioviter.h:245 [inline] BUG: KMSAN: kernel-infoleak in iterateandadvance include/linux/ioviter.h:271 [inline] BUG: KMSAN: kernel-infoleak in _copytoiter+0x366/0x2520 lib/ioviter.c:185 instrumentcopytouser include/linux/instrumented.h:114 [inline] copytouseriter lib/ioviter.c:24 [inline] iterateubuf include/linux/ioviter.h:29 [inline] iterateandadvance2 include/linux/ioviter.h:245 [inline] iterateandadvance include/linux/ioviter.h:271 [inline] _copytoiter+0x366/0x2520 lib/ioviter.c:185 copytoiter include/linux/uio.h:196 [inline] memcpytomsg include/linux/skbuff.h:4113 [inline] rawrecvmsg+0x2b8/0x9e0 net/can/raw.c:1008 sockrecvmsgnosec net/socket.c:1046 [inline] sockrecvmsg+0x2c4/0x340 net/socket.c:1068 _sysrecvmsg+0x18a/0x620 net/socket.c:2803 sysrecvmsg+0x223/0x840 net/socket.c:2845 dorecvmmsg+0x4fc/0xfd0 net/socket.c:2939 _sysrecvmmsg net/socket.c:3018 [inline] _dosysrecvmmsg net/socket.c:3041 [inline] _sesysrecvmmsg net/socket.c:3034 [inline] _x64sysrecvmmsg+0x397/0x490 net/socket.c:3034 x64syscall+0xf6c/0x3b50 arch/x86/include/generated/asm/syscalls64.h:300 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcf/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f

Uninit was created at: slabpostallochook mm/slub.c:3804 [inline] slaballocnode mm/slub.c:3845 [inline] kmemcacheallocnode+0x613/0xc50 mm/slub.c:3888 kmallocreserve+0x13d/0x4a0 net/core/skbuff.c:577 allocskb+0x35b/0x7a0 net/core/skbuff.c:668 allocskb include/linux/skbuff.h:1313 [inline] allocskbwithfrags+0xc8/0xbf0 net/core/skbuff.c:6504 sockallocsendpskb+0xa81/0xbf0 net/core/sock.c:2795 sockallocsendskb include/net/sock.h:1842 [inline] j1939skallocskb net/can/j1939/socket.c:878 [inline] j1939sksendloop net/can/j1939/socket.c:1142 [inline] j1939sksendmsg+0xc0a/0x2730 net/can/j1939/socket.c:1277 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg+0x30f/0x380 net/socket.c:745 syssendmsg+0x877/0xb60 net/socket.c:2584 _syssendmsg+0x28d/0x3c0 net/socket.c:2638 _syssendmsg net/socket.c:2667 [inline] _dosyssendmsg net/socket.c:2676 [inline] _sesyssendmsg net/socket.c:2674 [inline] _x64syssendmsg+0x307/0x4a0 net/socket.c:2674 x64syscall+0xc4b/0x3b50 arch/x86/include/generated/asm/syscalls64.h:47 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcf/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

Bytes 12-15 of 16 are uninitialized Memory access of size 16 starts at ffff888120969690 Data copied to user address 00000000200017c0

CPU: 1 PID: 5050 Comm: syz-executor198 Not tainted 6.9.0-rc5-syzkaller-00031-g71b1543c83d6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024(CVE-2024-42076)

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

ocfs2: fix DIO failure due to insufficient transaction credits

The code in ocfs2dioendiowrite() estimates number of necessary transaction credits using ocfs2calcextend_credits(). This however does not take into account that the IO could be arbitrarily large and can contain arbitrary number of extents.

Extent tree manipulations do often extend the current transaction but not in all of the cases. For example if we have only single block extents in the tree, ocfs2markextentwritten() will end up calling ocfs2replaceextentrec() all the time and we will never extend the current transaction and eventually exhaust all the transaction credits if the IO contains many single block extents. Once that happens a WARNON(jbd2handlebuffercredits(handle) <= 0) is triggered in jbd2journaldirty_metadata() and subsequently OCFS2 aborts in response to this error. This was actually triggered by one of our customers on a heavily fragmented OCFS2 filesystem.

To fix the issue make sure the transaction always has enough credits for one extent insert before each call of ocfs2markextent_written().

Heming Zhao said:

PANIC: "Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error"

PID: xxx TASK: xxxx CPU: 5 COMMAND: "SubmitThread-CA" #0 machinekexec at ffffffff8c069932 #1 _crashkexec at ffffffff8c1338fa #2 panic at ffffffff8c1d69b9 #3 ocfs2handleerror at ffffffffc0c86c0c [ocfs2] #4 _ocfs2abort at ffffffffc0c88387 [ocfs2] #5 ocfs2journaldirty at ffffffffc0c51e98 [ocfs2] #6 ocfs2splitextent at ffffffffc0c27ea3 [ocfs2] #7 ocfs2changeextentflag at ffffffffc0c28053 [ocfs2] #8 ocfs2markextentwritten at ffffffffc0c28347 [ocfs2] #9 ocfs2dioendio_write at ffffffffc0c2bef9 [ocfs2]

10 ocfs2dioend_io at ffffffffc0c2c0f5 [ocfs2]

11 dio_complete at ffffffff8c2b9fa7

12 doblockdevdirect_IO at ffffffff8c2bc09f

13 ocfs2directIO at ffffffffc0c2b653 [ocfs2]

14 genericfiledirect_write at ffffffff8c1dcf14

15 _genericfilewriteiter at ffffffff8c1dd07b

16 ocfs2filewrite_iter at ffffffffc0c49f1f [ocfs2]

17 aio_write at ffffffff8c2cc72e

18 kmemcachealloc at ffffffff8c248dde

19 doiosubmit at ffffffff8c2ccada

20 dosyscall64 at ffffffff8c004984

21 entrySYSCALL64afterhwframe at ffffffff8c8000ba(CVE-2024-42077)

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

RDMA/restrack: Fix potential invalid address access

struct rdmarestrackentry's kernname was set to KBUILDMODNAME in ibcreatecq(), while if the module exited but forgot del this rdmarestrackentry, it would cause a invalid address access in rdmarestrackclean() when print the owner of this rdmarestrackentry.

These code is used to help find one forgotten PD release in one of the ULPs. But it is not needed anymore, so delete them.(CVE-2024-42080)

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

xdp: Remove WARN() from _xdpregmemmodel()

syzkaller reports a warning in _xdpregmemmodel().

The warning occurs only if _memidinithash_table() returns an error. It returns the error in two cases:

1. memory allocation fails;
2. rhashtableinit() fails when some fields of rhashtableparams struct are not initialized properly.

The second case cannot happen since there is a static const rhashtable_params struct with valid fields. So, warning is only triggered when there is a problem with memory allocation.

Thus, there is no sense in using WARN() to handle this error and it can be safely removed.

WARNING: CPU: 0 PID: 5065 at net/core/xdp.c:299 _xdpregmemmodel+0x2d9/0x650 net/core/xdp.c:299

CPU: 0 PID: 5065 Comm: syz-executor883 Not tainted 6.8.0-syzkaller-05271-gf99c5f563c17 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:_xdpregmemmodel+0x2d9/0x650 net/core/xdp.c:299

Call Trace: xdpregmemmodel+0x22/0x40 net/core/xdp.c:344 xdptestrunsetup net/bpf/testrun.c:188 [inline] bpftestrunxdplive+0x365/0x1e90 net/bpf/testrun.c:377 bpfprogtestrunxdp+0x813/0x11b0 net/bpf/testrun.c:1267 bpfprogtestrun+0x33a/0x3b0 kernel/bpf/syscall.c:4240 _sysbpf+0x48d/0x810 kernel/bpf/syscall.c:5649 _dosysbpf kernel/bpf/syscall.c:5738 [inline] _sesysbpf kernel/bpf/syscall.c:5736 [inline] _x64sysbpf+0x7c/0x90 kernel/bpf/syscall.c:5736 dosyscall64+0xfb/0x240 entrySYSCALL64after_hwframe+0x6d/0x75

Found by Linux Verification Center (linuxtesting.org) with syzkaller.(CVE-2024-42082)

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

ftruncate: pass a signed offset

The old ftruncate() syscall, using the 32-bit off_t misses a sign extension when called in compat mode on 64-bit architectures. As a result, passing a negative length accidentally succeeds in truncating to file size between 2GiB and 4GiB.

Changing the type of the compat syscall to the signed compatofft changes the behavior so it instead returns -EINVAL.

The native entry point, the truncate() syscall and the corresponding loff_t based variants are all correct already and do not suffer from this mistake.(CVE-2024-42084)

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

drm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep

The ilitek-ili9881c controls the reset GPIO using the non-sleeping gpiodsetvalue() function. This complains loudly when the GPIO controller needs to sleep. As the caller can sleep, use gpiodsetvalue_cansleep() to fix the issue.(CVE-2024-42087)

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

ASoC: fsl-asoc-card: set priv->pdev before using it

priv->pdev pointer was set after being used in fslasoccardaudmuxinit(). Move this assignment at the start of the probe function, so sub-functions can correctly use pdev through priv.

fslasoccardaudmuxinit() dereferences priv->pdev to get access to the dev struct, used with dev_err macros. As priv is zero-initialised, there would be a NULL pointer dereference. Note that if priv->dev is dereferenced before assignment but never used, for example if there is no error to be printed, the driver won't crash probably due to compiler optimisations.(CVE-2024-42089)

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

pinctrl: fix deadlock in createpinctrl() when handling -EPROBEDEFER

In createpinctrl(), pinctrlmapsmutex is acquired before calling addsetting(). If addsetting() returns -EPROBEDEFER, createpinctrl() calls pinctrlfree(). However, pinctrlfree() attempts to acquire pinctrlmapsmutex, which is already held by createpinctrl(), leading to a potential deadlock.

This patch resolves the issue by releasing pinctrlmapsmutex before calling pinctrl_free(), preventing the deadlock.

This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc.(CVE-2024-42090)

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

gpio: davinci: Validate the obtained number of IRQs

Value of pdata->gpiounbanked is taken from Device Tree. In case of broken DT due to any error this value can be any. Without this value validation there can be out of chips->irqs array boundaries access in davincigpio_probe().

Validate the obtained nirq value so that it won't exceed the maximum number of IRQs per bank.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-42092)

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

net/dpaa2: Avoid explicit cpumask var allocation on stack

For CONFIGCPUMASKOFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow.

Instead, kernel code should always use *cpumaskvar API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIGCPUMASK_OFFSTACK.

Use *cpumask_var API(s) to address it.(CVE-2024-42093)

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

net/iucv: Avoid explicit cpumask var allocation on stack

For CONFIGCPUMASKOFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow.

Instead, kernel code should always use *cpumaskvar API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIGCPUMASK_OFFSTACK.

Use *cpumask_var API(s) to address it.(CVE-2024-42094)

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

serial: 8250_omap: Implementation of Errata i2310

As per Errata i2310[0], Erroneous timeout can be triggered, if this Erroneous interrupt is not cleared then it may leads to storm of interrupts, therefore apply Errata i2310 solution.

[0] https://www.ti.com/lit/pdf/sprz536 page 23(CVE-2024-42095)

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

x86: stop playing stack games in profile_pc()

The 'profile_pc()' function is used for timer-based profiling, which isn't really all that relevant any more to begin with, but it also ends up making assumptions based on the stack layout that aren't necessarily valid.

Basically, the code tries to account the time spent in spinlocks to the caller rather than the spinlock, and while I support that as a concept, it's not worth the code complexity or the KASAN warnings when no serious profiling is done using timers anyway these days.

And the code really does depend on stack layout that is only true in the simplest of cases. We've lost the comment at some point (I think when the 32-bit and 64-bit code was unified), but it used to say:

Assume the lock function has either no stack frame or a copy
of eflags from PUSHF.

which explains why it just blindly loads a word or two straight off the stack pointer and then takes a minimal look at the values to just check if they might be eflags or the return pc:

Eflags always has bits 22 and up cleared unlike kernel addresses

but that basic stack layout assumption assumes that there isn't any lock debugging etc going on that would complicate the code and cause a stack frame.

It causes KASAN unhappiness reported for years by syzkaller [1] and others [2].

With no real practical reason for this any more, just remove the code.

Just for historical interest, here's some background commits relating to this code from 2006:

0cb91a229364 ("i386: Account spinlocks to the caller during profiling for !FP kernels") 31679f38d886 ("Simplify profile_pc on x86-64")

and a code unification from 2009:

ef4512882dbe ("x86: time32/64.c unify profilepc")

but the basics of this thing actually goes back to before the git tree.(CVE-2024-42096)

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

crypto: ecdh - explicitly zeroize private_key

privatekey is overwritten with the key parameter passed in by the caller (if present), or alternatively a newly generated private key. However, it is possible that the caller provides a key (or the newly generated key) which is shorter than the previous key. In that scenario, some key material from the previous key would not be overwritten. The easiest solution is to explicitly zeroize the entire privatekey array first.

Note that this patch slightly changes the behavior of this function: previously, if the eccgenprivkey failed, the old privatekey would remain. Now, the privatekey is always zeroized. This behavior is consistent with the case where params.key is set and ecciskey_valid fails.(CVE-2024-42098)

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

inetdiag: Initialize pad field in struct inetdiagreqv2

KMSAN reported uninit-value access in rawlookup() [1]. Diag for raw sockets uses the pad field in struct inetdiagreqv2 for the underlying protocol. This field corresponds to the sdiagrawprotocol field in struct inetdiagreq_raw.

inetdiaggetexactcompat() converts inetdiagreq to inetdiagreqv2, but leaves the pad field uninitialized. So the issue occurs when rawlookup() accesses the sdiagrawprotocol field.

Fix this by initializing the pad field in inetdiaggetexactcompat(). Also, do the same fix in inetdiagdump_compat() to avoid the similar issue in the future.

[1] BUG: KMSAN: uninit-value in rawlookup net/ipv4/rawdiag.c:49 [inline] BUG: KMSAN: uninit-value in rawsockget+0x657/0x800 net/ipv4/rawdiag.c:71 rawlookup net/ipv4/rawdiag.c:49 [inline] rawsockget+0x657/0x800 net/ipv4/rawdiag.c:71 rawdiagdumpone+0xa1/0x660 net/ipv4/rawdiag.c:99 inetdiagcmdexact+0x7d9/0x980 inetdiaggetexactcompat net/ipv4/inetdiag.c:1404 [inline] inetdiagrcvmsgcompat+0x469/0x530 net/ipv4/inetdiag.c:1426 sockdiagrcvmsg+0x23d/0x740 net/core/sockdiag.c:282 netlinkrcvskb+0x537/0x670 net/netlink/afnetlink.c:2564 sockdiagrcv+0x35/0x40 net/core/sockdiag.c:297 netlinkunicastkernel net/netlink/afnetlink.c:1335 [inline] netlinkunicast+0xe74/0x1240 net/netlink/afnetlink.c:1361 netlinksendmsg+0x10c6/0x1260 net/netlink/afnetlink.c:1905 socksendmsgnosec net/socket.c:730 [inline] socksendmsg+0x332/0x3d0 net/socket.c:745 _syssendmsg+0x7f0/0xb70 net/socket.c:2585 _syssendmsg+0x271/0x3b0 net/socket.c:2639 _syssendmsg net/socket.c:2668 [inline] _dosyssendmsg net/socket.c:2677 [inline] _sesyssendmsg net/socket.c:2675 [inline] _x64syssendmsg+0x27e/0x4a0 net/socket.c:2675 x64syscall+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls64.h:47 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xd9/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

Uninit was stored to memory at: rawsockget+0x650/0x800 net/ipv4/rawdiag.c:71 rawdiagdumpone+0xa1/0x660 net/ipv4/rawdiag.c:99 inetdiagcmdexact+0x7d9/0x980 inetdiaggetexactcompat net/ipv4/inetdiag.c:1404 [inline] inetdiagrcvmsgcompat+0x469/0x530 net/ipv4/inetdiag.c:1426 sockdiagrcvmsg+0x23d/0x740 net/core/sockdiag.c:282 netlinkrcvskb+0x537/0x670 net/netlink/afnetlink.c:2564 sockdiagrcv+0x35/0x40 net/core/sockdiag.c:297 netlinkunicastkernel net/netlink/afnetlink.c:1335 [inline] netlinkunicast+0xe74/0x1240 net/netlink/afnetlink.c:1361 netlinksendmsg+0x10c6/0x1260 net/netlink/afnetlink.c:1905 socksendmsgnosec net/socket.c:730 [inline] socksendmsg+0x332/0x3d0 net/socket.c:745 syssendmsg+0x7f0/0xb70 net/socket.c:2585 _syssendmsg+0x271/0x3b0 net/socket.c:2639 _syssendmsg net/socket.c:2668 [inline] _dosyssendmsg net/socket.c:2677 [inline] _sesyssendmsg net/socket.c:2675 [inline] _x64syssendmsg+0x27e/0x4a0 net/socket.c:2675 x64syscall+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls64.h:47 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xd9/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

Local variable req.i created at: inetdiaggetexactcompat net/ipv4/inetdiag.c:1396 [inline] inetdiagrcvmsgcompat+0x2a6/0x530 net/ipv4/inetdiag.c:1426 sockdiagrcvmsg+0x23d/0x740 net/core/sockdiag.c:282

CPU: 1 PID: 8888 Comm: syz-executor.6 Not tainted 6.10.0-rc4-00217-g35bb670d65fc #32 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014(CVE-2024-42106)

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

drm/amd/display: Skip finding free audio for unknown engine_id

[WHY] ENGINEIDUNKNOWN = -1 and can not be used as an array index. Plus, it also means it is uninitialized and does not need free audio.

[HOW] Skip and return NULL.

This fixes 2 OVERRUN issues reported by Coverity.(CVE-2024-42119)

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

scsi: qedf: Make qedfexecutetmf() non-preemptible

Stop calling smpprocessorid() from preemptible code in qedfexecutetmf90. This results in BUG_ON() when running an RT kernel.

[ 659.343280] BUG: using smpprocessorid() in preemptible [00000000] code: sgreset/3646 [ 659.343282] caller is qedfexecute_tmf+0x8b/0x360 qedf

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

Bluetooth: qca: Fix BT enable failure again for QCA6390 after warm reboot

Commit 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed serdev") will cause below regression issue:

BT can't be enabled after below steps: cold boot -> enable BT -> disable BT -> warm reboot -> BT enable failure if property enable-gpios is not configured within DT|ACPI for QCA6390.

The commit is to fix a use-after-free issue within qcaserdevshutdown() by adding condition to avoid the serdev is flushed or wrote after closed but also introduces this regression issue regarding above steps since the VSC is not sent to reset controller during warm reboot.

Fixed by sending the VSC to reset controller within qcaserdevshutdown() once BT was ever enabled, and the use-after-free issue is also fixed by this change since the serdev is still opened before it is flushed or wrote.

Verified by the reported machine Dell XPS 13 9310 laptop over below two kernel commits: commit e00fc2700a3f ("Bluetooth: btusb: Fix triggering coredump implementation for QCA") of bluetooth-next tree. commit b23d98d46d28 ("Bluetooth: btusb: Fix triggering coredump implementation for QCA") of linus mainline tree.(CVE-2024-42137)

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

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

IB/core: Implement a limit on UMAD receive List

The existing behavior of ib_umad, which maintains received MAD packets in an unbounded list, poses a risk of uncontrolled growth. As user-space applications extract packets from this list, the rate of extraction may not match the rate of incoming packets, leading to potential list overflow.

To address this, we introduce a limit to the size of the list. After considering typical scenarios, such as OpenSM processing, which can handle approximately 100k packets per second, and the 1-second retry timeout for most packets, we set the list size limit to 200k. Packets received beyond this limit are dropped, assuming they are likely timed out by the time they are handled by user-space.

Notably, packets queued on the receive list due to reasons like timed-out sends are preserved even when the list is full.(CVE-2024-42145)

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

bnx2x: Fix multiple UBSAN array-index-out-of-bounds

Fix UBSAN warnings that occur when using a system with 32 physical cpu cores or more, or when the user defines a number of Ethernet queues greater than or equal to FPSBMAXE1x using the numqueues module parameter.

Currently there is a read/write out of bounds that occurs on the array "struct statsqueryentry query" present inside the "bnx2xfwstatsreq" struct in "drivers/net/ethernet/broadcom/bnx2x/bnx2x.h". Looking at the definition of the "struct statsquery_entry query" array:

struct statsqueryentry query[FPSBMAXE1x+ BNX2XFIRSTQUEUEQUERY_IDX];

FPSBMAXE1x is defined as the maximum number of fast path interrupts and has a value of 16, while BNX2XFIRSTQUEUEQUERYIDX has a value of 3 meaning the array has a total size of 19. Since accesses to "struct statsqueryentry query" are offset-ted by BNX2XFIRSTQUEUEQUERYIDX, that means that the total number of Ethernet queues should not exceed FPSBMAXE1x (16). However one of these queues is reserved for FCOE and thus the number of Ethernet queues should be set to [FPSBMAXE1x -1] (15) if FCOE is enabled or [FPSBMAXE1x] (16) if it is not.

This is also described in a comment in the source code in drivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definition of FPSBMAX_E1x. Below is the part of this explanation that it important for this patch

/* * The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is * control by the number of fast-path status blocks supported by the * device (HW/FW). Each fast-path status block (FP-SB) aka non-default * status block represents an independent interrupts context that can * serve a regular L2 networking queue. However special L2 queues such * as the FCoE queue do not require a FP-SB and other components like * the CNIC may consume FP-SB reducing the number of possible L2 queues * * If the maximum number of FP-SB available is X then: * a. If CNIC is supported it consumes 1 FP-SB thus the max number of * regular L2 queues is Y=X-1 * b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor) * c. If the FCoE L2 queue is supported the actual number of L2 queues * is Y+1 * d. The number of irqs (MSIX vectors) is either Y+1 (one extra for * slow-path interrupts) or Y+2 if CNIC is supported (one additional * FP interrupt context for the CNIC). * e. The number of HW context (CID count) is always X or X+1 if FCoE * L2 queue is supported. The cid for the FCoE L2 queue is always X. */

However this driver also supports NICs that use the E2 controller which can handle more queues due to having more FP-SB represented by FPSBMAXE2. Looking at the commits when the E2 support was added, it was originally using the E1x parameters: commit f2e0899f0f27 ("bnx2x: Add 57712 support"). Back then FPSBMAXE2 was set to 16 the same as E1x. However the driver was later updated to take full advantage of the E2 instead of having it be limited to the capabilities of the E1x. But as far as we can tell, the array "statsqueryentry query" was still limited to using the FP-SB available to the E1x cards as part of an oversignt when the driver was updated to take full advantage of the E2, and now with the driver being aware of the greater queue size supported by E2 NICs, it causes the UBSAN warnings seen in the stack traces below.

This patch increases the size of the "statsqueryentry query" array by replacing FPSBMAXE1x with FPSBMAXE2 to be large enough to handle both types of NICs.

Stack traces:

UBSAN: array-index-out-of-bounds in drivers/net/ethernet/broadcom/bnx2x/bnx2xstats.c:1529:11 index 20 is out of range for type 'statsquery_entry [19]' CPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic #202405052133 Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 ---truncated---(CVE-2024-42148)

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

USB: serial: mos7840: fix crash on resume

Since commit c49cfa917025 ("USB: serial: use generic method if no alternative is provided in usb serial layer"), USB serial core calls the generic resume implementation when the driver has not provided one.

This can trigger a crash on resume with mos7840 since support for multiple read URBs was added back in 2011. Specifically, both port read URBs are now submitted on resume for open ports, but the context pointer of the second URB is left set to the core rather than mos7840 port structure.

Fix this by implementing dedicated suspend and resume functions for mos7840.

Tested with Delock 87414 USB 2.0 to 4x serial adapter.

johan: analyse crash and rewrite commit message; set busy flag on resume; drop bulk-in check; drop unnecessary usbkillurb()

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

net, sunrpc: Remap EPERM in case of connection failure in xstcpsetup_socket

When using a BPF program on kernelconnect(), the call can return -EPERM. This causes xstcpsetupsocket() to loop forever, filling up the syslog and causing the kernel to potentially freeze up.

Neil suggested:

This will propagate -EPERM up into other layers which might not be ready to handle it. It might be safer to map EPERM to an error we would be more likely to expect from the network system - such as ECONNREFUSED or ENETDOWN.

ECONNREFUSED as error seems reasonable. For programs setting a different error can be out of reach (see handling in 4fbac77d2d09) in particular on kernels which do not have f10d05966196 ("bpf: Make BPFPROGRUNARRAY return -err instead of allow boolean"), thus given that it is better to simply remap for consistent behavior. UDP does handle EPERM in xsudpsendrequest().(CVE-2024-42246)

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

bpf: Fix a segment issue when downgrading gso_size

Linearize the skb when downgrading gsosize because it may trigger a BUGON() later when the skb is segmented as described in [1,2].(CVE-2024-42281)

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

scsi: qla2xxx: Fix for possible memory corruption

Init Control Block is dereferenced incorrectly. Correctly dereference ICB(CVE-2024-42288)

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

ext4: make sure the first directory block is not a hole

The syzbot constructs a directory that has no dirblock but is non-inline, i.e. the first directory block is a hole. And no errors are reported when creating files in this directory in the following flow.

ext4_mknod
 ...
  ext4_add_entry
    // Read block 0
    ext4_read_dirblock(dir, block, DIRENT)
      bh = ext4_bread(NULL, inode, block, 0)
      if (!bh && (type == INDEX || type == DIRENT_HTREE))
      // The first directory block is a hole
      // But type == DIRENT, so no error is reported.

After that, we get a directory block without '.' and '..' but with a valid dentry. This may cause some code that relies on dot or dotdot (such as makeindexeddir()) to crash.

Therefore when ext4readdirblock() finds that the first directory block is a hole report that the filesystem is corrupted and return an error to avoid loading corrupted data from disk causing something bad.(CVE-2024-42304)

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

drm/gma500: fix null pointer dereference in cdvintellvdsgetmodes

In cdvintellvdsgetmodes(), the return value of drmmodeduplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drmmodeduplicate(). Add a check to avoid npd.(CVE-2024-42310)

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

landlock: Don't lose track of restrictions on cred_transfer

When a process' cred struct is replaced, this almost always invokes the credprepare LSM hook; but in one special case (when KEYCTLSESSIONTOPARENT updates the parent's credentials), the credtransfer LSM hook is used instead. Landlock only implements the credprepare hook, not credtransfer, so KEYCTLSESSIONTOPARENT causes all information on Landlock restrictions to be lost.

This basically means that a process with the ability to use the fork() and keyctl() syscalls can get rid of all Landlock restrictions on itself.

Fix it by adding a credtransfer hook that does the same thing as the existing credprepare hook. (Implemented by having hookcredprepare() call hookcredtransfer() so that the two functions are less likely to accidentally diverge in the future.)(CVE-2024-42318)

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

bna: adjust 'name' buf size of bnatcb and bnaccb structures

To have enough space to write all possible sprintf() args. Currently 'name' size is 16, but the first '%s' specifier may already need at least 16 characters, since 'bnad->netdev->name' is used there.

For '%d' specifiers, assume that they require: * 1 char for 'txid + txinfo->tcb[i]->id' sum, BNADMAXTXQPERTX is 8 * 2 chars for 'rxid + rxinfo->rxctrl[i].ccb->id', BNADMAXRXPPER_RX is 16

And replace sprintf with snprintf.

Detected using the static analysis tool - Svace.(CVE-2024-43839)

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

block: initialize integrity buffer to zero before writing it to media

Metadata added by biointegrityprep is using plain kmalloc, which leads to random kernel memory being written media. For PI metadata this is limited to the app tag that isn't used by kernel generated metadata, but for non-PI metadata the entire buffer leaks kernel memory.

Fix this by adding the _GFPZERO flag to allocations for writes.(CVE-2024-43854)

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

wifi: cfg80211: handle 2x996 RU allocation in cfg80211calculatebitrate_he()

Currently NL80211RATEINFOHERUALLOC2x996 is not handled in cfg80211calculatebitrate_he(), leading to below warning:

kernel: invalid HE MCS: bw:6, ru:6 kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211calculatebitrate_he+0x22b/0x270 [cfg80211]

Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth.(CVE-2024-43879)

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

netfilter: ctnetlink: use helper function to calculate expect ID

Delete expectation path is missing a call to the nfexpectget_id() helper function to calculate the expectation ID, otherwise LSB of the expectation object address is leaked to userspace.(CVE-2024-44944)

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

xhci: Fix Panther point NULL pointer deref at full-speed re-enumeration

re-enumerating full-speed devices after a failed address device command can trigger a NULL pointer dereference.

Full-speed devices may need to reconfigure the endpoint 0 Max Packet Size value during enumeration. Usb core calls usbep0reinit() in this case, which ends up calling xhciconfigureendpoint().

On Panther point xHC the xhciconfigureendpoint() function will additionally check and reserve bandwidth in software. Other hosts do this in hardware

If xHC address device command fails then a new xhcivirtdevice structure is allocated as part of re-enabling the slot, but the bandwidth table pointers are not set up properly here. This triggers the NULL pointer dereference the next time usbep0reinit() is called and xhciconfigureendpoint() tries to check and reserve bandwidth

[46710.713538] usb 3-1: new full-speed USB device number 5 using xhcihcd [46710.713699] usb 3-1: Device not responding to setup address. [46710.917684] usb 3-1: Device not responding to setup address. [46711.125536] usb 3-1: device not accepting address 5, error -71 [46711.125594] BUG: kernel NULL pointer dereference, address: 0000000000000008 [46711.125600] #PF: supervisor read access in kernel mode [46711.125603] #PF: errorcode(0x0000) - not-present page [46711.125606] PGD 0 P4D 0 [46711.125610] Oops: Oops: 0000 [#1] PREEMPT SMP PTI [46711.125615] CPU: 1 PID: 25760 Comm: kworker/1:2 Not tainted 6.10.32 #1 [46711.125620] Hardware name: Gigabyte Technology Co., Ltd. [46711.125623] Workqueue: usbhubwq hubevent [usbcore] [46711.125668] RIP: 0010:xhcireservebandwidth (drivers/usb/host/xhci.c

Fix this by making sure bandwidth table pointers are set up correctly after a failed address device command, and additionally by avoiding checking for bandwidth in cases like this where no actual endpoints are added or removed, i.e. only context for default control endpoint 0 is evaluated.(CVE-2024-45006)

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

KVM: arm64: Make ICC*SGI*EL1 undef in the absence of a vGICv3

On a system with a GICv3, if a guest hasn't been configured with GICv3 and that the host is not capable of GICv2 emulation, a write to any of the ICC*SGI*EL1 registers is trapped to EL2.

We therefore try to emulate the SGI access, only to hit a NULL pointer as no private interrupt is allocated (no GIC, remember?).

The obvious fix is to give the guest what it deserves, in the shape of a UNDEF exception.(CVE-2024-46707)

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

ice: Add netifdeviceattach/detach into PF reset flow

Ethtool callbacks can be executed while reset is in progress and try to access deleted resources, e.g. getting coalesce settings can result in a NULL pointer dereference seen below.

Reproduction steps: Once the driver is fully initialized, trigger reset: # echo 1 > /sys/class/net/<interface>/device/reset when reset is in progress try to get coalesce settings using ethtool: # ethtool -c <interface>

BUG: kernel NULL pointer dereference, address: 0000000000000020 PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 11 PID: 19713 Comm: ethtool Tainted: G S 6.10.0-rc7+ #7 RIP: 0010:icegetqcoalesce+0x2e/0xa0 [ice] RSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206 RAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000 R13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40 FS: 00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0 Call Trace: <TASK> icegetcoalesce+0x17/0x30 [ice] coalescepreparedata+0x61/0x80 ethnldefaultdoit+0xde/0x340 genlfamilyrcvmsgdoit+0xf2/0x150 genlrcvmsg+0x1b3/0x2c0 netlinkrcvskb+0x5b/0x110 genlrcv+0x28/0x40 netlinkunicast+0x19c/0x290 netlinksendmsg+0x222/0x490 _syssendto+0x1df/0x1f0 _x64syssendto+0x24/0x30 dosyscall64+0x82/0x160 entrySYSCALL64after_hwframe+0x76/0x7e RIP: 0033:0x7faee60d8e27

Calling netifdevicedetach() before reset makes the net core not call the driver when ethtool command is issued, the attempt to execute an ethtool command during reset will result in the following message:

netlink error: No such device

instead of NULL pointer dereference. Once reset is done and icerebuild() is executing, the netifdevice_attach() is called to allow for ethtool operations to occur again in a safe manner.(CVE-2024-46770)

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

sched: sch_cake: fix bulk flow accounting logic for host fairness

In sch_cake, we keep track of the count of active bulk flows per host, when running in dst/src host fairness mode, which is used as the round-robin weight when iterating through flows. The count of active bulk flows is updated whenever a flow changes state.

This has a peculiar interaction with the hash collision handling: when a hash collision occurs (after the set-associative hashing), the state of the hash bucket is simply updated to match the new packet that collided, and if host fairness is enabled, that also means assigning new per-host state to the flow. For this reason, the bulk flow counters of the host(s) assigned to the flow are decremented, before new state is assigned (and the counters, which may not belong to the same host anymore, are incremented again).

Back when this code was introduced, the host fairness mode was always enabled, so the decrement was unconditional. When the configuration flags were introduced the increment was made conditional, but the decrement was not. Which of course can lead to a spurious decrement (and associated wrap-around to U16_MAX).

AFAICT, when host fairness is disabled, the decrement and wrap-around happens as soon as a hash collision occurs (which is not that common in itself, due to the set-associative hashing). However, in most cases this is harmless, as the value is only used when host fairness mode is enabled. So in order to trigger an array overflow, sch_cake has to first be configured with host fairness disabled, and while running in this mode, a hash collision has to occur to cause the overflow. Then, the qdisc has to be reconfigured to enable host fairness, which leads to the array out-of-bounds because the wrapped-around value is retained and used as an array index. It seems that syzbot managed to trigger this, which is quite impressive in its own right.

This patch fixes the issue by introducing the same conditional check on decrement as is used on increment.

The original bug predates the upstreaming of cake, but the commit listed in the Fixes tag touched that code, meaning that this patch won't apply before that.(CVE-2024-46828)

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

perf/x86/intel: Limit the period on Haswell

Running the ltp test cve-2015-3290 concurrently reports the following warnings.

perfevents: irq loop stuck! WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174 intelpmuhandleirq+0x285/0x370 Call Trace: <NMI> ? _warn+0xa4/0x220 ? intelpmuhandleirq+0x285/0x370 ? _reportbug+0x123/0x130 ? intelpmuhandleirq+0x285/0x370 ? _reportbug+0x123/0x130 ? intelpmuhandleirq+0x285/0x370 ? reportbug+0x3e/0xa0 ? handlebug+0x3c/0x70 ? excinvalidop+0x18/0x50 ? asmexcinvalidop+0x1a/0x20 ? irqworkclaim+0x1e/0x40 ? intelpmuhandleirq+0x285/0x370 perfeventnmihandler+0x3d/0x60 nmi_handle+0x104/0x330

Thanks to Thomas Gleixner's analysis, the issue is caused by the low initial period (1) of the frequency estimation algorithm, which triggers the defects of the HW, specifically erratum HSW11 and HSW143. (For the details, please refer https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/)

The HSW11 requires a period larger than 100 for the INST_RETIRED.ALL event, but the initial period in the freq mode is 1. The erratum is the same as the BDM11, which has been supported in the kernel. A minimum period of 128 is enforced as well on HSW.

HSW143 is regarding that the fixed counter 1 may overcount 32 with the Hyper-Threading is enabled. However, based on the test, the hardware has more issues than it tells. Besides the fixed counter 1, the message 'interrupt took too long' can be observed on any counter which was armed with a period < 32 and two events expired in the same NMI. A minimum period of 32 is enforced for the rest of the events. The recommended workaround code of the HSW143 is not implemented. Because it only addresses the issue for the fixed counter. It brings extra overhead through extra MSR writing. No related overcounting issue has been reported so far.(CVE-2024-46848)

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

ocfs2: add bounds checking to ocfs2xattrfind_entry()

Add a paranoia check to make sure it doesn't stray beyond valid memory region containing ocfs2 xattr entries when scanning for a match. It will prevent out-of-bound access in case of crafted images.(CVE-2024-47670)

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

wifi: ath9khtc: Use _skbsetlength() for resetting urb before resubmit

Syzbot points out that skbtrim() has a sanity check on the existing length of the skb, which can be uninitialised in some error paths. The intent here is clearly just to reset the length to zero before resubmitting, so switch to calling _skbsetlength(skb, 0) directly. In addition, _skbsetlength() already contains a call to skbresettailpointer(), so remove the redundant call.

The syzbot report came from ath9khifusbregincb(), but there's a similar usage of skbtrim() in ath9khifusbrxcb(), change both while we're at it.(CVE-2024-49938)

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

sctp: set skstate back to CLOSED if autobind fails in sctplisten_start

In sctplistenstart() invoked by sctpinetlisten(), it should set the skstate back to CLOSED if sctpautobind() fails due to whatever reason.

Otherwise, next time when calling sctpinetlisten(), if sctpsk(sk)->reuse is already set via setsockopt(SCTPREUSEPORT), sctpsk(sk)->bindhash will be dereferenced as skstate is LISTENING, which causes a crash as bind_hash is NULL.

KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctpinetlisten+0x7f0/0xa20 net/sctp/socket.c:8617 Call Trace: <TASK> _syslistensocket net/socket.c:1883 [inline] _syslisten+0x1b7/0x230 net/socket.c:1894 _dosyslisten net/socket.c:1902 inline

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

netfilter: nftables: prevent nfskb_duplicated corruption

syzbot found that nfdupipv4() or nfdupipv6() could write per-cpu variable nfskbduplicated in an unsafe way [1].

Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well.

[1] BUG: using thiscpuwrite() in preemptible [00000000] code: syz.4.282/6316 caller is nfdupipv4+0x651/0x8f0 net/ipv4/netfilter/nfdupipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: <TASK> _dumpstack lib/dumpstack.c:93 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:119 checkpreemptiondisabled+0x10e/0x120 lib/smpprocessorid.c:49 nfdupipv4+0x651/0x8f0 net/ipv4/netfilter/nfdupipv4.c:87 nftdupipv4eval+0x1db/0x300 net/ipv4/netfilter/nftdupipv4.c:30 exprcallopseval net/netfilter/nftablescore.c:240 [inline] nftdochain+0x4ad/0x1da0 net/netfilter/nftablescore.c:288 nftdochainipv4+0x202/0x320 net/netfilter/nftchainfilter.c:23 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xc3/0x220 net/netfilter/core.c:626 nfhook+0x2c4/0x450 include/linux/netfilter.h:269 NFHOOKCOND include/linux/netfilter.h:302 [inline] ipoutput+0x185/0x230 net/ipv4/ipoutput.c:433 iplocalout net/ipv4/ipoutput.c:129 [inline] ipsendskb+0x74/0x100 net/ipv4/ipoutput.c:1495 udpsendskb+0xacf/0x1650 net/ipv4/udp.c:981 udpsendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg+0x1a6/0x270 net/socket.c:745 syssendmsg+0x525/0x7d0 net/socket.c:2597 _syssendmsg net/socket.c:2651 [inline] _syssendmmsg+0x3b2/0x740 net/socket.c:2737 _dosyssendmmsg net/socket.c:2766 [inline] _sesyssendmmsg net/socket.c:2763 [inline] _x64syssendmmsg+0xa0/0xb0 net/socket.c:2763 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f4ce4f7def9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIGRAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68 </TASK>(CVE-2024-49952)

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

jbd2: stop waiting for space when jbd2cleanupjournal_tail() returns error

In _jbd2logwaitforspace(), we might call jbd2cleanupjournaltail() to recover some journal space. But if an error occurs while executing jbd2cleanupjournaltail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if jcommitting_transaction is NULL (i.e., the tid is 0), we will get the following complain:

============================================ JBD2: I/O error when updating journal superblock for sdd-8. jbd2logwaitforspace: needed 256 blocks and only had 217 space available _jbd2logwaitforspace: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 _jbd2logwaitforspace+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:jbd2logwaitforspace+0x251/0x2e0 Call Trace: <TASK> addtransactioncredits+0x5d1/0x5e0 startthishandle+0x1ef/0x6a0 jbd2_journalstart+0x18b/0x340 ext4dirtyinode+0x5d/0xb0 _markinodedirty+0xe4/0x5d0 genericupdate_time+0x60/0x70

[...]

So only if jbd2cleanupjournal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways.

Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corrupt when updating journal superblock fails") to make jbd2cleanupjournal_tail return the correct error code.(CVE-2024-49959)

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

mailbox: bcm2835: Fix timeout during suspend mode

During noirq suspend phase the Raspberry Pi power driver suffer of firmware property timeouts. The reason is that the IRQ of the underlying BCM2835 mailbox is disabled and rpifirmwareproperty_list() will always run into a timeout [1].

Since the VideoCore side isn't consider as a wakeup source, set the IRQFNOSUSPEND flag for the mailbox IRQ in order to keep it enabled during suspend-resume cycle.

[1] PM: late suspend of devices complete after 1.754 msecs WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpifirmwarepropertylist+0x204/0x22c Firmware transaction 0x00028001 timeout Modules linked in: CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17 Hardware name: BCM2835 Call trace: unwindbacktrace from showstack+0x18/0x1c showstack from dumpstacklvl+0x34/0x44 dumpstacklvl from _warn+0x88/0xec _warn from warnslowpathfmt+0x7c/0xb0 warnslowpathfmt from rpifirmwarepropertylist+0x204/0x22c rpifirmwarepropertylist from rpifirmwareproperty+0x68/0x8c rpifirmwareproperty from rpifirmwaresetpower+0x54/0xc0 rpifirmwaresetpower from genpdpoweroff+0xe4/0x148 _genpdpoweroff from genpdsyncpoweroff+0x7c/0x11c genpdsyncpoweroff from genpdfinishsuspend+0xcc/0xe0 genpdfinishsuspend from dpmruncallback+0x78/0xd0 dpmruncallback from devicesuspendnoirq+0xc0/0x238 devicesuspendnoirq from dpmsuspendnoirq+0xb0/0x168 dpmsuspendnoirq from suspenddevicesandenter+0x1b8/0x5ac suspenddevicesandenter from pmsuspend+0x254/0x2e4 pmsuspend from statestore+0xa8/0xd4 statestore from kernfsfopwriteiter+0x154/0x1a0 kernfsfopwriteiter from vfswrite+0x12c/0x184 vfswrite from ksyswrite+0x78/0xc0 ksyswrite from retfast_syscall+0x0/0x54 Exception stack(0xcc93dfa8 to 0xcc93dff0) [...] PM: noirq suspend of devices complete after 3095.584 msecs(CVE-2024-49963)

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

tty: ngsm: Fix use-after-free in gsmcleanup_mux

BUG: KASAN: slab-use-after-free in gsmcleanupmux+0x77b/0x7b0 drivers/tty/ngsm.c:3160 [ngsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: <TASK> gsmcleanupmux+0x77b/0x7b0 drivers/tty/ngsm.c:3160 [ngsm] _pfxgsmcleanupmux+0x10/0x10 drivers/tty/ngsm.c:3124 [ngsm] _pfxschedclockcpu+0x10/0x10 kernel/sched/clock.c:389 updateloadavg+0x1c1/0x27b0 kernel/sched/fair.c:4500 _pfxminvruntimecbrotate+0x10/0x10 kernel/sched/fair.c:846 _rbinsertaugmented+0x492/0xbf0 lib/rbtree.c:161 gsmldioctl+0x395/0x1450 drivers/tty/ngsm.c:3408 [ngsm] _rawspinlockirqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 _pfxgsmldioctl+0x10/0x10 drivers/tty/ngsm.c:3822 [ngsm] ktimeget+0x5e/0x140 kernel/time/timekeeping.c:195 ldsemdownread+0x94/0x4e0 arch/x86/include/asm/atomic6464.h:79 _pfxldsemdownread+0x10/0x10 drivers/tty/ttyldsem.c:338 _pfxdovfsioctl+0x10/0x10 fs/ioctl.c:805 ttyioctl+0x643/0x1100 drivers/tty/ttyio.c:2818

Allocated by task 65: gsmdataalloc.constprop.0+0x27/0x190 drivers/tty/ngsm.c:926 [ngsm] gsmsend+0x2c/0x580 drivers/tty/ngsm.c:819 [ngsm] gsm1receive+0x547/0xad0 drivers/tty/ngsm.c:3038 [ngsm] gsmldreceivebuf+0x176/0x280 drivers/tty/ngsm.c:3609 [ngsm] ttyldiscreceivebuf+0x101/0x1e0 drivers/tty/ttybuffer.c:391 ttyportdefaultreceivebuf+0x61/0xa0 drivers/tty/ttyport.c:39 flushtoldisc+0x1b0/0x750 drivers/tty/ttybuffer.c:445 processscheduledworks+0x2b0/0x10d0 kernel/workqueue.c:3229 workerthread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 retfromfork+0x2d/0x70 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry_64.S:257

Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsmcleanupmux+0x36c/0x7b0 drivers/tty/ngsm.c:3160 [ngsm] gsmldioctl+0x395/0x1450 drivers/tty/ngsm.c:3408 [ngsm] ttyioctl+0x643/0x1100 drivers/tty/tty_io.c:2818

[Analysis] gsmmsg on the txctrllist or txdatalist of gsmmux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock.(CVE-2024-50073)

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

LoongArch: Don't crash in stack_top() for tasks without vDSO

Not all tasks have a vDSO mapped, for example kthreads never do. If such a task ever ends up calling stack_top(), it will derefence the NULL vdso pointer and crash.

This can for example happen when using kunit:

[<9000000000203874>] stack_top+0x58/0xa8
[<90000000002956cc>] arch_pick_mmap_layout+0x164/0x220
[<90000000003c284c>] kunit_vm_mmap_init+0x108/0x12c
[<90000000003c1fbc>] __kunit_add_resource+0x38/0x8c
[<90000000003c2704>] kunit_vm_mmap+0x88/0xc8
[<9000000000410b14>] usercopy_test_init+0xbc/0x25c
[<90000000003c1db4>] kunit_try_run_case+0x5c/0x184
[<90000000003c3d54>] kunit_generic_run_threadfn_adapter+0x24/0x48
[<900000000022e4bc>] kthread+0xc8/0xd4
[<9000000000200ce8>] ret_from_kernel_thread+0xc/0xa4(CVE-2024-50133)

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

xfrm: validate new SA's prefixlen using SA family when sel.family is unset

This expands the validation introduced in commit 07bf7908950a ("xfrm: Validate address prefix lengths in the xfrm selector.")

syzbot created an SA with usersa.sel.family = AFUNSPEC usersa.sel.prefixlens = 128 usersa.family = AF_INET

Because of the AFUNSPEC selector, verifynewsainfo doesn't put limits on prefixlen{s,d}. But then copyfromuserstate sets x->sel.family to usersa.family (AFINET). Do the same conversion in verifynewsainfo before validating prefixlen_{s,d}, since that's how prefixlen is going to be used later on.(CVE-2024-50142)

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

be2net: fix potential memory leak in be_xmit()

The bexmit() returns NETDEVTXOK without freeing skb in case of bexmitenqueue() fails, add devkfreeskbany() to fix it.(CVE-2024-50167)

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

net/sun382586: fix potential memory leak in sun382586sendpacket()

The sun382586sendpacket() returns NETDEVTXOK without freeing skb in case of skb->len being too long, add devkfree_skb() to fix it.(CVE-2024-50168)

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

netfilter: nftpayload: sanitize offset and length before calling skbchecksum()

If access to offset + length is larger than the skbuff length, then skbchecksum() triggers BUGON().

skbchecksum() internally subtracts the length parameter while iterating over skbuff, BUGON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.(CVE-2024-50251)

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:

bpf: Check validity of link->type in bpflinkshow_fdinfo()

If a newly-added link type doesn't invoke BPFLINKTYPE(), accessing bpflinktype_strs[link->type] may result in an out-of-bounds access.

To spot such missed invocations early in the future, checking the validity of link->type in bpflinkshow_fdinfo() and emitting a warning when such invocations are missed.(CVE-2024-53099)

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

fs: Fix uninitialized value issue in fromkuid and fromkgid

ocfs2setattr() uses attr->iamode, attr->iauid and attr->iagid in a trace point even though ATTRMODE, ATTRUID and ATTR_GID aren't set.

Initialize all fields of newattrs to avoid uninitialized variables, by checking if ATTRMODE, ATTRUID, ATTR_GID are initialized, otherwise 0.(CVE-2024-53101)

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/hns: Fix NULL pointer derefernce in hnsrocemapmrsg()

ibmapmrsg() allows ULPs to specify NULL as the sgoffset argument. The driver needs to check whether it is a NULL pointer before dereferencing it.(CVE-2024-53226)

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)