OESA-2025-1286

IORINGOPREAD did not correctly consume the provided buffer list when read i/o returned < 0 (except for -EAGAIN and -EIOCBQUEUED return). This can lead to a potential use-after-free when the completion via iorwdone runs at separate context.(CVE-2023-52926)

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

f2fs: fix to shrink read extent node in batches

We use rwlock to protect core structure data of extent tree during its shrink, however, if there is a huge number of extent nodes in extent tree, during shrink of extent tree, it may hold rwlock for a very long time, which may trigger kernel hang issue.

This patch fixes to shrink read extent node in batches, so that, critical region of the rwlock can be shrunk to avoid its extreme long time hold.(CVE-2024-41935)

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

dma-debug: fix a possible deadlock on radix_lock

radixlock() shouldn't be held while holding dmahashentry[idx].lock otherwise, there's a possible deadlock scenario when dma debug API is called holding rqlock():

CPU0 CPU1 CPU2 dmafreeattrs() checkunmap() adddmaentry() _schedule() //out (A) rqlock() gethashbucket() (A) dmaentryhash checksync() (A) radixlock() (W) dmaentryhash dmaentryfree() (W) radixlock() // CPU2's one (W) rq_lock()

CPU1 situation can happen when it extending radix tree and it tries to wake up kswapd via wakeallkswapd().

CPU2 situation can happen while perfeventtaskschedout() (i.e. dma sync operation is called while deleting perf_event using etm and etr tmc which are Arm Coresight hwtracing driver backends).

To remove this possible situation, call dmaentryfree() after puthashbucket() in check_unmap().(CVE-2024-47143)

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

dlm: fix possible lkb_resource null dereference

This patch fixes a possible null pointer dereference when this function is called from requestlock() as lkb->lkbresource is not assigned yet, only after validatelockargs() by calling attach_lkb(). Another issue is that a resource name could be a non printable bytearray and we cannot assume to be ASCII coded.

The log functionality is probably never being hit when DLM is used in normal way and no debug logging is enabled. The null pointer dereference can only occur on a new created lkb that does not have the resource assigned yet, it probably never hits the null pointer dereference but we should be sure that other changes might not change this behaviour and we actually can hit the mentioned null pointer dereference.

In this patch we just drop the printout of the resource name, the lkb id is enough to make a possible connection to a resource name if this exists.(CVE-2024-47809)

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

bcache: revert replacing ISERRORNULL with ISERR again

Commit 028ddcac477b ("bcache: Remove unnecessary NULL point check in node allocations") leads a NULL pointer deference in cachesetflush().

1721 if (!ISERRORNULL(c->root)) 1722 listadd(&c->root->list, &c->btree_cache);

>From the above code in cachesetflush(), if previous registration code fails before allocating c->root, it is possible c->root is NULL as what it is initialized. _bchbtreenodealloc() never returns NULL but c->root is possible to be NULL at above line 1721.

This patch replaces ISERR() by ISERRORNULL() to fix this.(CVE-2024-48881)

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

netfilter: ipset: add missing range check in bitmapipuadt

When tb[IPSETATTRIPTO] is not present but tb[IPSETATTRCIDR] exists, the values of ip and ipto are slightly swapped. Therefore, the range check for ip should be done later, but this part is missing and it seems that the vulnerability occurs.

So we should add missing range checks and remove unnecessary range checks.(CVE-2024-53141)

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

comedi: Flush partial mappings in error case

If some remappfnrange() calls succeeded before one failed, we still have buffer pages mapped into the userspace page tables when we drop the buffer reference with comedibufmap_put(bm). The userspace mappings are only cleaned up later in the mmap error path.

Fix it by explicitly flushing all mappings in our VMA on the error path.

See commit 79a61cc3fc04 ("mm: avoid leaving partial pfn mappings around in error case").(CVE-2024-53148)

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

wifi: ath9k: add range check for connrspepid in htcconnectservice()

I found the following bug in my fuzzer:

UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath9k/htchst.c:26:51 index 255 is out of range for type 'htcendpoint [22]' CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.11.0-rc6-dirty #14 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: events requestfirmwareworkfunc Call Trace: <TASK> dumpstacklvl+0x180/0x1b0 _ubsanhandleoutofbounds+0xd4/0x130 htcissuesend.constprop.0+0x20c/0x230 ? rawspinunlockirqrestore+0x3c/0x70 ath9kwmicmd+0x41d/0x610 ? markheldlocks+0x9f/0xe0 ...

Since this bug has been confirmed to be caused by insufficient verification of connrspepid, I think it would be appropriate to add a range check for connrspepid to htcconnectservice() to prevent the bug from occurring.(CVE-2024-53156)

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

smb: During unmount, ensure all cached dir instances drop their dentry

The unmount process (cifskillsb() calling closeallcached_dirs()) can race with various cached directory operations, which ultimately results in dentries not being dropped and these kernel BUGs:

BUG: Dentry ffff88814f37e358{i=1000000000080,n=/} still in use (2) [unmount of cifs cifs] VFS: Busy inodes after unmount of cifs (cifs) ------------[ cut here ]------------ kernel BUG at fs/super.c:661!

This happens when a cfid is in the process of being cleaned up when, and has been removed from the cfids->entries list, including:

Receiving a lease break from the server
Server reconnection triggers invalidateallcached_dirs(), which removes all the cfids from the list
The laundromat thread decides to expire an old cfid.

To solve these problems, dropping the dentry is done in queued work done in a newly-added cfidputwq workqueue, and closeallcached_dirs() flushes that workqueue after it drops all the dentries of which it's aware. This is a global workqueue (rather than scoped to a mount), but the queued work is minimal.

The final cleanup work for cleaning up a cfid is performed via work queued in the serverclosewq workqueue; this is done separate from dropping the dentries so that closeallcacheddirs() doesn't block on any server operations.

Both of these queued works expect to invoked with a cfid reference and a tcon reference to avoid those objects from being freed while the work is ongoing.

While we're here, add proper locking to closeallcached_dirs(), and locking around the freeing of cfid->dentry.(CVE-2024-53176)

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

smb: prevent use-after-free due to opencacheddir error paths

If opencacheddir() encounters an error parsing the lease from the server, the error handling may race with receiving a lease break, resulting in opencacheddir() freeing the cfid while the queued work is pending.

Update opencacheddir() to drop refs rather than directly freeing the cfid.

Have cacheddirleasebreak(), cfidslaundromatworker(), and invalidateallcacheddirs() clear haslease immediately while still holding cfids->cfidlistlock, and then use this to also simplify the reference counting in cfidslaundromatworker() and invalidateallcacheddirs().

Fixes this KASAN splat (which manually injects an error and lease break in opencacheddir()):

================================================================== BUG: KASAN: slab-use-after-free in smb2cachedlease_break+0x27/0xb0 Read of size 8 at addr ffff88811cc24c10 by task kworker/3:1/65

CPU: 3 UID: 0 PID: 65 Comm: kworker/3:1 Not tainted 6.12.0-rc6-g255cf264e6e5-dirty #87 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Workqueue: cifsiod smb2cachedleasebreak Call Trace: <TASK> dumpstacklvl+0x77/0xb0 printreport+0xce/0x660 kasanreport+0xd3/0x110 smb2cachedleasebreak+0x27/0xb0 processonework+0x50a/0xc50 workerthread+0x2ba/0x530 kthread+0x17c/0x1c0 retfromfork+0x34/0x60 retfromforkasm+0x1a/0x30 </TASK>

Allocated by task 2464: kasansavestack+0x33/0x60 kasansavetrack+0x14/0x30 _kasankmalloc+0xaa/0xb0 opencacheddir+0xa7d/0x1fb0 smb2querypathinfo+0x43c/0x6e0 cifsgetfattr+0x346/0xf10 cifsgetinodeinfo+0x157/0x210 cifsrevalidatedentryattr+0x2d1/0x460 cifsgetattr+0x173/0x470 vfsstatxpath+0x10f/0x160 vfsstatx+0xe9/0x150 vfsfstatat+0x5e/0xc0 _dosysnewfstatat+0x91/0xf0 dosyscall64+0x95/0x1a0 entrySYSCALL64after_hwframe+0x76/0x7e

Freed by task 2464: kasansavestack+0x33/0x60 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3b/0x60 _kasanslabfree+0x51/0x70 kfree+0x174/0x520 opencacheddir+0x97f/0x1fb0 smb2querypathinfo+0x43c/0x6e0 cifsgetfattr+0x346/0xf10 cifsgetinodeinfo+0x157/0x210 cifsrevalidatedentryattr+0x2d1/0x460 cifsgetattr+0x173/0x470 vfsstatxpath+0x10f/0x160 vfsstatx+0xe9/0x150 vfsfstatat+0x5e/0xc0 _dosysnewfstatat+0x91/0xf0 dosyscall64+0x95/0x1a0 entrySYSCALL64after_hwframe+0x76/0x7e

Last potentially related work creation: kasansavestack+0x33/0x60 _kasanrecordauxstack+0xad/0xc0 insertwork+0x32/0x100 _queuework+0x5c9/0x870 queueworkon+0x82/0x90 opencacheddir+0x1369/0x1fb0 smb2querypathinfo+0x43c/0x6e0 cifsgetfattr+0x346/0xf10 cifsgetinodeinfo+0x157/0x210 cifsrevalidatedentryattr+0x2d1/0x460 cifsgetattr+0x173/0x470 vfsstatxpath+0x10f/0x160 vfsstatx+0xe9/0x150 vfsfstatat+0x5e/0xc0 _dosysnewfstatat+0x91/0xf0 dosyscall64+0x95/0x1a0 entrySYSCALL64afterhwframe+0x76/0x7e

The buggy address belongs to the object at ffff88811cc24c00 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 16 bytes inside of freed 1024-byte region [ffff88811cc24c00, ffff88811cc25000)(CVE-2024-53177)

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

smb: Don't leak cfid when reconnect races with opencacheddir

opencacheddir() may either race with the tcon reconnection even before compoundsendrecv() or directly trigger a reconnection via SMB2openinit() or SMBqueryinfo_init().

The reconnection process invokes invalidateallcacheddirs() via cifsmarkopenfilesinvalid(), which removes all cfids from the cfids->entries list but doesn't drop a ref if haslease isn't true. This results in the currently-being-constructed cfid not being on the list, but still having a refcount of 2. It leaks if returned from opencacheddir().

Fix this by setting cfid->has_lease when the ref is actually taken; the cfid will not be used by other threads until it has a valid time.

Addresses these kmemleaks:

unreferenced object 0xffff8881090c4000 (size 1024): comm "bash", pid 1860, jiffies 4295126592 hex dump (first 32 bytes): 00 01 00 00 00 00 ad de 22 01 00 00 00 00 ad de ........"....... 00 ca 45 22 81 88 ff ff f8 dc 4f 04 81 88 ff ff ..E"......O..... backtrace (crc 6f58c20f): [<ffffffff8b895a1e>] _kmalloccachenoprof+0x2be/0x350 [<ffffffff8bda06e3>] opencacheddir+0x993/0x1fb0 [<ffffffff8bdaa750>] cifsreaddir+0x15a0/0x1d50 [<ffffffff8b9a853f>] iteratedir+0x28f/0x4b0 [<ffffffff8b9a9aed>] _x64sysgetdents64+0xfd/0x200 [<ffffffff8cf6da05>] dosyscall64+0x95/0x1a0 [<ffffffff8d00012f>] entrySYSCALL64afterhwframe+0x76/0x7e unreferenced object 0xffff8881044fdcf8 (size 8): comm "bash", pid 1860, jiffies 4295126592 hex dump (first 8 bytes): 00 cc cc cc cc cc cc cc ........ backtrace (crc 10c106a9): [<ffffffff8b89a3d3>] _kmallocnodetrackcallernoprof+0x363/0x480 [<ffffffff8b7d7256>] kstrdup+0x36/0x60 [<ffffffff8bda0700>] opencacheddir+0x9b0/0x1fb0 [<ffffffff8bdaa750>] cifsreaddir+0x15a0/0x1d50 [<ffffffff8b9a853f>] iteratedir+0x28f/0x4b0 [<ffffffff8b9a9aed>] _x64sysgetdents64+0xfd/0x200 [<ffffffff8cf6da05>] dosyscall64+0x95/0x1a0 [<ffffffff8d00012f>] entrySYSCALL64afterhwframe+0x76/0x7e

And addresses these BUG splats when unmounting the SMB filesystem:

BUG: Dentry ffff888140590ba0{i=1000000000080,n=/} still in use (2) [unmount of cifs cifs] WARNING: CPU: 3 PID: 3433 at fs/dcache.c:1536 umountcheck+0xd0/0x100 Modules linked in: CPU: 3 UID: 0 PID: 3433 Comm: bash Not tainted 6.12.0-rc4-g850925a8133c-dirty #49 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 RIP: 0010:umountcheck+0xd0/0x100 Code: 8d 7c 24 40 e8 31 5a f4 ff 49 8b 54 24 40 41 56 49 89 e9 45 89 e8 48 89 d9 41 57 48 89 de 48 c7 c7 80 e7 db ac e8 f0 72 9a ff <0f> 0b 58 31 c0 5a 5b 5d 41 5c 41 5d 41 5e 41 5f e9 2b e5 5d 01 41 RSP: 0018:ffff88811cc27978 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff888140590ba0 RCX: ffffffffaaf20bae RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881f6fb6f40 RBP: ffff8881462ec000 R08: 0000000000000001 R09: ffffed1023984ee3 R10: ffff88811cc2771f R11: 00000000016cfcc0 R12: ffff888134383e08 R13: 0000000000000002 R14: ffff8881462ec668 R15: ffffffffaceab4c0 FS: 00007f23bfa98740(0000) GS:ffff8881f6f80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556de4a6f808 CR3: 0000000123c80000 CR4: 0000000000350ef0 Call Trace: <TASK> dwalk+0x6a/0x530 shrinkdcacheforumount+0x6a/0x200 genericshutdownsuper+0x52/0x2a0 killanonsuper+0x22/0x40 cifskillsb+0x159/0x1e0 deactivatelockedsuper+0x66/0xe0 cleanupmnt+0x140/0x210 taskworkrun+0xfb/0x170 syscallexittousermode+0x29f/0x2b0 dosyscall64+0xa1/0x1a0 entrySYSCALL64after_hwframe+0x76/0x7e RIP: 0033:0x7f23bfb93ae7 Code: ff ff ff ff c3 66 0f 1f 44 00 00 48 8b 0d 11 93 0d 00 f7 d8 64 89 01 b8 ff ff ff ff eb bf 0f 1f 44 00 00 b8 50 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e9 92 0d 00 f7 d8 64 89 ---truncated---(CVE-2024-53178)

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

um: vector: Do not use drvdata in release

The drvdata is not available in release. Let's just use containerof() to get the vectordevice instance. Otherwise, removing a vector device will result in a crash:

RIP: 0033:vectordevicerelease+0xf/0x50 RSP: 00000000e187bc40 EFLAGS: 00010202 RAX: 0000000060028f61 RBX: 00000000600f1baf RCX: 00000000620074e0 RDX: 000000006220b9c0 RSI: 0000000060551c80 RDI: 0000000000000000 RBP: 00000000e187bc50 R08: 00000000603ad594 R09: 00000000e187bb70 R10: 000000000000135a R11: 00000000603ad422 R12: 00000000623ae028 R13: 000000006287a200 R14: 0000000062006d30 R15: 00000000623700b6 Kernel panic - not syncing: Segfault with no mm CPU: 0 UID: 0 PID: 16 Comm: kworker/0:1 Not tainted 6.12.0-rc6-g59b723cd2adb #1 Workqueue: events mcworkproc Stack: 60028f61 623ae028 e187bc80 60276fcd 6220b9c0 603f5820 623ae028 00000000 e187bcb0 603a2bcd 623ae000 62370010 Call Trace: [<60028f61>] ? vectordevicerelease+0x0/0x50 [<60276fcd>] devicerelease+0x70/0xba [<603a2bcd>] kobjectput+0xba/0xe7 [<60277265>] putdevice+0x19/0x1c [<60281266>] platformdeviceput+0x26/0x29 [<60281e5f>] platformdeviceunregister+0x2c/0x2e [<60029422>] vectorremove+0x52/0x58 [<60031316>] ? mconsolereply+0x0/0x50 [<600310c8>] mconsoleremove+0x160/0x1cc [<603b19f4>] ? strlen+0x0/0x15 [<60066611>] ? _dequeueentity+0x1a9/0x206 [<600666a7>] ? setnextentity+0x39/0x63 [<6006666e>] ? setnextentity+0x0/0x63 [<60038fa6>] ? umsetsignals+0x0/0x43 [<6003070c>] mcworkproc+0x77/0x91 [<60057664>] processscheduledworks+0x1b3/0x2dd [<60055f32>] ? assignwork+0x0/0x58 [<60057f0a>] workerthread+0x1e9/0x293 [<6005406f>] ? setpfworker+0x0/0x64 [<6005d65d>] ? archlocalirqsave+0x0/0x2d [<6005d748>] ? kthreadexit+0x0/0x3a [<60057d21>] ? workerthread+0x0/0x293 [<6005dbf1>] kthread+0x126/0x12b [<600219c5>] newthread_handler+0x85/0xb6(CVE-2024-53181)

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

smb: client: fix NULL ptr deref in cryptoaeadsetkey()

Neither SMB3.0 or SMB3.02 supports encryption negotiate context, so when SMB2GLOBALCAP_ENCRYPTION flag is set in the negotiate response, the client uses AES-128-CCM as the default cipher. See MS-SMB2 3.3.5.4.

Commit b0abcd65ec54 ("smb: client: fix UAF in async decryption") added a @server->ciphertype check to conditionally call smb3cryptoaeadallocate(), but that check would always be false as @server->cipher_type is unset for SMB3.02.

Fix the following KASAN splat by setting @server->cipher_type for SMB3.02 as well.

mount.cifs //srv/share /mnt -o vers=3.02,seal,...

BUG: KASAN: null-ptr-deref in cryptoaeadsetkey+0x2c/0x130 Read of size 8 at addr 0000000000000020 by task mount.cifs/1095 CPU: 1 UID: 0 PID: 1095 Comm: mount.cifs Not tainted 6.12.0 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x5d/0x80 ? cryptoaeadsetkey+0x2c/0x130 kasanreport+0xda/0x110 ? cryptoaeadsetkey+0x2c/0x130 cryptoaeadsetkey+0x2c/0x130 cryptmessage+0x258/0xec0 [cifs] ? asanmemset+0x23/0x50 ? _pfxcryptmessage+0x10/0x10 [cifs] ? marklock+0xb0/0x6a0 ? hlockclass+0x32/0xb0 ? marklock+0xb0/0x6a0 smb3inittransformrq+0x352/0x3f0 [cifs] ? lockacquire.part.0+0xf4/0x2a0 smbsendrqst+0x144/0x230 [cifs] ? _pfxsmbsendrqst+0x10/0x10 [cifs] ? hlockclass+0x32/0xb0 ? smb2setuprequest+0x225/0x3a0 [cifs] ? _pfxcifscompoundlastcallback+0x10/0x10 [cifs] compoundsendrecv+0x59b/0x1140 [cifs] ? _pfxcompoundsendrecv+0x10/0x10 [cifs] ? _createobject+0x5e/0x90 ? hlockclass+0x32/0xb0 ? dorawspinunlock+0x9a/0xf0 cifssendrecv+0x23/0x30 [cifs] SMB2tcon+0x3ec/0xb30 [cifs] ? _pfxSMB2tcon+0x10/0x10 [cifs] ? lockacquire.part.0+0xf4/0x2a0 ? _pfxlockrelease+0x10/0x10 ? dorawspintrylock+0xc6/0x120 ? lockacquire+0x3f/0x90 ? _getxid+0x16/0xd0 [cifs] ? _pfxSMB2tcon+0x10/0x10 [cifs] ? cifsgetsmbses+0xcdd/0x10a0 [cifs] cifsgetsmbses+0xcdd/0x10a0 [cifs] ? _pfxcifsgetsmbses+0x10/0x10 [cifs] ? cifsgettcpsession+0xaa0/0xca0 [cifs] cifsmountgetsession+0x8a/0x210 [cifs] dfsmountshare+0x1b0/0x11d0 [cifs] ? _pfxlockacquire+0x10/0x10 ? pfxdfsmountshare+0x10/0x10 [cifs] ? lockacquire.part.0+0xf4/0x2a0 ? findheldlock+0x8a/0xa0 ? hlockclass+0x32/0xb0 ? lockrelease+0x203/0x5d0 cifsmount+0xb3/0x3d0 [cifs] ? dorawspintrylock+0xc6/0x120 ? _pfxcifsmount+0x10/0x10 [cifs] ? lockacquire+0x3f/0x90 ? findnls+0x16/0xa0 ? smb3updatemntflags+0x372/0x3b0 [cifs] cifssmb3domount+0x1e2/0xc80 [cifs] ? _pfxvfsparsefsstring+0x10/0x10 ? _pfxcifssmb3domount+0x10/0x10 [cifs] smb3gettree+0x1bf/0x330 [cifs] vfsgettree+0x4a/0x160 pathmount+0x3c1/0xfb0 ? kasanquarantineput+0xc7/0x1d0 ? _pfxpathmount+0x10/0x10 ? kmemcachefree+0x118/0x3e0 ? userpathat+0x74/0xa0 _x64sysmount+0x1a6/0x1e0 ? _pfxx64sysmount+0x10/0x10 ? markheldlocks+0x1a/0x90 dosyscall64+0xbb/0x1d0 entrySYSCALL64after_hwframe+0x77/0x7f(CVE-2024-53185)

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

s390/iucv: MSGPEEK causes memory leak in iucvsock_destruct()

Passing MSGPEEK flag to skbrecvdatagram() increments skb refcount (skb->users) and iucvsockrecvmsg() does not decrement skb refcount at exit. This results in skb memory leak in skbqueuepurge() and WARNON in iucvsockdestruct() during socket close. To fix this decrease skb refcount by one if MSGPEEK is set in order to prevent memory leak and WARNON.

WARNING: CPU: 2 PID: 6292 at net/iucv/afiucv.c:286 iucvsockdestruct+0x144/0x1a0 [afiucv] CPU: 2 PID: 6292 Comm: afiucvtestmsg Kdump: loaded Tainted: G W 6.10.0-rc7 #1 Hardware name: IBM 3931 A01 704 (z/VM 7.3.0) Call Trace: [<001587c682c4aa98>] iucvsockdestruct+0x148/0x1a0 [afiucv] [<001587c682c4a9d0>] iucvsockdestruct+0x80/0x1a0 [afiucv] [<001587c704117a32>] _skdestruct+0x52/0x550 [<001587c704104a54>] _sockrelease+0xa4/0x230 [<001587c704104c0c>] sockclose+0x2c/0x40 [<001587c702c5f5a8>] _fput+0x2e8/0x970 [<001587c7024148c4>] taskworkrun+0x1c4/0x2c0 [<001587c7023b0716>] doexit+0x996/0x1050 [<001587c7023b13aa>] dogroupexit+0x13a/0x360 [<001587c7023b1626>] _s390xsysexitgroup+0x56/0x60 [<001587c7022bccca>] dosyscall+0x27a/0x380 [<001587c7049a6a0c>] _dosyscall+0x9c/0x160 [<001587c7049ce8a8>] systemcall+0x70/0x98 Last Breaking-Event-Address: [<001587c682c4a9d4>] iucvsockdestruct+0x84/0x1a0 afiucv

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

vfio/pci: Properly hide first-in-list PCIe extended capability

There are cases where a PCIe extended capability should be hidden from the user. For example, an unknown capability (i.e., capability with ID greater than PCIEXTCAPIDMAX) or a capability that is intentionally chosen to be hidden from the user.

Hiding a capability is done by virtualizing and modifying the 'Next Capability Offset' field of the previous capability so it points to the capability after the one that should be hidden.

The special case where the first capability in the list should be hidden is handled differently because there is no previous capability that can be modified. In this case, the capability ID and version are zeroed while leaving the next pointer intact. This hides the capability and leaves an anchor for the rest of the capability list.

However, today, hiding the first capability in the list is not done properly if the capability is unknown, as struct vfiopcicoredevice->pciconfigmap is set to the capability ID during initialization but the capability ID is not properly checked later when used in vfioconfigdorw(). This leads to the following warning [1] and to an out-of-bounds access to ecap_perms array.

Fix it by checking capid in vfioconfigdorw(), and if it is greater than PCIEXTCAPIDMAX, use an alternative struct permbits for direct read only access instead of the ecapperms array.

Note that this is safe since the above is the only case where capid can exceed PCIEXTCAPID_MAX (except for the special capabilities, which are already checked before).

[1]

WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfiopciconfig.c:1900 vfiopciconfigrw+0x395/0x430 [vfiopcicore] CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1 (snip) Call Trace: <TASK> ? showregs+0x69/0x80 ? _warn+0x8d/0x140 ? vfiopciconfigrw+0x395/0x430 [vfiopcicore] ? reportbug+0x18f/0x1a0 ? handlebug+0x63/0xa0 ? excinvalidop+0x19/0x70 ? asmexcinvalidop+0x1b/0x20 ? vfiopciconfigrw+0x395/0x430 [vfiopcicore] ? vfiopciconfigrw+0x244/0x430 [vfiopcicore] vfiopcirw+0x101/0x1b0 [vfiopcicore] vfiopcicoreread+0x1d/0x30 [vfiopcicore] vfiodevicefopsread+0x27/0x40 [vfio] vfsread+0xbd/0x340 ? vfiodevicefopsunlioctl+0xbb/0x740 [vfio] ? _rseqhandlenotifyresume+0xa4/0x4b0 _x64syspread64+0x96/0xc0 x64syscall+0x1c3d/0x20d0 dosyscall64+0x4d/0x120 entrySYSCALL64after_hwframe+0x76/0x7e(CVE-2024-53214)

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

nfsd: release svcexpkey/svcexport with rcu_work

The last reference for cache_head can be reduced to zero in c_show and e_show(using rcu_read_lock and rcu_read_unlock). Consequently, svc_export_put and expkey_put will be invoked, leading to two issues:

The svc_export_put will directly free ex_uuid. However, e_show/c_show will access ex_uuid after cache_put, which can trigger a use-after-free issue, shown below.

================================================================== BUG: KASAN: slab-use-after-free in svcexportshow+0x362/0x430 [nfsd] Read of size 1 at addr ff11000010fdc120 by task cat/870

CPU: 1 UID: 0 PID: 870 Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x53/0x70 printaddressdescription.constprop.0+0x2c/0x3a0 printreport+0xb9/0x280 kasanreport+0xae/0xe0 svcexportshow+0x362/0x430 [nfsd] cshow+0x161/0x390 [sunrpc] seqreaditer+0x589/0x770 seqread+0x1e5/0x270 procregread+0xe1/0x140 vfsread+0x125/0x530 ksysread+0xc1/0x160 dosyscall64+0x5f/0x170 entrySYSCALL64afterhwframe+0x76/0x7e

Allocated by task 830: kasansavestack+0x20/0x40 kasansavetrack+0x14/0x30 _kasankmalloc+0x8f/0xa0 _kmallocnodetrackcallernoprof+0x1bc/0x400 kmemdupnoprof+0x22/0x50 svcexportparse+0x8a9/0xb80 [nfsd] cachedodowncall+0x71/0xa0 [sunrpc] cachewriteprocfs+0x8e/0xd0 [sunrpc] procregwrite+0xe1/0x140 vfswrite+0x1a5/0x6d0 ksyswrite+0xc1/0x160 dosyscall64+0x5f/0x170 entrySYSCALL64afterhwframe+0x76/0x7e

Freed by task 868: kasansavestack+0x20/0x40 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3b/0x60 _kasanslabfree+0x37/0x50 kfree+0xf3/0x3e0 svcexportput+0x87/0xb0 [nfsd] cachepurge+0x17f/0x1f0 [sunrpc] nfsddestroyserv+0x226/0x2d0 [nfsd] nfsdsvc+0x125/0x1e0 [nfsd] writethreads+0x16a/0x2a0 [nfsd] nfsctltransactionwrite+0x74/0xa0 [nfsd] vfswrite+0x1a5/0x6d0 ksyswrite+0xc1/0x160 dosyscall64+0x5f/0x170 entrySYSCALL64after_hwframe+0x76/0x7e
We cannot sleep while using rcu_read_lock/rcu_read_unlock. However, svc_export_put/expkey_put will call path_put, which subsequently triggers a sleeping operation due to the following dput.

============================= WARNING: suspicious RCU usage 5.10.0-dirty #141 Not tainted

... Call Trace: dumpstack+0x9a/0xd0 _mightsleep+0x231/0x240 dput+0x39/0x600 pathput+0x1b/0x30 svcexportput+0x17/0x80 eshow+0x1c9/0x200 seqreaditer+0x63f/0x7c0 seqread+0x226/0x2d0 vfsread+0x113/0x2c0 ksysread+0xc9/0x170 dosyscall64+0x33/0x40 entrySYSCALL64after_hwframe+0x67/0xd1

Fix these issues by using rcu_work to help release svc_expkey/svc_export. This approach allows for an asynchronous context to invoke path_put and also facilitates the freeing of uuid/exp/key after an RCU grace period.(CVE-2024-53216)

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

unicode: Fix utf8_load() error path

utf8load() requests the symbol "utf8datatable" and then checks if the requested UTF-8 version is supported. If it's unsupported, it tries to put the data table using symbolput(). If an unsupported version is requested, symbol_put() fails like this:

kernel BUG at kernel/module/main.c:786! RIP: 0010:_symbolput+0x93/0xb0 Call Trace: <TASK> ? _diebody.cold+0x19/0x27 ? die+0x2e/0x50 ? dotrap+0xca/0x110 ? doerrortrap+0x65/0x80 ? _symbolput+0x93/0xb0 ? excinvalidop+0x51/0x70 ? _symbolput+0x93/0xb0 ? asmexcinvalidop+0x1a/0x20 ? _pfxcmpname+0x10/0x10 ? _symbolput+0x93/0xb0 ? _symbolput+0x62/0xb0 utf8load+0xf8/0x150

That happens because symbol_put() expects the unique string that identify the symbol, instead of a pointer to the loaded symbol. Fix that by using such string.(CVE-2024-53233)

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

NFS: Fix potential buffer overflowin nfssysfslinkrpcclient()

name is char[64] where the size of clnt->cl_program->name remains unknown. Invoking strcat() directly will also lead to potential buffer overflow. Change them to strscpy() and strncat() to fix potential issues.(CVE-2024-54456)

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

ALSA: caiaq: Use sndcardfreewhenclosed() at disconnection

The USB disconnect callback is supposed to be short and not too-long waiting. OTOH, the current code uses sndcardfree() at disconnection, but this waits for the close of all used fds, hence it can take long. It eventually blocks the upper layer USB ioctls, which may trigger a soft lockup.

An easy workaround is to replace sndcardfree() with sndcardfreewhenclosed(). This variant returns immediately while the release of resources is done asynchronously by the card device release at the last close.

This patch also splits the code to the disconnect and the free phases; the former is called immediately at the USB disconnect callback while the latter is called from the card destructor.(CVE-2024-56531)

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

ALSA: usx2y: Use sndcardfreewhenclosed() at disconnection

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

wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiexconfigscan()

Replace one-element array with a flexible-array member in struct mwifiex_ie_types_wildcard_ssid_params to fix the following warning on a MT8173 Chromebook (mt8173-elm-hana):

[ 356.775250] ------------[ cut here ]------------ [ 356.784543] memcpy: detected field-spanning write (size 6) of single field "wildcardssidtlv->ssid" at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1) [ 356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiexscannetworks+0x4fc/0xf28 [mwifiex]

The "(size 6)" above is exactly the length of the SSID of the network this device was connected to. The source of the warning looks like:

ssid_len = user_scan_in-&gt;ssid_list[i].ssid_len;
[...]
memcpy(wildcard_ssid_tlv-&gt;ssid,
       user_scan_in-&gt;ssid_list[i].ssid, ssid_len);

There is a #define WILDCARDSSIDTLVMAXSIZE that uses sizeof() on this struct, but it already didn't account for the size of the one-element array, so it doesn't need to be changed.(CVE-2024-56539)

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

HID: hyperv: streamline driver probe to avoid devres issues

It was found that unloading 'hid_hyperv' module results in a devres complaint:

... hvvmbus: unregistering driver hidhyperv ------------[ cut here ]------------ WARNING: CPU: 2 PID: 3983 at drivers/base/devres.c:691 devresreleasegroup+0x1f2/0x2c0 ... Call Trace: <TASK> ? devresreleasegroup+0x1f2/0x2c0 ? _warn+0xd1/0x1c0 ? devresreleasegroup+0x1f2/0x2c0 ? reportbug+0x32a/0x3c0 ? handlebug+0x53/0xa0 ? excinvalidop+0x18/0x50 ? asmexcinvalidop+0x1a/0x20 ? devresreleasegroup+0x1f2/0x2c0 ? devresreleasegroup+0x90/0x2c0 ? rcuiswatching+0x15/0xb0 ? _pfxdevresreleasegroup+0x10/0x10 hiddeviceremove+0xf5/0x220 devicereleasedriverinternal+0x371/0x540 ? klistput+0xf3/0x170 busremovedevice+0x1f1/0x3f0 devicedel+0x33f/0x8c0 ? _pfxdevicedel+0x10/0x10 ? cleanupsrcustruct+0x337/0x500 hiddestroydevice+0xc8/0x130 mousevscremove+0xd2/0x1d0 [hidhyperv] devicereleasedriverinternal+0x371/0x540 driverdetach+0xc5/0x180 busremovedriver+0x11e/0x2a0 ? _mutexunlockslowpath+0x160/0x5e0 vmbusdriverunregister+0x62/0x2b0 [hvvmbus] ...

And the issue seems to be that the corresponding devres group is not allocated. Normally, devresopengroup() is called from _hiddeviceprobe() but Hyper-V HID driver overrides 'hiddev->driver' with 'mousevschiddriver' stub and basically re-implements _hiddeviceprobe() by calling hidparse() and hidhwstart() but not devresopengroup(). hiddeviceprobe() does not call _hiddeviceprobe() for it. Later, when the driver is removed, hiddeviceremove() calls devresrelease_group() as it doesn't check whether hdev->driver was initially overridden or not.

The issue seems to be related to the commit 62c68e7cee33 ("HID: ensure timely release of driver-allocated resources") but the commit itself seems to be correct.

Fix the issue by dropping the 'hiddev->driver' override and using hidregisterdriver()/hidunregisterdriver() instead. Alternatively, it would have been possible to rely on the default handling but HIDCONNECTDEFAULT implies HIDCONNECT_HIDRAW and it doesn't seem to work for mousevsc as-is.(CVE-2024-56545)

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

drm/amdgpu: fix usage slab after free

[ +0.000021] BUG: KASAN: slab-use-after-free in drmschedentityflush+0x6cb/0x7a0 [gpusched] [ +0.000027] Read of size 8 at addr ffff8881b8605f88 by task amdpciunplug/2147

[ +0.000023] CPU: 6 PID: 2147 Comm: amdpciunplug Not tainted 6.10.0+ #1 [ +0.000016] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020 [ +0.000016] Call Trace: [ +0.000008] <TASK> [ +0.000009] dumpstacklvl+0x76/0xa0 [ +0.000017] printreport+0xce/0x5f0 [ +0.000017] ? drmschedentityflush+0x6cb/0x7a0 [gpusched] [ +0.000019] ? srsoreturnthunk+0x5/0x5f [ +0.000015] ? kasancompletemodereportinfo+0x72/0x200 [ +0.000016] ? drmschedentityflush+0x6cb/0x7a0 [gpusched] [ +0.000019] kasanreport+0xbe/0x110 [ +0.000015] ? drmschedentityflush+0x6cb/0x7a0 [gpusched] [ +0.000023] _asanreportload8noabort+0x14/0x30 [ +0.000014] drmschedentityflush+0x6cb/0x7a0 [gpusched] [ +0.000020] ? srsoreturnthunk+0x5/0x5f [ +0.000013] ? _kasancheckwrite+0x14/0x30 [ +0.000016] ? _pfxdrmschedentityflush+0x10/0x10 [gpusched] [ +0.000020] ? srsoreturnthunk+0x5/0x5f [ +0.000013] ? _kasancheckwrite+0x14/0x30 [ +0.000013] ? srsoreturnthunk+0x5/0x5f [ +0.000013] ? enablework+0x124/0x220 [ +0.000015] ? _pfxenablework+0x10/0x10 [ +0.000013] ? srsoreturnthunk+0x5/0x5f [ +0.000014] ? freelargekmalloc+0x85/0xf0 [ +0.000016] drmschedentitydestroy+0x18/0x30 [gpusched] [ +0.000020] amdgpuvceswfini+0x55/0x170 [amdgpu] [ +0.000735] ? _kasancheckread+0x11/0x20 [ +0.000016] vcev40swfini+0x80/0x110 [amdgpu] [ +0.000726] amdgpudevicefinisw+0x331/0xfc0 [amdgpu] [ +0.000679] ? mutexunlock+0x80/0xe0 [ +0.000017] ? _pfxamdgpudevicefinisw+0x10/0x10 [amdgpu] [ +0.000662] ? srsoreturnthunk+0x5/0x5f [ +0.000014] ? _kasancheckwrite+0x14/0x30 [ +0.000013] ? srsoreturnthunk+0x5/0x5f [ +0.000013] ? mutexunlock+0x80/0xe0 [ +0.000016] amdgpudriverreleasekms+0x16/0x80 [amdgpu] [ +0.000663] drmminorrelease+0xc9/0x140 [drm] [ +0.000081] drmrelease+0x1fd/0x390 [drm] [ +0.000082] _fput+0x36c/0xad0 [ +0.000018] _fputsync+0x3c/0x50 [ +0.000014] _x64sysclose+0x7d/0xe0 [ +0.000014] x64syscall+0x1bc6/0x2680 [ +0.000014] dosyscall64+0x70/0x130 [ +0.000014] ? srsoreturnthunk+0x5/0x5f [ +0.000014] ? irqentryexittousermode+0x60/0x190 [ +0.000015] ? srsoreturnthunk+0x5/0x5f [ +0.000014] ? irqentryexit+0x43/0x50 [ +0.000012] ? srsoreturnthunk+0x5/0x5f [ +0.000013] ? excpagefault+0x7c/0x110 [ +0.000015] entrySYSCALL64afterhwframe+0x76/0x7e [ +0.000014] RIP: 0033:0x7ffff7b14f67 [ +0.000013] Code: ff e8 0d 16 02 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 73 ba f7 ff [ +0.000026] RSP: 002b:00007fffffffe378 EFLAGS: 00000246 ORIG_RAX: 0000000000000003 [ +0.000019] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffff7b14f67 [ +0.000014] RDX: 0000000000000000 RSI: 00007ffff7f6f47a RDI: 0000000000000003 [ +0.000014] RBP: 00007fffffffe3a0 R08: 0000555555569890 R09: 0000000000000000 [ +0.000014] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fffffffe5c8 [ +0.000013] R13: 00005555555552a9 R14: 0000555555557d48 R15: 00007ffff7ffd040 [ +0.000020] </TASK>

[ +0.000016] Allocated by task 383 on cpu 7 at 26.880319s: [ +0.000014] kasansavestack+0x28/0x60 [ +0.000008] kasansavetrack+0x18/0x70 [ +0.000007] kasansaveallocinfo+0x38/0x60 [ +0.000007] _kasankmalloc+0xc1/0xd0 [ +0.000007] kmalloctracenoprof+0x180/0x380 [ +0.000007] drmschedinit+0x411/0xec0 [gpusched] [ +0.000012] amdgpudeviceinit+0x695f/0xa610 [amdgpu] [ +0.000658] amdgpudriverloadkms+0x1a/0x120 [amdgpu] [ +0.000662] amdgpupci_p ---truncated---(CVE-2024-56551)

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

nfsd: make sure exp active before svcexportshow

The function e_show was called with protection from RCU. This only ensures that exp will not be freed. Therefore, the reference count for exp can drop to zero, which will trigger a refcount use-after-free warning when exp_get is called. To resolve this issue, use cache_get_rcu to ensure that exp remains active.

------------[ cut here ]------------ refcountt: addition on 0; use-after-free. WARNING: CPU: 3 PID: 819 at lib/refcount.c:25 refcountwarnsaturate+0xb1/0x120 CPU: 3 UID: 0 PID: 819 Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcountwarnsaturate+0xb1/0x120 ... Call Trace: <TASK> eshow+0x20b/0x230 [nfsd] seqreaditer+0x589/0x770 seqread+0x1e5/0x270 vfsread+0x125/0x530 ksysread+0xc1/0x160 dosyscall64+0x5f/0x170 entrySYSCALL64after_hwframe+0x76/0x7e(CVE-2024-56558)

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

mm/slub: Avoid list corruption when removing a slab from the full list

Boot with slub_debug=UFPZ.

If allocated object failed in allocconsistencychecks, all objects of the slab will be marked as used, and then the slab will be removed from the partial list.

When an object belonging to the slab got freed later, the remove_full() function is called. Because the slab is neither on the partial list nor on the full list, it eventually lead to a list corruption (actually a list poison being detected).

So we need to mark and isolate the slab page with metadata corruption, do not put it back in circulation.

Because the debug caches avoid all the fastpaths, reusing the frozen bit to mark slab page with metadata corruption seems to be fine.

[ 4277.385669] listdel corruption, ffffea00044b3e50->next is LISTPOISON1 (dead000000000100) [ 4277.387023] ------------[ cut here ]------------ [ 4277.387880] kernel BUG at lib/listdebug.c:56! [ 4277.388680] invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 4277.389562] CPU: 5 PID: 90 Comm: kworker/5:1 Kdump: loaded Tainted: G OE 6.6.1-1 #1 [ 4277.392113] Workqueue: xfs-inodegc/vda1 xfsinodegcworker [xfs] [ 4277.393551] RIP: 0010:listdelentryvalidorreport+0x7b/0xc0 [ 4277.394518] Code: 48 91 82 e8 37 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 28 49 91 82 e8 26 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 58 49 91 [ 4277.397292] RSP: 0018:ffffc90000333b38 EFLAGS: 00010082 [ 4277.398202] RAX: 000000000000004e RBX: ffffea00044b3e50 RCX: 0000000000000000 [ 4277.399340] RDX: 0000000000000002 RSI: ffffffff828f8715 RDI: 00000000ffffffff [ 4277.400545] RBP: ffffea00044b3e40 R08: 0000000000000000 R09: ffffc900003339f0 [ 4277.401710] R10: 0000000000000003 R11: ffffffff82d44088 R12: ffff888112cf9910 [ 4277.402887] R13: 0000000000000001 R14: 0000000000000001 R15: ffff8881000424c0 [ 4277.404049] FS: 0000000000000000(0000) GS:ffff88842fd40000(0000) knlGS:0000000000000000 [ 4277.405357] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4277.406389] CR2: 00007f2ad0b24000 CR3: 0000000102a3a006 CR4: 00000000007706e0 [ 4277.407589] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4277.408780] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 4277.410000] PKRU: 55555554 [ 4277.410645] Call Trace: [ 4277.411234] <TASK> [ 4277.411777] ? die+0x32/0x80 [ 4277.412439] ? dotrap+0xd6/0x100 [ 4277.413150] ? _listdelentryvalidorreport+0x7b/0xc0 [ 4277.414158] ? doerrortrap+0x6a/0x90 [ 4277.414948] ? _listdelentryvalidorreport+0x7b/0xc0 [ 4277.415915] ? excinvalidop+0x4c/0x60 [ 4277.416710] ? _listdelentryvalidorreport+0x7b/0xc0 [ 4277.417675] ? asmexcinvalidop+0x16/0x20 [ 4277.418482] ? _listdelentryvalidorreport+0x7b/0xc0 [ 4277.419466] ? _listdelentryvalidorreport+0x7b/0xc0 [ 4277.420410] freetopartiallist+0x515/0x5e0 [ 4277.421242] ? xfsiextremove+0x41a/0xa10 [xfs] [ 4277.422298] xfsiextremove+0x41a/0xa10 [xfs] [ 4277.423316] ? xfsinodegcworker+0xb4/0x1a0 [xfs] [ 4277.424383] xfsbmapdelextentdelay+0x4fe/0x7d0 [xfs] [ 4277.425490] _xfsbunmapi+0x50d/0x840 [xfs] [ 4277.426445] xfsitruncateextentsflags+0x13a/0x490 [xfs] [ 4277.427553] xfsinactivetruncate+0xa3/0x120 [xfs] [ 4277.428567] xfsinactive+0x22d/0x290 [xfs] [ 4277.429500] xfsinodegcworker+0xb4/0x1a0 [xfs] [ 4277.430479] processonework+0x171/0x340 [ 4277.431227] workerthread+0x277/0x390 [ 4277.431962] ? _pfxworkerthread+0x10/0x10 [ 4277.432752] kthread+0xf0/0x120 [ 4277.433382] ? _pfxkthread+0x10/0x10 [ 4277.434134] retfromfork+0x2d/0x50 [ 4277.434837] ? _pfxkthread+0x10/0x10 [ 4277.435566] retfromforkasm+0x1b/0x30 [ 4277.436280] </TASK>(CVE-2024-56566)

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

efi/libstub: Free correct pointer on failure

cmdline_ptr is an out parameter, which is not allocated by the function itself, and likely points into the caller's stack.

cmdline refers to the pool allocation that should be freed when cleaning up after a failure, so pass this instead to free_pool().(CVE-2024-56573)

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

media: ts2020: fix null-ptr-deref in ts2020_probe()

KASAN reported a null-ptr-deref issue when executing the following command:

# echo ts2020 0x20 > /sys/bus/i2c/devices/i2c-0/newdevice KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 53 UID: 0 PID: 970 Comm: systemd-udevd Not tainted 6.12.0-rc2+ #24 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) RIP: 0010:ts2020probe+0xad/0xe10 [ts2020] RSP: 0018:ffffc9000abbf598 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffffc0714809 RDX: 0000000000000002 RSI: ffff88811550be00 RDI: 0000000000000010 RBP: ffff888109868800 R08: 0000000000000001 R09: fffff52001577eb6 R10: 0000000000000000 R11: ffffc9000abbff50 R12: ffffffffc0714790 R13: 1ffff92001577eb8 R14: ffffffffc07190d0 R15: 0000000000000001 FS: 00007f95f13b98c0(0000) GS:ffff888149280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555d2634b000 CR3: 0000000152236000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ts2020probe+0xad/0xe10 [ts2020] i2cdeviceprobe+0x421/0xb40 reallyprobe+0x266/0x850 ...

The cause of the problem is that when using sysfs to dynamically register an i2c device, there is no platform data, but the probe process of ts2020 needs to use platform data, resulting in a null pointer being accessed.

Solve this problem by adding checks to platform data.(CVE-2024-56574)

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

media: i2c: tc358743: Fix crash in the probe error path when using polling

If an error occurs in the probe() function, we should remove the polling timer that was alarmed earlier, otherwise the timer is called with arguments that are already freed, which results in a crash.

------------[ cut here ]------------ WARNING: CPU: 3 PID: 0 at kernel/time/timer.c:1830 runtimers+0x244/0x268 Modules linked in: CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.11.0 #226 Hardware name: Diasom DS-RK3568-SOM-EVB (DT) pstate: 804000c9 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : _runtimers+0x244/0x268 lr : _runtimers+0x1d4/0x268 sp : ffffff80eff2baf0 x29: ffffff80eff2bb50 x28: 7fffffffffffffff x27: ffffff80eff2bb00 x26: ffffffc080f669c0 x25: ffffff80efef6bf0 x24: ffffff80eff2bb00 x23: 0000000000000000 x22: dead000000000122 x21: 0000000000000000 x20: ffffff80efef6b80 x19: ffffff80041c8bf8 x18: ffffffffffffffff x17: ffffffc06f146000 x16: ffffff80eff27dc0 x15: 000000000000003e x14: 0000000000000000 x13: 00000000000054da x12: 0000000000000000 x11: 00000000000639c0 x10: 000000000000000c x9 : 0000000000000009 x8 : ffffff80eff2cb40 x7 : ffffff80eff2cb40 x6 : ffffff8002bee480 x5 : ffffffc080cb2220 x4 : ffffffc080cb2150 x3 : 00000000000f4240 x2 : 0000000000000102 x1 : ffffff80eff2bb00 x0 : ffffff80041c8bf0 Call trace: _runtimers+0x244/0x268 timerexpireremote+0x50/0x68 tmigrhandleremote+0x388/0x39c runtimersoftirq+0x38/0x44 handlesoftirqs+0x138/0x298 _dosoftirq+0x14/0x20 dosoftirq+0x10/0x1c callonirqstack+0x24/0x4c dosoftirqownstack+0x1c/0x2c irqexitrcu+0x9c/0xcc el1interrupt+0x48/0xc0 el1h64irqhandler+0x18/0x24 el1h64irq+0x7c/0x80 defaultidlecall+0x34/0x68 doidle+0x23c/0x294 cpustartupentry+0x38/0x3c secondarystartkernel+0x128/0x160 _secondaryswitched+0xb8/0xbc ---[ end trace 0000000000000000 ]---(CVE-2024-56576)

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

media: mtk-jpeg: Fix null-ptr-deref during unload module

The workqueue should be destroyed in mtkjpegcore.c since commit 09aea13ecf6f ("media: mtk-jpeg: refactor some variables"), otherwise the below calltrace can be easily triggered.

[ 677.862514] Unable to handle kernel paging request at virtual address dfff800000000023 [ 677.863633] KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] ... [ 677.879654] CPU: 6 PID: 1071 Comm: modprobe Tainted: G O 6.8.12-mtk+gfa1a78e5d24b+ #17 ... [ 677.882838] pc : destroyworkqueue+0x3c/0x770 [ 677.883413] lr : mtkjpegdecdestroyworkqueue+0x70/0x88 [mtkjpegdechw] [ 677.884314] sp : ffff80008ad974f0 [ 677.884744] x29: ffff80008ad974f0 x28: ffff0000d7115580 x27: ffff0000dd691070 [ 677.885669] x26: ffff0000dd691408 x25: ffff8000844af3e0 x24: ffff80008ad97690 [ 677.886592] x23: ffff0000e051d400 x22: ffff0000dd691010 x21: dfff800000000000 [ 677.887515] x20: 0000000000000000 x19: 0000000000000000 x18: ffff800085397ac0 [ 677.888438] x17: 0000000000000000 x16: ffff8000801b87c8 x15: 1ffff000115b2e10 [ 677.889361] x14: 00000000f1f1f1f1 x13: 0000000000000000 x12: ffff7000115b2e4d [ 677.890285] x11: 1ffff000115b2e4c x10: ffff7000115b2e4c x9 : ffff80000aa43e90 [ 677.891208] x8 : 00008fffeea4d1b4 x7 : ffff80008ad97267 x6 : 0000000000000001 [ 677.892131] x5 : ffff80008ad97260 x4 : ffff7000115b2e4d x3 : 0000000000000000 [ 677.893054] x2 : 0000000000000023 x1 : dfff800000000000 x0 : 0000000000000118 [ 677.893977] Call trace: [ 677.894297] destroyworkqueue+0x3c/0x770 [ 677.894826] mtkjpegdecdestroyworkqueue+0x70/0x88 [mtkjpegdechw] [ 677.895677] devmactionrelease+0x50/0x90 [ 677.896211] releasenodes+0xe8/0x170 [ 677.896688] devresreleaseall+0xf8/0x178 [ 677.897219] deviceunbindcleanup+0x24/0x170 [ 677.897785] devicereleasedriverinternal+0x35c/0x480 [ 677.898461] devicereleasedriver+0x20/0x38 ... [ 677.912665] ---[ end trace 0000000000000000 ]---(CVE-2024-56577)

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

media: amphion: Set video drvdata before register video device

The video drvdata should be set before the video device is registered, otherwise video_drvdata() may return NULL in the open() file ops, and led to oops.(CVE-2024-56579)

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

leds: class: Protect brightnessshow() with ledcdev->led_access mutex

There is NULL pointer issue observed if from Process A where hid device being added which results in adding a ledcdev addition and later a another call to access of ledcdev attribute from Process B can result in NULL pointer issue.

Use mutex ledcdev->ledaccess to protect access to led->cdev and its attribute inside brightnessshow() and maxbrightness_show() and also update the comment for mutex that it should be used to protect the led class device fields.

Process A               Process B

kthread+0x114 workerthread+0x244 processscheduledworks+0x248 uhiddeviceaddworker+0x24 hidadddevice+0x120 deviceadd+0x268 busprobedevice+0x94 deviceinitialprobe+0x14 _deviceattach+0xfc busforeachdrv+0x10c _deviceattachdriver+0x14c driverprobedevice+0x3c _driverprobedevice+0xa0 reallyprobe+0x190 hiddeviceprobe+0x130 psprobe+0x990 psledregister+0x94 devmledclassdevregisterext+0x58 ledclassdevregisterext+0x1f8 devicecreatewithgroups+0x48 devicecreategroupsvargs+0xc8 deviceadd+0x244 kobjectuevent+0x14 kobjectueventenv[jt]+0x224 mutexunlock[jt]+0xc4 _mutexunlockslowpath+0xd4 wakeupq+0x70 trytowakeup[jt]+0x48c preemptschedulecommon+0x28 _schedule+0x628 _switchto+0x174 el0t64sync+0x1a8/0x1ac el0t64synchandler+0x68/0xbc el0svc+0x38/0x68 doel0svc+0x1c/0x28 el0svccommon+0x80/0xe0 invokesyscall+0x58/0x114 _arm64sysread+0x1c/0x2c ksysread+0x78/0xe8 vfsread+0x1e0/0x2c8 kernfsfopreaditer+0x68/0x1b4 seqreaditer+0x158/0x4ec kernfsseqshow+0x44/0x54 sysfskfseqshow+0xb4/0x130 devattrshow+0x38/0x74 brightnessshow+0x20/0x4c dualshock4ledget_brightness+0xc/0x74

[ 3313.874295][ T4013] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060 [ 3313.874301][ T4013] Mem abort info: [ 3313.874303][ T4013] ESR = 0x0000000096000006 [ 3313.874305][ T4013] EC = 0x25: DABT (current EL), IL = 32 bits [ 3313.874307][ T4013] SET = 0, FnV = 0 [ 3313.874309][ T4013] EA = 0, S1PTW = 0 [ 3313.874311][ T4013] FSC = 0x06: level 2 translation fault [ 3313.874313][ T4013] Data abort info: [ 3313.874314][ T4013] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000 [ 3313.874316][ T4013] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 3313.874318][ T4013] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 3313.874320][ T4013] user pgtable: 4k pages, 39-bit VAs, pgdp=00000008f2b0a000 ..

[ 3313.874332][ T4013] Dumping ftrace buffer: [ 3313.874334][ T4013] (ftrace buffer empty) .. .. [ dd3313.874639][ T4013] CPU: 6 PID: 4013 Comm: InputReader [ 3313.874648][ T4013] pc : dualshock4ledgetbrightness+0xc/0x74 [ 3313.874653][ T4013] lr : ledupdatebrightness+0x38/0x60 [ 3313.874656][ T4013] sp : ffffffc0b910bbd0 .. .. [ 3313.874685][ T4013] Call trace: [ 3313.874687][ T4013] dualshock4ledgetbrightness+0xc/0x74 [ 3313.874690][ T4013] brightnessshow+0x20/0x4c [ 3313.874692][ T4013] devattrshow+0x38/0x74 [ 3313.874696][ T4013] sysfskfseqshow+0xb4/0x130 [ 3313.874700][ T4013] kernfsseqshow+0x44/0x54 [ 3313.874703][ T4013] seqreaditer+0x158/0x4ec [ 3313.874705][ T4013] kernfsfopreaditer+0x68/0x1b4 [ 3313.874708][ T4013] vfsread+0x1e0/0x2c8 [ 3313.874711][ T4013] ksysread+0x78/0xe8 [ 3313.874714][ T4013] _arm64sysread+0x1c/0x2c [ 3313.874718][ T4013] invokesyscall+0x58/0x114 [ 3313.874721][ T4013] el0svccommon+0x80/0xe0 [ 3313.874724][ T4013] doel0svc+0x1c/0x28 [ 3313.874727][ T4013] el0svc+0x38/0x68 [ 3313.874730][ T4013] el0t64synchandler+0x68/0xbc [ 3313.874732][ T4013] el0t64_sync+0x1a8/0x1ac(CVE-2024-56587)

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

wifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmfsdiodsglist_rw()

This patch fixes a NULL pointer dereference bug in brcmfmac that occurs when a high 'sdsgentryalign' value applies (e.g. 512) and a lot of queued SKBs are sent from the pkt queue.

The problem is the number of entries in the pre-allocated sgtable, it is nents = max(rxglomsize, txglomsize) + max(rxglomsize, txglomsize) >> 4 + 1. Given the default [rt]xglomsize=32 it's actually 35 which is too small. Worst case, the pkt queue can end up with 64 SKBs. This occurs when a new SKB is added for each original SKB if tailroom isn't enough to hold tailpad. At least one sg entry is needed for each SKB. So, eventually the "skbqueuewalk loop" in brcmfsdiodsglistrw may run out of sg entries. This makes sgnext return NULL and this causes the oops.

The patch sets nents to max(rxglomsize, txglomsize) * 2 to be able handle the worst-case. Btw. this requires only 64-35=29 * 16 (or 20 if CONFIGNEEDSGDMALENGTH) = 464 additional bytes of memory.(CVE-2024-56593)

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

net: inet6: do not leave a dangling sk pointer in inet6_create()

sockinitdata() attaches the allocated sk pointer to the provided sock object. If inet6_create() fails later, the sk object is released, but the sock object retains the dangling sk pointer, which may cause use-after-free later.

Clear the sock sk pointer on error.(CVE-2024-56600)

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

net: inet: do not leave a dangling sk pointer in inet_create()

sockinitdata() attaches the allocated sk object to the provided sock object. If inet_create() fails later, the sk object is freed, but the sock object retains the dangling pointer, which may create use-after-free later.

Clear the sk pointer in the sock object on error.(CVE-2024-56601)

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

net: ieee802154: do not leave a dangling sk pointer in ieee802154_create()

sockinitdata() attaches the allocated sk object to the provided sock object. If ieee802154_create() fails later, the allocated sk object is freed, but the dangling pointer remains in the provided sock object, which may allow use-after-free.

Clear the sk pointer in the sock object on error.(CVE-2024-56602)

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

net: afcan: do not leave a dangling sk pointer in cancreate()

On error cancreate() frees the allocated sk object, but sockinit_data() has already attached it to the provided sock object. This will leave a dangling sk pointer in the sock object and may cause use-after-free later.(CVE-2024-56603)

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

afpacket: avoid erroring out after sockinitdata() in packetcreate()

After sockinitdata() the allocated sk object is attached to the provided sock object. On error, packet_create() frees the sk object leaving the dangling pointer in the sock object on return. Some other code may try to use this pointer and cause use-after-free.(CVE-2024-56606)

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

can: dev: cansettermination(): allow sleeping GPIOs

In commit 6e86a1543c37 ("can: dev: provide optional GPIO based termination support") GPIO based termination support was added.

For no particular reason that patch uses gpiodsetvalue() to set the GPIO. This leads to the following warning, if the systems uses a sleeping GPIO, i.e. behind an I2C port expander:

| WARNING: CPU: 0 PID: 379 at /drivers/gpio/gpiolib.c:3496 gpiodsetvalue+0x50/0x6c | CPU: 0 UID: 0 PID: 379 Comm: ip Not tainted 6.11.0-20241016-1 #1 823affae360cc91126e4d316d7a614a8bf86236c

Replace gpiodsetvalue() by gpiodsetvalue_cansleep() to allow the use of sleeping GPIOs.(CVE-2024-56625)

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

LoongArch: Add architecture specific hugepteclear()

When executing mm selftests run_vmtests.sh, there is such an error:

BUG: Bad page state in process uffd-unit-tests pfn:00000 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x0 flags: 0xffff0000002000(reserved|node=0|zone=0|lastcpupid=0xffff) raw: 00ffff0000002000 ffffbf0000000008 ffffbf0000000008 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: PAGEFLAGSCHECKATFREE flag(s) set Modules linked in: sndseqdummy sndseq sndseqdevice rfkill vfat fat virtioballoon efipstore virtionet pstore netfailover failover fuse nfnetlink virtioscsi virtiogpu virtiodmabuf dmmultipath efivarfs CPU: 2 UID: 0 PID: 1913 Comm: uffd-unit-tests Not tainted 6.12.0 #184 Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022 Stack : 900000047c8ac000 0000000000000000 9000000000223a7c 900000047c8ac000 900000047c8af690 900000047c8af698 0000000000000000 900000047c8af7d8 900000047c8af7d0 900000047c8af7d0 900000047c8af5b0 0000000000000001 0000000000000001 900000047c8af698 10b3c7d53da40d26 0000010000000000 0000000000000022 0000000fffffffff fffffffffe000000 ffff800000000000 000000000000002f 0000800000000000 000000017a6d4000 90000000028f8940 0000000000000000 0000000000000000 90000000025aa5e0 9000000002905000 0000000000000000 90000000028f8940 ffff800000000000 0000000000000000 0000000000000000 0000000000000000 9000000000223a94 000000012001839c 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ... Call Trace: [<9000000000223a94>] showstack+0x5c/0x180 [<9000000001c3fd64>] dumpstacklvl+0x6c/0xa0 [<900000000056aa08>] badpage+0x1a0/0x1f0 [<9000000000574978>] freeunreffolios+0xbf0/0xd20 [<90000000004e65cc>] foliosputrefs+0x1a4/0x2b8 [<9000000000599a0c>] freepagesandswapcache+0x164/0x260 [<9000000000547698>] tlbbatchpagesflush+0xa8/0x1c0 [<9000000000547f30>] tlbfinishmmu+0xa8/0x218 [<9000000000543cb8>] exitmmap+0x1a0/0x360 [<9000000000247658>] _mmput+0x78/0x200 [<900000000025583c>] doexit+0x43c/0xde8 [<9000000000256490>] dogroupexit+0x68/0x110 [<9000000000256554>] sysexitgroup+0x1c/0x20 [<9000000001c413b4>] dosyscall+0x94/0x130 [<90000000002216d8>] handlesyscall+0xb8/0x158 Disabling lock debugging due to kernel taint BUG: non-zero pgtables_bytes on freeing mm: -16384

On LoongArch system, invalid huge pte entry should be invalidptetable or a single PAGEHUGE bit rather than a zero value. And it should be the same with invalid pmd entry, since pmdnone() is called by function freepgdrange() and pmdnone() return 0 by hugepteclear(). So single PAGEHUGE bit is also treated as a valid pte table and freepterange() will be called in freepmdrange().

freepmdrange() pmd = pmdoffset(pud, addr); do { next = pmdaddrend(addr, end); if (pmdnoneorclearbad(pmd)) continue; freepte_range(tlb, pmd, addr); } while (pmd++, addr = next, addr != end);

Here invalidptetable is used for both invalid huge pte entry and pmd entry.(CVE-2024-56628)

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

geneve: do not assume mac header is set in genevexmitskb()

We should not assume mac header is set in output path.

Use skbethhdr() instead of eth_hdr() to fix the issue.

sysbot reported the following :

WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 skbmacheader include/linux/skbuff.h:3052 [inline] WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 ethhdr include/linux/ifether.h:24 [inline] WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 genevexmitskb drivers/net/geneve.c:898 [inline] WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 genevexmit+0x4c38/0x5730 drivers/net/geneve.c:1039 Modules linked in: CPU: 0 UID: 0 PID: 11635 Comm: syz.4.1423 Not tainted 6.12.0-syzkaller-10296-gaaf20f870da0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skbmacheader include/linux/skbuff.h:3052 [inline] RIP: 0010:ethhdr include/linux/ifether.h:24 [inline] RIP: 0010:genevexmitskb drivers/net/geneve.c:898 [inline] RIP: 0010:genevexmit+0x4c38/0x5730 drivers/net/geneve.c:1039 Code: 21 c6 02 e9 35 d4 ff ff e8 a5 48 4c fb 90 0f 0b 90 e9 fd f5 ff ff e8 97 48 4c fb 90 0f 0b 90 e9 d8 f5 ff ff e8 89 48 4c fb 90 <0f> 0b 90 e9 41 e4 ff ff e8 7b 48 4c fb 90 0f 0b 90 e9 cd e7 ff ff RSP: 0018:ffffc90003b2f870 EFLAGS: 00010283 RAX: 000000000000037a RBX: 000000000000ffff RCX: ffffc9000dc3d000 RDX: 0000000000080000 RSI: ffffffff86428417 RDI: 0000000000000003 RBP: ffffc90003b2f9f0 R08: 0000000000000003 R09: 000000000000ffff R10: 000000000000ffff R11: 0000000000000002 R12: ffff88806603c000 R13: 0000000000000000 R14: ffff8880685b2780 R15: 0000000000000e23 FS: 00007fdc2deed6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b30a1dff8 CR3: 0000000056b8c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> _netdevstartxmit include/linux/netdevice.h:5002 [inline] netdevstartxmit include/linux/netdevice.h:5011 [inline] _devdirectxmit+0x58a/0x720 net/core/dev.c:4490 devdirectxmit include/linux/netdevice.h:3181 [inline] packetxmit+0x1e4/0x360 net/packet/afpacket.c:285 packetsnd net/packet/afpacket.c:3146 [inline] packetsendmsg+0x2700/0x5660 net/packet/afpacket.c:3178 socksendmsgnosec net/socket.c:711 [inline] _socksendmsg net/socket.c:726 [inline] _syssendto+0x488/0x4f0 net/socket.c:2197 _dosyssendto net/socket.c:2204 [inline] _sesyssendto net/socket.c:2200 [inline] _x64syssendto+0xe0/0x1c0 net/socket.c:2200 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x250 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f(CVE-2024-56636)

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

netfilter: ipset: Hold module reference while requesting a module

User space may unload ipset.ko while it is itself requesting a set type backend module, leading to a kernel crash. The race condition may be provoked by inserting an mdelay() right after the nfnlunlock() call.(CVE-2024-56637)

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

dccp: Fix memory leak in dccpfeatchange_recv

If dccpfeatpushconfirm() fails after new value for SP feature was accepted without reconciliation ('entry == NULL' branch), memory allocated for that value with dccpfeatclonesp_val() is never freed.

Here is the kmemleak stack for this:

unreferenced object 0xffff88801d4ab488 (size 8): comm "syz-executor310", pid 1127, jiffies 4295085598 (age 41.666s) hex dump (first 8 bytes): 01 b4 4a 1d 80 88 ff ff ..J..... backtrace: [<00000000db7cabfe>] kmemdup+0x23/0x50 mm/util.c:128 [<0000000019b38405>] kmemdup include/linux/string.h:465 [inline] [<0000000019b38405>] dccpfeatclonespval net/dccp/feat.c:371 [inline] [<0000000019b38405>] dccpfeatclonespval net/dccp/feat.c:367 [inline] [<0000000019b38405>] dccpfeatchangerecv net/dccp/feat.c:1145 [inline] [<0000000019b38405>] dccpfeatparseoptions+0x1196/0x2180 net/dccp/feat.c:1416 [<00000000b1f6d94a>] dccpparseoptions+0xa2a/0x1260 net/dccp/options.c:125 [<0000000030d7b621>] dccprcvstateprocess+0x197/0x13d0 net/dccp/input.c:650 [<000000001f74c72e>] dccpv4dorcv+0xf9/0x1a0 net/dccp/ipv4.c:688 [<00000000a6c24128>] skbacklogrcv include/net/sock.h:1041 [inline] [<00000000a6c24128>] _releasesock+0x139/0x3b0 net/core/sock.c:2570 [<00000000cf1f3a53>] releasesock+0x54/0x1b0 net/core/sock.c:3111 [<000000008422fa23>] inetwaitforconnect net/ipv4/afinet.c:603 [inline] [<000000008422fa23>] _inetstreamconnect+0x5d0/0xf70 net/ipv4/afinet.c:696 [<0000000015b6f64d>] inetstreamconnect+0x53/0xa0 net/ipv4/afinet.c:735 [<0000000010122488>] _sysconnectfile+0x15c/0x1a0 net/socket.c:1865 [<00000000b4b70023>] _sysconnect+0x165/0x1a0 net/socket.c:1882 [<00000000f4cb3815>] _dosysconnect net/socket.c:1892 [inline] [<00000000f4cb3815>] _sesysconnect net/socket.c:1889 [inline] [<00000000f4cb3815>] _x64sysconnect+0x6e/0xb0 net/socket.c:1889 [<00000000e7b1e839>] dosyscall64+0x33/0x40 arch/x86/entry/common.c:46 [<0000000055e91434>] entrySYSCALL64afterhwframe+0x67/0xd1

Clean up the allocated memory in case of dccpfeatpush_confirm() failure and bail out with an error reset code.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2024-56643)

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

net/ipv6: release expired exception dst cached in socket

Dst objects get leaked in ip6negativeadvice() when this function is executed for an expired IPv6 route located in the exception table. There are several conditions that must be fulfilled for the leak to occur: * an ICMPv6 packet indicating a change of the MTU for the path is received, resulting in an exception dst being created * a TCP connection that uses the exception dst for routing packets must start timing out so that TCP begins retransmissions * after the exception dst expires, the FIB6 garbage collector must not run before TCP executes ip6negativeadvice() for the expired exception dst

When TCP executes ip6negativeadvice() for an exception dst that has expired and if no other socket holds a reference to the exception dst, the refcount of the exception dst is 2, which corresponds to the increment made by dstinit() and the increment made by the TCP socket for which the connection is timing out. The refcount made by the socket is never released. The refcount of the dst is decremented in skdstreset() but that decrement is counteracted by a dsthold() intentionally placed just before the skdstreset() in ip6negativeadvice(). After ip6negativeadvice() has finished, there is no other object tied to the dst. The socket lost its reference stored in skdstcache and the dst is no longer in the exception table. The exception dst becomes a leaked object.

As a result of this dst leak, an unbalanced refcount is reported for the loopback device of a net namespace being destroyed under kernels that do not contain e5f80fcf869a ("ipv6: give an IPv6 dev to blackholenetdev"): unregisternetdevice: waiting for lo to become free. Usage count = 2

Fix the dst leak by removing the dsthold() in ip6negativeadvice(). The patch that introduced the dsthold() in ip6negativeadvice() was 92f1655aa2b22 ("net: fix _dstnegativeadvice() race"). But 92f1655aa2b22 merely refactored the code with regards to the dst refcount so the issue was present even before 92f1655aa2b22. The bug was introduced in 54c1a859efd9f ("ipv6: Don't drop cache route entry unless timer actually expired.") where the expired cached route is deleted and the skdstcache member of the socket is set to NULL by calling dstnegative_advice() but the refcount belonging to the socket is left unbalanced.

The IPv4 version - ipv4negativeadvice() - is not affected by this bug. When the TCP connection times out ipv4negativeadvice() merely resets the skdstcache of the socket while decrementing the refcount of the exception dst.(CVE-2024-56644)

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

can: j1939: j1939sessionnew(): fix skb reference counting

Since j1939sessionskbqueue() does an extra skbget() for each new skb, do the same for the initial one in j1939sessionnew() to avoid refcount underflow.

mkl: clean up commit message

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

netfilter: xtables: fix LED ID check in ledtg_check()

Syzbot has reported the following BUG detected by KASAN:

BUG: KASAN: slab-out-of-bounds in strlen+0x58/0x70 Read of size 1 at addr ffff8881022da0c8 by task repro/5879 ... Call Trace: <TASK> dumpstacklvl+0x241/0x360 ? pfxdumpstacklvl+0x10/0x10 ? _pfxprintk+0x10/0x10 ? printk+0xd5/0x120 ? virtaddrvalid+0x183/0x530 ? _virtaddrvalid+0x183/0x530 printreport+0x169/0x550 ? _virtaddrvalid+0x183/0x530 ? _virtaddrvalid+0x183/0x530 ? _virtaddrvalid+0x45f/0x530 ? _physaddr+0xba/0x170 ? strlen+0x58/0x70 kasanreport+0x143/0x180 ? strlen+0x58/0x70 strlen+0x58/0x70 kstrdup+0x20/0x80 ledtgcheck+0x18b/0x3c0 xtchecktarget+0x3bb/0xa40 ? _pfxxtchecktarget+0x10/0x10 ? stackdepotsaveflags+0x6e4/0x830 ? nfttargetinit+0x174/0xc30 nfttargetinit+0x82d/0xc30 ? _pfxnfttargetinit+0x10/0x10 ? nftablesnewrule+0x1609/0x2980 ? nftablesnewrule+0x1609/0x2980 ? rcuiswatching+0x15/0xb0 ? nftablesnewrule+0x1609/0x2980 ? nftablesnewrule+0x1609/0x2980 ? _kmallocnoprof+0x21a/0x400 nftablesnewrule+0x1860/0x2980 ? _pfxnftablesnewrule+0x10/0x10 ? _nlaparse+0x40/0x60 nfnetlinkrcv+0x14e5/0x2ab0 ? _pfxvalidatechain+0x10/0x10 ? _pfxnfnetlinkrcv+0x10/0x10 ? _lockacquire+0x1384/0x2050 ? netlinkdelivertap+0x2e/0x1b0 ? _pfxlockrelease+0x10/0x10 ? netlinkdelivertap+0x2e/0x1b0 netlinkunicast+0x7f8/0x990 ? _pfxnetlinkunicast+0x10/0x10 ? _virtaddrvalid+0x183/0x530 ? _checkobjectsize+0x48e/0x900 netlinksendmsg+0x8e4/0xcb0 ? _pfxnetlinksendmsg+0x10/0x10 ? aasockmsgperm+0x91/0x160 ? _pfxnetlinksendmsg+0x10/0x10 _socksendmsg+0x223/0x270 syssendmsg+0x52a/0x7e0 ? pfxsyssendmsg+0x10/0x10 _syssendmsg+0x292/0x380 ? _pfxsyssendmsg+0x10/0x10 ? lockdephardirqsonprepare+0x43d/0x780 ? _pfxlockdephardirqsonprepare+0x10/0x10 ? excpagefault+0x590/0x8c0 ? dosyscall64+0xb6/0x230 dosyscall64+0xf3/0x230 entrySYSCALL64afterhwframe+0x77/0x7f ... </TASK>

Since an invalid (without '\0' byte at all) byte sequence may be passed from userspace, add an extra check to ensure that such a sequence is rejected as possible ID and so never passed to 'kstrdup()' and further.(CVE-2024-56650)

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

can: hi311x: hi3110canist(): fix potential use-after-free

The commit a22bd630cfff ("can: hi311x: do not report txerr and rxerr during bus-off") removed the reporting of rxerr and txerr even in case of correct operation (i. e. not bus-off).

The error count information added to the CAN frame after netif_rx() is a potential use after free, since there is no guarantee that the skb is in the same state. It might be freed or reused.

Fix the issue by postponing the netif_rx() call in case of txerr and rxerr reporting.(CVE-2024-56651)

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

powerpc/mm/fault: Fix kfence page fault reporting

copyfromkernelnofault() can be called when doing read of /proc/kcore. /proc/kcore can have some unmapped kfence objects which when read via copyfromkernelnofault() can cause page faults. Since *_nofault() functions define their own fixup table for handling fault, use that instead of asking kfence to handle such faults.

Hence we search the exception tables for the nip which generated the fault. If there is an entry then we let the fixup table handler handle the page fault by returning an error from within _dopagefault().

This can be easily triggered if someone tries to do dd from /proc/kcore. eg. dd if=/proc/kcore of=/dev/null bs=1M

Some example false negatives:

=============================== BUG: KFENCE: invalid read in copyfromkernelnofault+0x9c/0x1a0 Invalid read at 0xc0000000fdff0000: copyfromkernelnofault+0x9c/0x1a0 0xc00000000665f950 readkcoreiter+0x57c/0xa04 procregreaditer+0xe4/0x16c vfsread+0x320/0x3ec ksysread+0x90/0x154 systemcallexception+0x120/0x310 systemcallvectoredcommon+0x15c/0x2ec

BUG: KFENCE: use-after-free read in copyfromkernelnofault+0x9c/0x1a0 Use-after-free read at 0xc0000000fe050000 (in kfence-#2): copyfromkernelnofault+0x9c/0x1a0 0xc00000000665f950 readkcoreiter+0x57c/0xa04 procregreaditer+0xe4/0x16c vfsread+0x320/0x3ec ksysread+0x90/0x154 systemcallexception+0x120/0x310 systemcallvectoredcommon+0x15c/0x2ec(CVE-2024-56678)

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

PCI: endpoint: epf-mhi: Avoid NULL dereference if DT lacks 'mmio'

If platformgetresource_byname() fails and returns NULL because DT lacks an 'mmio' property for the MHI endpoint, dereferencing res->start will cause a NULL pointer access. Add a check to prevent it.

[kwilczynski: error message update per the review feedback] bhelgaas: commit log

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

9p/xen: fix release of IRQ

Kernel logs indicate an IRQ was double-freed.

Pass correct device ID during IRQ release.

Dominique: remove confusing variable reset to 0

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

octeontx2-pf: handle otx2mboxgetrsp errors in otx2dmac_flt.c

Add error pointer checks after calling otx2mboxget_rsp().(CVE-2024-56707)

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

mfd: intelsocpmic_bxtwc: Use IRQ domain for PMIC devices

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-56723)

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

mfd: intelsocpmic_bxtwc: Use IRQ domain for TMU device

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-56724)

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

octeontx2-pf: handle otx2mboxgetrsp errors in otx2dcbnl.c

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

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

octeontx2-pf: handle otx2mboxgetrsp errors in otx2flows.c

Adding error pointer check after calling otx2mboxget_rsp().(CVE-2024-56727)

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

fbdev: sh7760fb: Fix a possible memory leak in sh7760fballocmem()

When information such as info->screenbase is not ready, calling sh7760fbfreemem() does not release memory correctly. Call dmafree_coherent() instead.(CVE-2024-56746)

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

ipv6: release nexthop on device removal

The CI is hitting some aperiodic hangup at device removal time in the pmtu.sh self-test:

unregisternetdevice: waiting for vethA-R1 to become free. Usage count = 6 reftracker: vethA-R1@ffff888013df15d8 has 1/5 users at dstinit+0x84/0x4a0 dstalloc+0x97/0x150 ip6dstalloc+0x23/0x90 ip6rtpcpualloc+0x1e6/0x520 ip6polroute+0x56f/0x840 fib6rulelookup+0x334/0x630 ip6routeoutputflags+0x259/0x480 ip6dstlookuptail.constprop.0+0x5c2/0x940 ip6dstlookupflow+0x88/0x190 udptunnel6dstlookup+0x2a7/0x4c0 vxlanxmitone+0xbde/0x4a50 [vxlan] vxlanxmit+0x9ad/0xf20 [vxlan] devhardstartxmit+0x10e/0x360 _devqueuexmit+0xf95/0x18c0 arpsolicit+0x4a2/0xe00 neighprobe+0xaa/0xf0

While the first suspect is the dstcache, explicitly tracking the dst owing the last device reference via probes proved such dst is held by the nexthop in the originating fib6info.

Similar to commit f5b51fe804ec ("ipv6: route: purge exception on removal"), we need to explicitly release the originating fib info when disconnecting a to-be-removed device from a live ipv6 dst: move the fib6info cleanup into ip6dst_ifdown().

Tested running:

./pmtu.sh cleanupipv6exception

in a tight loop for more than 400 iterations with no spat, running an unpatched kernel I observed a splat every ~10 iterations.(CVE-2024-56751)

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

crypto: caam - Fix the pointer passed to caamqishutdown()

The type of the last parameter given to devmaddactionorreset() is "struct caamdrvprivate *", but in caamqishutdown(), it is casted to "struct device *".

Pass the correct parameter to devmaddactionorreset() so that the resources are released as expected.(CVE-2024-56754)

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

btrfs: add a sanity check for btrfs root in btrfssearchslot()

Syzbot reports a null-ptr-deref in btrfssearchslot().

The reproducer is using rescue=ibadroots, and the extent tree root is corrupted thus the extent tree is NULL.

When scrub tries to search the extent tree to gather the needed extent info, btrfssearchslot() doesn't check if the target root is NULL or not, resulting the null-ptr-deref.

Add sanity check for btrfs root before using it in btrfssearchslot().(CVE-2024-56774)

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

netfilter: nftsocket: remove WARNON_ONCE on maximum cgroup level

cgroup maximum depth is INTMAX by default, there is a cgroup toggle to restrict this maximum depth to a more reasonable value not to harm performance. Remove unnecessary WARNON_ONCE which is reachable from userspace.(CVE-2024-56783)

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

MIPS: Loongson64: DTS: Really fix PCIe port nodes for ls7a

Fix the dtc warnings:

arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: &apos;#interrupt-cells&apos; found, but node is not an interrupt provider
arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: &apos;#interrupt-cells&apos; found, but node is not an interrupt provider
arch/mips/boot/dts/loongson/loongson64g_4core_ls7a.dtb: Warning (interrupt_map): Failed prerequisite &apos;interrupt_provider&apos;

And a runtime warning introduced in commit 045b14ca5c36 ("of: WARN on deprecated #address-cells/#size-cells handling"):

WARNING: CPU: 0 PID: 1 at drivers/of/base.c:106 of_bus_n_addr_cells+0x9c/0xe0
Missing &apos;#address-cells&apos; in /bus@10000000/pci@1a000000/pci_bridge@9,0

The fix is similar to commit d89a415ff8d5 ("MIPS: Loongson64: DTS: Fix PCIe port nodes for ls7a"), which has fixed the issue for ls2k (despite its subject mentions ls7a).(CVE-2024-56785)

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

s390/entry: Mark IRQ entries to fix stack depot warnings

The stack depot filters out everything outside of the top interrupt context as an uninteresting or irrelevant part of the stack traces. This helps with stack trace de-duplication, avoiding an explosion of saved stack traces that share the same IRQ context code path but originate from different randomly interrupted points, eventually exhausting the stack depot.

Filtering uses inirqentrytext() to identify functions within the .irqentry.text and .softirqentry.text sections, which then become the last stack trace entries being saved.

While _dosoftirq() is placed into the .softirqentry.text section by common code, populating .irqentry.text is architecture-specific.

Currently, the .irqentry.text section on s390 is empty, which prevents stack depot filtering and de-duplication and could result in warnings like:

Stack depot reached limit capacity WARNING: CPU: 0 PID: 286113 at lib/stackdepot.c:252 depotallocstack+0x39a/0x3c8

with PREEMPT and KASAN enabled.

Fix this by moving the IO/EXT interrupt handlers from .kprobes.text into the .irqentry.text section and updating the kprobes blacklist to include the .irqentry.text section.

This is done only for asynchronous interrupts and explicitly not for program checks, which are synchronous and where the context beyond the program check is important to preserve. Despite machine checks being somewhat in between, they are extremely rare, and preserving context when possible is also of value.

SVCs and Restart Interrupts are not relevant, one being always at the boundary to user space and the other being a one-time thing.

IRQ entries filtering is also optionally used in ftrace function graph, where the same logic applies.(CVE-2024-57838)

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

drm/dp_mst: Fix resetting msg rx state after topology removal

If the MST topology is removed during the reception of an MST down reply or MST up request sideband message, the drmdpmsttopologymgr::upreqrecv/downreprecv states could be reset from one thread via drmdpmsttopologymgrsetmst(false), racing with the reading/parsing of the message from another thread via drmdpmsthandledownrep() or drmdpmsthandleupreq(). The race is possible since the reader/parser doesn't hold any lock while accessing the reception state. This in turn can lead to a memory corruption in the reader/parser as described by commit bd2fccac61b4 ("drm/dp_mst: Fix MST sideband message body length check").

Fix the above by resetting the message reception state if needed before reading/parsing a message. Another solution would be to hold the drmdpmsttopologymgr::lock for the whole duration of the message reception/parsing in drmdpmsthandledownrep() and drmdpmsthandleupreq(), however this would require a bigger change. Since the fix is also needed for stable, opting for the simpler solution in this patch.(CVE-2024-57876)

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

wifi: mac80211: fix mbss changed flags corruption on 32 bit systems

On 32-bit systems, the size of an unsigned long is 4 bytes, while a u64 is 8 bytes. Therefore, when using oreachsetbit(bit, &bits, sizeof(changed) * BITSPER_BYTE), the code is incorrectly searching for a bit in a 32-bit variable that is expected to be 64 bits in size, leading to incorrect bit finding.

Solution: Ensure that the size of the bits variable is correctly adjusted for each architecture.

Call Trace: ? showregs+0x54/0x58 ? _warn+0x6b/0xd4 ? ieee80211linkinfochangenotify+0xcc/0xd4 [mac80211] ? reportbug+0x113/0x150 ? excoverflow+0x30/0x30 ? handlebug+0x27/0x44 ? excinvalidop+0x18/0x50 ? handleexception+0xf6/0xf6 ? excoverflow+0x30/0x30 ? ieee80211linkinfochangenotify+0xcc/0xd4 [mac80211] ? excoverflow+0x30/0x30 ? ieee80211linkinfochangenotify+0xcc/0xd4 [mac80211] ? ieee80211meshwork+0xff/0x260 [mac80211] ? cfg80211wiphywork+0x72/0x98 [cfg80211] ? processonework+0xf1/0x1fc ? workerthread+0x2c0/0x3b4 ? kthread+0xc7/0xf0 ? moddelayedworkon+0x4c/0x4c ? kthreadcompleteandexit+0x14/0x14 ? retfromfork+0x24/0x38 ? kthreadcompleteandexit+0x14/0x14 ? retfromforkasm+0xf/0x14 ? entryINT80_32+0xf0/0xf0

restore no-op path for no changes

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

usb: xhci: Fix NULL pointer dereference on certain command aborts

If a command is queued to the final usable TRB of a ring segment, the enqueue pointer is advanced to the subsequent link TRB and no further. If the command is later aborted, when the abort completion is handled the dequeue pointer is advanced to the first TRB of the next segment.

If no further commands are queued, xhcihandlestoppedcmdring() sees the ring pointers unequal and assumes that there is a pending command, so it calls xhcimodcmdtimer() which crashes if curcmd was NULL.

Don't attempt timer setup if cur_cmd is NULL. The subsequent doorbell ring likely is unnecessary too, but it's harmless. Leave it alone.

This is probably Bug 219532, but no confirmation has been received.

The issue has been independently reproduced and confirmed fixed using a USB MCU programmed to NAK the Status stage of SET_ADDRESS forever. Everything continued working normally after several prevented crashes.(CVE-2024-57981)

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

ocfs2: handle a symlink read error correctly

Patch series "Convert ocfs2 to use folios".

Mark did a conversion of ocfs2 to use folios and sent it to me as a giant patch for review ;-)

So I've redone it as individual patches, and credited Mark for the patches where his code is substantially the same. It's not a bad way to do it; his patch had some bugs and my patches had some bugs. Hopefully all our bugs were different from each other. And hopefully Mark likes all the changes I made to his code!

This patch (of 23):

If we can't read the buffer, be sure to unlock the page before returning.(CVE-2024-58001)

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

bpf: bpflocalstorage: Always use bpfmemalloc in PREEMPT_RT

In PREEMPTRT, kmalloc(GFPATOMIC) is still not safe in non preemptible context. bpfmemalloc must be used in PREEMPTRT. This patch is to enforce bpfmemalloc in the bpflocalstorage when CONFIGPREEMPT_RT is enabled.

[ 35.118559] BUG: sleeping function called from invalid context at kernel/locking/spinlockrt.c:48 [ 35.118566] inatomic(): 1, irqsdisabled(): 0, nonblock: 0, pid: 1832, name: testprogs [ 35.118569] preemptcount: 1, expected: 0 [ 35.118571] RCU nest depth: 1, expected: 1 [ 35.118577] INFO: lockdep is turned off. ... [ 35.118647] mightresched+0x433/0x5b0 [ 35.118677] rtspinlock+0xc3/0x290 [ 35.118700] _slaballoc+0x72/0xc40 [ 35.118723] _kmallocnoprof+0x13f/0x4e0 [ 35.118732] bpfmapkzalloc+0xe5/0x220 [ 35.118740] bpfselemalloc+0x1d2/0x7b0 [ 35.118755] bpflocalstorageupdate+0x2fa/0x8b0 [ 35.118784] bpfskstoragegettracing+0x15a/0x1d0 [ 35.118791] bpfprog9a118d86fca78ebbtraceinetsocksetstate+0x44/0x66 [ 35.118795] bpftracerun3+0x222/0x400 [ 35.118820] _bpftraceinetsocksetstate+0x11/0x20 [ 35.118824] traceinetsocksetstate+0x112/0x130 [ 35.118830] inetskstatestore+0x41/0x90 [ 35.118836] tcpset_state+0x3b3/0x640

There is no need to adjust the gfpflags passing to the bpfmemcacheallocflags() which only honors the GFPKERNEL. The verifier has ensured GFP_KERNEL is passed only in sleepable context.

It has been an old issue since the first introduction of the bpflocalstorage ~5 years ago, so this patch targets the bpf-next.

bpfmemalloc is needed to solve it, so the Fixes tag is set to the commit when bpfmemalloc was first used in the bpflocalstorage.(CVE-2024-58070)

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

wifi: rtw89: fix race between cancelhwscan and hw_scan completion

The rtwdev->scanning flag isn't protected by mutex originally, so cancelhwscan can pass the condition, but suddenly hwscan completion unset the flag and calls ieee80211scancompleted() that will free local->hwscanreq. Then, cancelhw_scan raises null-ptr-deref and use-after-free. Fix it by moving the check condition to where protected by mutex.

KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f] CPU: 2 PID: 6922 Comm: kworker/2:2 Tainted: G OE Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB6WW (2.76 ) 09/10/2019 Workqueue: events cfg80211connwork [cfg80211] RIP: 0010:rtw89fwh2cscanoffloadbe+0xc33/0x13c3 [rtw89core] Code: 00 45 89 6c 24 1c 0f 85 23 01 00 00 48 8b 85 20 ff ff ff 48 8d RSP: 0018:ffff88811fd9f068 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: ffff88811fd9f258 RCX: 0000000000000001 RDX: 0000000000000011 RSI: 0000000000000001 RDI: 0000000000000089 RBP: ffff88811fd9f170 R08: 0000000000000000 R09: 0000000000000000 R10: ffff88811fd9f108 R11: 0000000000000000 R12: ffff88810e47f960 R13: 0000000000000000 R14: 000000000000ffff R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8881d6f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007531dfca55b0 CR3: 00000001be296004 CR4: 00000000001706e0 Call Trace: <TASK> ? showregs+0x61/0x73 ? diebody+0x20/0x73 ? dieaddr+0x4f/0x7b ? excgeneralprotection+0x191/0x1db ? asmexcgeneralprotection+0x27/0x30 ? rtw89fwh2cscanoffloadbe+0xc33/0x13c3 [rtw89core] ? rtw89fwh2cscanoffloadbe+0x458/0x13c3 [rtw89core] ? _pfxrtw89fwh2cscanoffloadbe+0x10/0x10 [rtw89core] ? dorawspinlock+0x75/0xdb ? _pfxdorawspinlock+0x10/0x10 rtw89hwscanoffload+0xb5e/0xbf7 [rtw89core] ? rawspinunlock+0xe/0x24 ? _mutexlock.constprop.0+0x40c/0x471 ? _pfxrtw89hwscanoffload+0x10/0x10 [rtw89core] ? _mutexlockslowpath+0x13/0x1f ? mutexlock+0xa2/0xdc ? _pfxmutexlock+0x10/0x10 rtw89hwscanabort+0x58/0xb7 [rtw89core] rtw89opscancelhwscan+0x120/0x13b [rtw89core] ieee80211scancancel+0x468/0x4d0 [mac80211] ieee80211prepconnection+0x858/0x899 [mac80211] ieee80211mgdauth+0xbea/0xdde [mac80211] ? _pfxieee80211mgdauth+0x10/0x10 [mac80211] ? cfg80211findelem+0x15/0x29 [cfg80211] ? isbss+0x1b7/0x1d7 [cfg80211] ieee80211auth+0x18/0x27 [mac80211] cfg80211mlmeauth+0x3bb/0x3e7 [cfg80211] cfg80211conndowork+0x410/0xb81 [cfg80211] ? _pfxcfg80211conndowork+0x10/0x10 [cfg80211] ? _kasancheckread+0x11/0x1f ? psigroupchange+0x8bc/0x944 ? _kasancheckwrite+0x14/0x22 ? mutexlock+0x8e/0xdc ? _pfxmutexlock+0x10/0x10 ? _pfxradixtreelookup+0x10/0x10 cfg80211connwork+0x245/0x34d [cfg80211] ? pfxcfg80211connwork+0x10/0x10 [cfg80211] ? updatecfsrqloadavg+0x3bc/0x3d7 ? schedclocknoinstr+0x9/0x1a ? schedclock+0x10/0x24 ? schedclockcpu+0x7e/0x42e ? newidlebalance+0x796/0x937 ? _pfxschedclockcpu+0x10/0x10 ? _pfxnewidlebalance+0x10/0x10 ? _kasancheckread+0x11/0x1f ? psigroupchange+0x8bc/0x944 ? rawspinunlock+0xe/0x24 ? rawspinrqunlock+0x47/0x54 ? rawspinrqunlockirq+0x9/0x1f ? finishtaskswitch.isra.0+0x347/0x586 ? _schedule+0x27bf/0x2892 ? mutexunlock+0x80/0xd0 ? dorawspinlock+0x75/0xdb ? _pfxschedule+0x10/0x10 processscheduledworks+0x58c/0x821 workerthread+0x4c7/0x586 ? _kasancheckread+0x11/0x1f kthread+0x285/0x294 ? _pfxworkerthread+0x10/0x10 ? _pfxkthread+0x10/0x10 retfromfork+0x29/0x6f ? _pfxkthread+0x10/0x10 retfromfork_asm+0x1b/0x30 </TASK>(CVE-2025-21729)

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

RDMA/mlx5: Fix a race for an ODP MR which leads to CQE with error

This patch addresses a race condition for an ODP MR that can result in a CQE with an error on the UMR QP.

During the _mlx5ibderegmr() flow, the following sequence of calls occurs:

mlx5revokemr() mlx5rumrrevokemr() mlx5rumrpostsend_wait()

At this point, the lkey is freed from the hardware's perspective.

However, concurrently, mlx5ibinvalidate_range() might be triggered by another task attempting to invalidate a range for the same freed lkey.

This task will: - Acquire the umemodp->umemmutex lock. - Call mlx5rumrupdate_xlt() on the UMR QP. - Since the lkey has already been freed, this can lead to a CQE error, causing the UMR QP to enter an error state [1].

To resolve this race condition, the umemodp->umemmutex lock is now also acquired as part of the mlx5revokemr() scope. Upon successful revoke, we set umem_odp->private which points to that MR to NULL, preventing any further invalidation attempts on its lkey.

[1] From dmesg:

infiniband rocep8s0f0: dumpcqe:277:(pid 0): WC error: 6, Message: memory bind operation error cqedump: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqedump: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqedump: 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqe_dump: 00000030: 00 00 00 00 08 00 78 06 25 00 11 b9 00 0e dd d2

WARNING: CPU: 15 PID: 1506 at drivers/infiniband/hw/mlx5/umr.c:394 mlx5rumrpostsendwait+0x15a/0x2b0 [mlx5ib] Modules linked in: ip6tablemangle ip6tablenatip6tablefilter ip6tables iptablemangle xtconntrack xtMASQUERADE nfconntracknetlink nfnetlink xtaddrtype iptablenat nfnat brnetfilter rpcsecgsskrb5 authrpcgss oidregistry overlay rpcrdma rdmaucm ibiser libiscsi scsitransportiscsi rdmacm iwcm ibumad ibipoib ibcm mlx5ib ibuverbs ibcore fuse mlx5core CPU: 15 UID: 0 PID: 1506 Comm: ibvrcpingpong Not tainted 6.12.0-rc7+ #1626 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5rumrpostsendwait+0x15a/0x2b0 [mlx5ib] [..] Call Trace: <TASK> mlx5rumrupdatexlt+0x23c/0x3e0 [mlx5ib] mlx5ibinvalidaterange+0x2e1/0x330 [mlx5ib] _mmunotifierinvalidaterangestart+0x1e1/0x240 zappagerangesingle+0xf1/0x1a0 madvisevmabehavior+0x677/0x6e0 domadvise+0x1a2/0x4b0 _x64sysmadvise+0x25/0x30 dosyscall64+0x6b/0x140 entrySYSCALL64afterhwframe+0x76/0x7e(CVE-2025-21732)

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

nilfs2: fix possible int overflows in nilfs_fiemap()

Since nilfsbmaplookupcontig() in nilfsfiemap() calculates its result by being prepared to go through potentially maxblocks == INT_MAX blocks, the value in n may experience an overflow caused by left shift of blkbits.

While it is extremely unlikely to occur, play it safe and cast right hand expression to wider type to mitigate the issue.

Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE.(CVE-2025-21736)

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

usbnet: ipheth: fix possible overflow in DPE length check

Originally, it was possible for the DPE length check to overflow if wDatagramIndex + wDatagramLength > U16_MAX. This could lead to an OoB read.

Move the wDatagramIndex term to the other side of the inequality.

An existing condition ensures that wDatagramIndex < urb->actual_length.(CVE-2025-21743)

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

clocksource: Use migratedisable() to avoid calling getrandom_u32() in atomic context

The following bug report happened with a PREEMPT_RT kernel:

BUG: sleeping function called from invalid context at kernel/locking/spinlockrt.c:48 inatomic(): 1, irqsdisabled(): 0, nonblock: 0, pid: 2012, name: kwatchdog preemptcount: 1, expected: 0 RCU nest depth: 0, expected: 0 getrandomu32+0x4f/0x110 clocksourceverifychoosecpus+0xab/0x1a0 clocksourceverifypercpu.part.0+0x6b/0x330 clocksourcewatchdogkthread+0x193/0x1a0

It is due to the fact that clocksourceverifychoosecpus() is invoked with preemption disabled. This function invokes getrandomu32() to obtain random numbers for choosing CPUs. The batchedentropy32 local lock and/or the basecrng.lock spinlock in driver/char/random.c will be acquired during the call. In PREEMPT_RT kernel, they are both sleeping locks and so cannot be acquired in atomic context.

Fix this problem by using migratedisable() to allow smpprocessorid() to be reliably used without introducing atomic context. preemptdisable() is then called after clocksourceverifychoose_cpus() but before the clocksource measurement is being run to avoid introducing unexpected latency.(CVE-2025-21767)

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

USB: hub: Ignore non-compliant devices with too many configs or interfaces

Robert Morris created a test program which can cause usbhubtostructhub() to dereference a NULL or inappropriate pointer:

Oops: general protection fault, probably for non-canonical address 0xcccccccccccccccc: 0000 [#1] SMP DEBUGPAGEALLOC PTI CPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14 Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021 Workqueue: usbhubwq hubevent RIP: 0010:usbhubadjustdeviceremovable+0x78/0x110 ... Call Trace: <TASK> ? dieaddr+0x31/0x80 ? excgeneralprotection+0x1b4/0x3c0 ? asmexcgeneralprotection+0x26/0x30 ? usbhubadjustdeviceremovable+0x78/0x110 hubprobe+0x7c7/0xab0 usbprobeinterface+0x14b/0x350 reallyprobe+0xd0/0x2d0 ? pfxdeviceattachdriver+0x10/0x10 _driverprobedevice+0x6e/0x110 driverprobedevice+0x1a/0x90 _deviceattachdriver+0x7e/0xc0 busforeachdrv+0x7f/0xd0 _deviceattach+0xaa/0x1a0 busprobedevice+0x8b/0xa0 deviceadd+0x62e/0x810 usbsetconfiguration+0x65d/0x990 usbgenericdriverprobe+0x4b/0x70 usbprobedevice+0x36/0xd0

The cause of this error is that the device has two interfaces, and the hub driver binds to interface 1 instead of interface 0, which is where usbhubtostructhub() looks.

We can prevent the problem from occurring by refusing to accept hub devices that violate the USB spec by having more than one configuration or interface.(CVE-2025-21776)

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

orangefs: fix a oob in orangefsdebugwrite

I got a syzbot report: slab-out-of-bounds Read in orangefsdebugwrite... several people suggested fixes, I tested Al Viro's suggestion and made this patch.(CVE-2025-21782)

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

gpiolib: Fix crash on error in gpiochipgetngpios()

The gpiochipgetngpios() uses chip*() macros to print messages. However these macros rely on gpiodev to be initialised and set, which is not the case when called via bgpioinit(). In such a case the printing messages will crash on NULL pointer dereference. Replace chip*() macros by the respective dev*() ones to avoid such crash.(CVE-2025-21783)

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

LoongArch: csum: Fix OoB access in IP checksum code for negative lengths

Commit 69e3a6aa6be2 ("LoongArch: Add checksum optimization for 64-bit system") would cause an undefined shift and an out-of-bounds read.

Commit 8bd795fedb84 ("arm64: csum: Fix OoB access in IP checksum code for negative lengths") fixes the same issue on ARM64.(CVE-2025-21789)

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

NFSD: fix hang in nfsd4shutdowncallback

If nfs4client is in courtesy state then there is no point to send the callback. This causes nfsd4shutdowncallback to hang since clcb_inflight is not 0. This hang lasts about 15 minutes until TCP notifies NFSD that the connection was dropped.

This patch modifies nfsd4runcbwork to skip the RPC call if nfs4client is in courtesy state.(CVE-2025-21795)

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

nfsd: clear aclaccess/acldefault after releasing them

If getting acldefault fails, aclaccess and acldefault will be released simultaneously. However, aclaccess will still retain a pointer pointing to the released posixacl, which will trigger a WARNING in nfs3svcrelease_getacl like this:

------------[ cut here ]------------ refcountt: underflow; use-after-free. WARNING: CPU: 26 PID: 3199 at lib/refcount.c:28 refcountwarnsaturate+0xb5/0x170 Modules linked in: CPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted 6.12.0-rc6-00079-g04ae226af01f-dirty #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcountwarnsaturate+0xb5/0x170 Code: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75 e4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff <0f> 0b eb cd 0f b6 1d 8a3 RSP: 0018:ffffc90008637cd8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fde RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380 RBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56 R10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001 R13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0 FS: 0000000000000000(0000) GS:ffff88871ed00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? refcountwarnsaturate+0xb5/0x170 ? _warn+0xa5/0x140 ? refcountwarnsaturate+0xb5/0x170 ? reportbug+0x1b1/0x1e0 ? handlebug+0x53/0xa0 ? excinvalidop+0x17/0x40 ? asmexcinvalidop+0x1a/0x20 ? ticknohztickstopped+0x1e/0x40 ? refcountwarnsaturate+0xb5/0x170 ? refcountwarnsaturate+0xb5/0x170 nfs3svcreleasegetacl+0xc9/0xe0 svcprocesscommon+0x5db/0xb60 ? _pfxsvcprocesscommon+0x10/0x10 ? _rcureadunlock+0x69/0xa0 ? _pfxnfsddispatch+0x10/0x10 ? svcxprtreceived+0xa1/0x120 ? xdrinitdecode+0x11d/0x190 svcprocess+0x2a7/0x330 svchandlexprt+0x69d/0x940 svcrecv+0x180/0x2d0 nfsd+0x168/0x200 ? _pfxnfsd+0x10/0x10 kthread+0x1a2/0x1e0 ? kthread+0xf4/0x1e0 ? _pfxkthread+0x10/0x10 retfromfork+0x34/0x60 ? _pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK> Kernel panic - not syncing: kernel: panicon_warn set ...

Clear aclaccess/acldefault after posixaclrelease is called to prevent UAF from being triggered.(CVE-2025-21796)

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

ptp: Ensure info->enable callback is always set

The ioctl and sysfs handlers unconditionally call the ->enable callback. Not all drivers implement that callback, leading to NULL dereferences. Example of affected drivers: ptps390.c, ptpvclock.c and ptp_mock.c.

Instead use a dummy callback if no better was specified by the driver.(CVE-2025-21814)

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

block: mark GFP_NOIO around sysfs ->store()

sysfs ->store is called with queue freezed, meantime we have several ->store() callbacks(updatenrrequests, wbt, scheduler) to allocate memory with GFP_KERNEL which may run into direct reclaim code path, then potential deadlock can be caused.

Fix the issue by marking NOIO around sysfs ->store()(CVE-2025-21817)

Database specific

{
    "severity": "High"
}

References

Affected packages

openEuler:24.03-LTS-SP1 / kernel

Package

Name: kernel
Purl: pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS-SP1

Affected ranges

Type: ECOSYSTEM
Events: Introduced

0Unknown introduced version / All previous versions are affected

Fixed

6.6.0-82.0.0.86.oe2403sp1

Ecosystem specific

{
    "aarch64": [
        "bpftool-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
        "bpftool-debuginfo-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
        "kernel-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
        "kernel-debuginfo-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
        "kernel-debugsource-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
        "kernel-devel-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
        "kernel-headers-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
        "kernel-source-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
        "kernel-tools-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
        "kernel-tools-debuginfo-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
        "kernel-tools-devel-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
        "perf-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
        "perf-debuginfo-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
        "python3-perf-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
        "python3-perf-debuginfo-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm"
    ],
    "src": [
        "kernel-6.6.0-82.0.0.86.oe2403sp1.src.rpm"
    ],
    "x86_64": [
        "bpftool-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
        "bpftool-debuginfo-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
        "kernel-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
        "kernel-debuginfo-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
        "kernel-debugsource-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
        "kernel-devel-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
        "kernel-headers-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
        "kernel-source-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
        "kernel-tools-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
        "kernel-tools-debuginfo-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
        "kernel-tools-devel-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
        "perf-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
        "perf-debuginfo-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
        "python3-perf-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
        "python3-perf-debuginfo-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm"
    ]
}