The Linux Kernel, the operating system core itself.

Security Fix(es):

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

PCI: ofproperty: Return error for intmap allocation failure

Return -ENOMEM from ofpcipropintrmap() if kcalloc() fails to prevent a NULL pointer dereference in this case.

bhelgaas: commit log

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

drm/arm/malidp: fix a possible null pointer dereference

In malidpmwconnectorreset, new memory is allocated with kzalloc, but no check is performed. In order to prevent null pointer dereferencing, ensure that mwstate is checked before calling _drmatomichelperconnector_reset.(CVE-2024-36014)

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

tty: ngsm: fix possible out-of-bounds in gsm0receive()

Assuming the following: - side A configures the ngsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration.

Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAXMRU in gsm0receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru.

All other checks remain as we still need to limit the data according to the user configuration and actual payload size.(CVE-2024-36016)

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

keys: Fix overwrite of key expiration on instantiation

The expiry time of a key is unconditionally overwritten during instantiation, defaulting to turn it permanent. This causes a problem for DNS resolution as the expiration set by user-space is overwritten to TIME64MAX, disabling further DNS updates. Fix this by restoring the condition that keyset_expiry is only called when the pre-parser sets a specific expiry.(CVE-2024-36031)

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

mm/userfaultfd: reset ptes when close() for wr-protected ones

Userfaultfd unregister includes a step to remove wr-protect bits from all the relevant pgtable entries, but that only covered an explicit UFFDIO_UNREGISTER ioctl, not a close() on the userfaultfd itself. Cover that too. This fixes a WARN trace.

The only user visible side effect is the user can observe leftover wr-protect bits even if the user close()ed on an userfaultfd when releasing the last reference of it. However hopefully that should be harmless, and nothing bad should happen even if so.

This change is now more important after the recent page-table-check patch we merged in mm-unstable (446dd9ad37d0 ("mm/pagetablecheck: support userfault wr-protect entries")), as we'll do sanity check on uffd-wp bits without vma context. So it's better if we can 100% guarantee no uffd-wp bit leftovers, to make sure each report will be valid.(CVE-2024-36881)

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

nfs: Handle error of rpcprocregister() in nfsnetinit().

syzkaller reported a warning [0] triggered while destroying immature netns.

rpcprocregister() was called in initnfsfs(), but its error has been ignored since at least the initial commit 1da177e4c3f4 ("Linux-2.6.12-rc2").

Recently, commit d47151b79e32 ("nfs: expose /proc/net/sunrpc/nfs in net namespaces") converted the procfs to per-netns and made the problem more visible.

Even when rpcprocregister() fails, nfsnetinit() could succeed, and thus nfsnetexit() will be called while destroying the netns.

Then, removeprocentry() will be called for non-existing proc directory and trigger the warning below.

Let's handle the error of rpcprocregister() properly in nfsnetinit().

WARNING: CPU: 1 PID: 1710 at fs/proc/generic.c:711 removeprocentry+0x1bb/0x2d0 fs/proc/generic.c:711 Modules linked in: CPU: 1 PID: 1710 Comm: syz-executor.2 Not tainted 6.8.0-12822-gcd51db110a7e #12 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:removeprocentry+0x1bb/0x2d0 fs/proc/generic.c:711 Code: 41 5d 41 5e c3 e8 85 09 b5 ff 48 c7 c7 88 58 64 86 e8 09 0e 71 02 e8 74 09 b5 ff 4c 89 e6 48 c7 c7 de 1b 80 84 e8 c5 ad 97 ff <0f> 0b eb b1 e8 5c 09 b5 ff 48 c7 c7 88 58 64 86 e8 e0 0d 71 02 eb RSP: 0018:ffffc9000c6d7ce0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff8880422b8b00 RCX: ffffffff8110503c RDX: ffff888030652f00 RSI: ffffffff81105045 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: ffffffff81bb62cb R12: ffffffff84807ffc R13: ffff88804ad6fcc0 R14: ffffffff84807ffc R15: ffffffff85741ff8 FS: 00007f30cfba8640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff51afe8000 CR3: 000000005a60a005 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> rpcprocunregister+0x64/0x70 net/sunrpc/stats.c:310 nfsnetexit+0x1c/0x30 fs/nfs/inode.c:2438 opsexitlist+0x62/0xb0 net/core/netnamespace.c:170 setupnet+0x46c/0x660 net/core/netnamespace.c:372 copynetns+0x244/0x590 net/core/netnamespace.c:505 createnewnamespaces+0x2ed/0x770 kernel/nsproxy.c:110 unsharensproxynamespaces+0xae/0x160 kernel/nsproxy.c:228 ksysunshare+0x342/0x760 kernel/fork.c:3322 _dosysunshare kernel/fork.c:3393 [inline] _sesysunshare kernel/fork.c:3391 [inline] _x64sysunshare+0x1f/0x30 kernel/fork.c:3391 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x4f/0x110 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x46/0x4e RIP: 0033:0x7f30d0febe5d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48 RSP: 002b:00007f30cfba7cc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000110 RAX: ffffffffffffffda RBX: 00000000004bbf80 RCX: 00007f30d0febe5d RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000006c020600 RBP: 00000000004bbf80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002 R13: 000000000000000b R14: 00007f30d104c530 R15: 0000000000000000 </TASK>(CVE-2024-36939)

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

net: bridge: mst: fix vlan use-after-free

syzbot reported a suspicious rcu usage[1] in bridge's mst code. While fixing it I noticed that nothing prevents a vlan to be freed while walking the list from the same path (br forward delay timer). Fix the rcu usage and also make sure we are not accessing freed memory by making brmstvlansetstate use rcu read lock.

[1] WARNING: suspicious RCU usage 6.9.0-rc6-syzkaller #0 Not tainted

net/bridge/brprivate.h:1599 suspicious rcudereferenceprotected() usage! ... stack backtrace: CPU: 1 PID: 8017 Comm: syz-executor.1 Not tainted 6.9.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: <IRQ> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:114 lockdeprcususpicious+0x221/0x340 kernel/locking/lockdep.c:6712 nbpvlangroup net/bridge/brprivate.h:1599 [inline] brmstsetstate+0x1ea/0x650 net/bridge/brmst.c:105 brsetstate+0x28a/0x7b0 net/bridge/brstp.c:47 brforwarddelaytimerexpired+0x176/0x440 net/bridge/brstptimer.c:88 calltimerfn+0x18e/0x650 kernel/time/timer.c:1793 expiretimers kernel/time/timer.c:1844 [inline] _runtimers kernel/time/timer.c:2418 [inline] _runtimerbase+0x66a/0x8e0 kernel/time/timer.c:2429 runtimerbase kernel/time/timer.c:2438 [inline] runtimersoftirq+0xb7/0x170 kernel/time/timer.c:2448 _dosoftirq+0x2c6/0x980 kernel/softirq.c:554 invokesoftirq kernel/softirq.c:428 [inline] _irqexitrcu+0xf2/0x1c0 kernel/softirq.c:633 irqexitrcu+0x9/0x30 kernel/softirq.c:645 instrsysvecapictimerinterrupt arch/x86/kernel/apic/apic.c:1043 [inline] sysvecapictimerinterrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043 </IRQ> <TASK> asmsysvecapictimerinterrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702 RIP: 0010:lock_acquire+0x264/0x550 kernel/locking/lockdep.c:5758 Code: 2b 00 74 08 4c 89 f7 e8 ba d1 84 00 f6 44 24 61 02 0f 85 85 01 00 00 41 f7 c7 00 02 00 00 74 01 fb 48 c7 44 24 40 0e 36 e0 45 <4b> c7 44 25 00 00 00 00 00 43 c7 44 25 09 00 00 00 00 43 c7 44 25 RSP: 0018:ffffc90013657100 EFLAGS: 00000206 RAX: 0000000000000001 RBX: 1ffff920026cae2c RCX: 0000000000000001 RDX: dffffc0000000000 RSI: ffffffff8bcaca00 RDI: ffffffff8c1eaa60 RBP: ffffc90013657260 R08: ffffffff92efe507 R09: 1ffffffff25dfca0 R10: dffffc0000000000 R11: fffffbfff25dfca1 R12: 1ffff920026cae28 R13: dffffc0000000000 R14: ffffc90013657160 R15: 0000000000000246(CVE-2024-36979)

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

scsi: qedf: Ensure the copied buf is NUL terminated

Currently, we allocate a count-sized kernel buffer and copy count from userspace to that buffer. Later, we use kstrtouint on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using kstrtouint. Fix this issue by using memdupusernul instead of memdup_user.(CVE-2024-38559)

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

ecryptfs: Fix buffer size for tag 66 packet

The 'TAG 66 Packet Format' description is missing the cipher code and checksum fields that are packed into the message packet. As a result, the buffer allocated for the packet is 3 bytes too small and writetag66_packet() will write up to 3 bytes past the end of the buffer.

Fix this by increasing the size of the allocation so the whole packet will always fit in the buffer.

This fixes the below kasan slab-out-of-bounds bug:

BUG: KASAN: slab-out-of-bounds in ecryptfsgeneratekeypacketset+0x7d6/0xde0 Write of size 1 at addr ffff88800afbb2a5 by task touch/181

CPU: 0 PID: 181 Comm: touch Not tainted 6.6.13-gnu #1 4c9534092be820851bb687b82d1f92a426598dc6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2/GNU Guix 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x4c/0x70 printreport+0xc5/0x610 ? ecryptfsgeneratekeypacketset+0x7d6/0xde0 ? kasancompletemodereportinfo+0x44/0x210 ? ecryptfsgeneratekeypacketset+0x7d6/0xde0 kasanreport+0xc2/0x110 ? ecryptfsgeneratekeypacketset+0x7d6/0xde0 asanstore1+0x62/0x80 ecryptfsgeneratekeypacketset+0x7d6/0xde0 ? _pfxecryptfsgeneratekeypacketset+0x10/0x10 ? _allocpages+0x2e2/0x540 ? _pfxovlopen+0x10/0x10 [overlay 30837f11141636a8e1793533a02e6e2e885dad1d] ? dentryopen+0x8f/0xd0 ecryptfswritemetadata+0x30a/0x550 ? _pfxecryptfswritemetadata+0x10/0x10 ? ecryptfsgetlowerfile+0x6b/0x190 ecryptfsinitializefile+0x77/0x150 ecryptfscreate+0x1c2/0x2f0 pathopenat+0x17cf/0x1ba0 ? _pfxpathopenat+0x10/0x10 dofilpopen+0x15e/0x290 ? _pfxdofilpopen+0x10/0x10 ? _kasancheckwrite+0x18/0x30 ? rawspinlock+0x86/0xf0 ? _pfxrawspinlock+0x10/0x10 ? kasancheckwrite+0x18/0x30 ? allocfd+0xf4/0x330 dosysopenat2+0x122/0x160 ? _pfxdosysopenat2+0x10/0x10 _x64sysopenat+0xef/0x170 ? _pfxx64sysopenat+0x10/0x10 dosyscall64+0x60/0xd0 entrySYSCALL64afterhwframe+0x6e/0xd8 RIP: 0033:0x7f00a703fd67 Code: 25 00 00 41 00 3d 00 00 41 00 74 37 64 8b 04 25 18 00 00 00 85 c0 75 5b 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 85 00 00 00 48 83 c4 68 5d 41 5c c3 0f 1f RSP: 002b:00007ffc088e30b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101 RAX: ffffffffffffffda RBX: 00007ffc088e3368 RCX: 00007f00a703fd67 RDX: 0000000000000941 RSI: 00007ffc088e48d7 RDI: 00000000ffffff9c RBP: 00007ffc088e48d7 R08: 0000000000000001 R09: 0000000000000000 R10: 00000000000001b6 R11: 0000000000000246 R12: 0000000000000941 R13: 0000000000000000 R14: 00007ffc088e48d7 R15: 00007f00a7180040 </TASK>

Allocated by task 181: kasansavestack+0x2f/0x60 kasansettrack+0x29/0x40 kasansaveallocinfo+0x25/0x40 _kasankmalloc+0xc5/0xd0 _kmalloc+0x66/0x160 ecryptfsgeneratekeypacketset+0x6d2/0xde0 ecryptfswritemetadata+0x30a/0x550 ecryptfsinitializefile+0x77/0x150 ecryptfscreate+0x1c2/0x2f0 pathopenat+0x17cf/0x1ba0 dofilpopen+0x15e/0x290 dosysopenat2+0x122/0x160 _x64sysopenat+0xef/0x170 dosyscall64+0x60/0xd0 entrySYSCALL64after_hwframe+0x6e/0xd8(CVE-2024-38578)

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

netrom: fix possible dead-lock in nrrtioctl()

syzbot loves netrom, and found a possible deadlock in nrrtioctl [1]

Make sure we always acquire nrnodelistlock before nrnodelock(nrnode)

[1] WARNING: possible circular locking dependency detected

6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0 Not tainted

syz-executor350/5129 is trying to acquire lock: ffff8880186e2070 (&nrnode->nodelock){+...}-{2:2}, at: spinlockbh include/linux/spinlock.h:356 [inline] ffff8880186e2070 (&nrnode->nodelock){+...}-{2:2}, at: nrnodelock include/net/netrom.h:152 [inline] ffff8880186e2070 (&nrnode->nodelock){+...}-{2:2}, at: nrdecobs net/netrom/nrroute.c:464 [inline] ffff8880186e2070 (&nrnode->nodelock){+...}-{2:2}, at: nrrtioctl+0x1bb/0x1090 net/netrom/nrroute.c:697

but task is already holding lock: ffffffff8f7053b8 (nrnodelistlock){+...}-{2:2}, at: spinlockbh include/linux/spinlock.h:356 [inline] ffffffff8f7053b8 (nrnodelistlock){+...}-{2:2}, at: nrdecobs net/netrom/nrroute.c:462 [inline] ffffffff8f7053b8 (nrnodelistlock){+...}-{2:2}, at: nrrtioctl+0x10a/0x1090 net/netrom/nr_route.c:697

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (nrnodelistlock){+...}-{2:2}: lockacquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 _rawspinlockbh include/linux/spinlockapismp.h:126 [inline] rawspinlockbh+0x35/0x50 kernel/locking/spinlock.c:178 spinlockbh include/linux/spinlock.h:356 [inline] nrremovenode net/netrom/nrroute.c:299 [inline] nrdelnode+0x4b4/0x820 net/netrom/nrroute.c:355 nrrtioctl+0xa95/0x1090 net/netrom/nrroute.c:683 sockdoioctl+0x158/0x460 net/socket.c:1222 sockioctl+0x629/0x8e0 net/socket.c:1341 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:904 [inline] _sesysioctl+0xfc/0x170 fs/ioctl.c:890 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf5/0x240 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f

-> #0 (&nrnode->nodelock){+...}-{2:2}: checkprevadd kernel/locking/lockdep.c:3134 [inline] checkprevsadd kernel/locking/lockdep.c:3253 [inline] validatechain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869 _lockacquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137 lockacquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 _rawspinlockbh include/linux/spinlockapismp.h:126 [inline] rawspinlockbh+0x35/0x50 kernel/locking/spinlock.c:178 spinlockbh include/linux/spinlock.h:356 [inline] nrnodelock include/net/netrom.h:152 [inline] nrdecobs net/netrom/nrroute.c:464 [inline] nrrtioctl+0x1bb/0x1090 net/netrom/nrroute.c:697 sockdoioctl+0x158/0x460 net/socket.c:1222 sockioctl+0x629/0x8e0 net/socket.c:1341 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:904 [inline] _sesysioctl+0xfc/0x170 fs/ioctl.c:890 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf5/0x240 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

other info that might help us debug this:

Possible unsafe locking scenario:

   CPU0                    CPU1
   ----                    ----

lock(nrnodelistlock); lock(&nrnode->nodelock); lock(nrnodelistlock); lock(&nrnode->nodelock);

* DEADLOCK *

1 lock held by syz-executor350/5129: #0: ffffffff8f7053b8 (nrnodelistlock){+...}-{2:2}, at: spinlockbh include/linux/spinlock.h:356 [inline] #0: ffffffff8f7053b8 (nrnodelistlock){+...}-{2:2}, at: nrdecobs net/netrom/nr_route.c:462 [inline] #0: ffffffff8f70 ---truncated---(CVE-2024-38589)

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

ALSA: timer: Set lower bound of start tick time

Currently ALSA timer doesn't have the lower limit of the start tick time, and it allows a very small size, e.g. 1 tick with 1ns resolution for hrtimer. Such a situation may lead to an unexpected RCU stall, where the callback repeatedly queuing the expire update, as reported by fuzzer.

This patch introduces a sanity check of the timer start tick time, so that the system returns an error when a too small start size is set. As of this patch, the lower limit is hard-coded to 100us, which is small enough but can still work somehow.(CVE-2024-38618)

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

usb-storage: alauda: Check whether the media is initialized

The member "uzonesize" of struct alaudainfo will remain 0 if alaudainitmedia() fails, potentially causing divide errors in alaudareaddata() and alaudawritelba(). - Add a member "mediainitialized" to struct alaudainfo. - Change a condition in alaudacheckmedia() to ensure the first initialization. - Add an error check for the return value of alaudainit_media().(CVE-2024-38619)

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

9p: add missing locking around taking dentry fid list

Fix a use-after-free on dentry's d_fsdata fid list when a thread looks up a fid through dentry while another thread unlinks it:

UAF thread: refcountt: addition on 0; use-after-free. p9fidget linux/./include/net/9p/client.h:262 v9fsfidfind+0x236/0x280 linux/fs/9p/fid.c:129 v9fsfidlookupwithuid linux/fs/9p/fid.c:181 v9fsfidlookup+0xbf/0xc20 linux/fs/9p/fid.c:314 v9fsvfsgetattrdotl+0xf9/0x360 linux/fs/9p/vfsinodedotl.c:400 vfs_statx+0xdd/0x4d0 linux/fs/stat.c:248

Freed by: p9fiddestroy (inlined) p9clientclunk+0xb0/0xe0 linux/net/9p/client.c:1456 p9fidput linux/./include/net/9p/client.h:278 v9fsdentryrelease+0xb5/0x140 linux/fs/9p/vfsdentry.c:55 v9fsremove+0x38f/0x620 linux/fs/9p/vfsinode.c:518 vfsunlink+0x29a/0x810 linux/fs/namei.c:4335

The problem is that dfsdata was not accessed under dlock, because drelease() normally is only called once the dentry is otherwise no longer accessible but since we also call it explicitly in v9fsremove that lock is required: move the hlist out of the dentry under lock then unref its fids once they are no longer accessible.(CVE-2024-39463)

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

nilfs2: fix nilfsemptydir() misjudgment and long loop on I/O errors

The error handling in nilfsemptydir() when a directory folio/page read fails is incorrect, as in the old ext2 implementation, and if the folio/page cannot be read or nilfscheckfolio() fails, it will falsely determine the directory as empty and corrupt the file system.

In addition, since nilfsemptydir() does not immediately return on a failed folio/page read, but continues to loop, this can cause a long loop with I/O if i_size of the directory's inode is also corrupted, causing the log writer thread to wait and hang, as reported by syzbot.

Fix these issues by making nilfsemptydir() immediately return a false value (0) if it fails to get a directory folio/page.(CVE-2024-39469)

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

xfs: fix log recovery buffer allocation for the legacy h_size fixup

Commit a70f9fe52daa ("xfs: detect and handle invalid iclog size set by mkfs") added a fixup for incorrect hsize values used for the initial umount record in old xfsprogs versions. Later commit 0c771b99d6c9 ("xfs: clean up calculation of LR header blocks") cleaned up the log reover buffer calculation, but stoped using the fixed up hsize value to size the log recovery buffer, which can lead to an out of bounds access when the incorrect h_size does not come from the old mkfs tool, but a fuzzer.

Fix this by open coding xloglogrechblks and taking the fixed h_size into account for this calculation.(CVE-2024-39472)

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

media: v4l: async: Properly re-initialise notifier entry in unregister

The notifierentry of a notifier is not re-initialised after unregistering the notifier. This leads to dangling pointers being left there so use listdelinit() to return the notifierentry an empty list.(CVE-2024-39485)

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

ima: Fix use-after-free on a dentry's dname.name

->dname.name can change on rename and the earlier value can be freed; there are conditions sufficient to stabilize it (->dlock on dentry, ->dlock on its parent, ->irwsem exclusive on the parent's inode, rename_lock), but none of those are met at any of the sites. Take a stable snapshot of the name instead.(CVE-2024-39494)

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

vmci: prevent speculation leaks by sanitizing event in event_deliver()

Coverity spotted that eventmsg is controlled by user-space, eventmsg->eventdata.event is passed to eventdeliver() and used as an index without sanitization.

This change ensures that the event index is sanitized to mitigate any possibility of speculative information leaks.

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

Only compile tested, no access to HW.(CVE-2024-39499)

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

drm/komeda: check for error-valued pointer

komedapipelineget_state() may return an error-valued pointer, thus check the pointer for negative or null value before dereferencing.(CVE-2024-39505)

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

wifi: mac80211: Fix deadlock in ieee80211stapsdeliverwakeup()

The ieee80211stapsdeliverwakeup() function takes sta->pslock to synchronizes with ieee80211txhunicastpsbuf() which is called from softirq context. However using only spinlock() to get sta->pslock in ieee80211stapsdeliverwakeup() does not prevent softirq to execute on this same CPU, to run ieee80211txhunicastps_buf() and try to take this same lock ending in deadlock. Below is an example of rcu stall that arises in such situation.

rcu: INFO: rcusched self-detected stall on CPU rcu: 2-....: (42413413 ticks this GP) idle=b154/1/0x4000000000000000 softirq=1763/1765 fqs=21206996 rcu: (t=42586894 jiffies g=2057 q=362405 ncpus=4) CPU: 2 PID: 719 Comm: wpasupplicant Tainted: G W 6.4.0-02158-g1b062f552873 #742 Hardware name: RPT (r1) (DT) pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : queuedspinlockslowpath+0x58/0x2d0 lr : invoketxhandlersearly+0x5b4/0x5c0 sp : ffff00001ef64660 x29: ffff00001ef64660 x28: ffff000009bc1070 x27: ffff000009bc0ad8 x26: ffff000009bc0900 x25: ffff00001ef647a8 x24: 0000000000000000 x23: ffff000009bc0900 x22: ffff000009bc0900 x21: ffff00000ac0e000 x20: ffff00000a279e00 x19: ffff00001ef646e8 x18: 0000000000000000 x17: ffff800016468000 x16: ffff00001ef608c0 x15: 0010533c93f64f80 x14: 0010395c9faa3946 x13: 0000000000000000 x12: 00000000fa83b2da x11: 000000012edeceea x10: ffff0000010fbe00 x9 : 0000000000895440 x8 : 000000000010533c x7 : ffff00000ad8b740 x6 : ffff00000c350880 x5 : 0000000000000007 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffff00000ac0e0e8 Call trace: queuedspinlockslowpath+0x58/0x2d0 ieee80211tx+0x80/0x12c ieee80211txpending+0x110/0x278 taskletactioncommon.constprop.0+0x10c/0x144 taskletaction+0x20/0x28 _stext+0x11c/0x284 dosoftirq+0xc/0x14 callonirqstack+0x24/0x34 dosoftirqownstack+0x18/0x20 dosoftirq+0x74/0x7c _localbhenableip+0xa0/0xa4 _ieee80211waketxqs+0x3b0/0x4b8 _ieee80211wakequeue+0x12c/0x168 ieee80211addpendingskbs+0xec/0x138 ieee80211stapsdeliverwakeup+0x2a4/0x480 ieee80211mpsstastatusupdate.part.0+0xd8/0x11c ieee80211mpsstastatusupdate+0x18/0x24 staapplyparameters+0x3bc/0x4c0 ieee80211changestation+0x1b8/0x2dc nl80211setstation+0x444/0x49c genlfamilyrcvmsgdoit.isra.0+0xa4/0xfc genlrcvmsg+0x1b0/0x244 netlinkrcvskb+0x38/0x10c genlrcv+0x34/0x48 netlinkunicast+0x254/0x2bc netlinksendmsg+0x190/0x3b4 syssendmsg+0x1e8/0x218 _syssendmsg+0x68/0x8c _syssendmsg+0x44/0x84 _arm64syssendmsg+0x20/0x28 doel0svc+0x6c/0xe8 el0svc+0x14/0x48 el0t64synchandler+0xb0/0xb4 el0t64_sync+0x14c/0x150

Using spinlockbh()/spinunlockbh() instead prevents softirq to raise on the same CPU that is holding the lock.(CVE-2024-40912)

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

drm/exynos: hdmi: report safe 640x480 mode as a fallback when no EDID found

When reading EDID fails and driver reports no modes available, the DRM core adds an artificial 1024x786 mode to the connector. Unfortunately some variants of the Exynos HDMI (like the one in Exynos4 SoCs) are not able to drive such mode, so report a safe 640x480 mode instead of nothing in case of the EDID reading failure.

This fixes the following issue observed on Trats2 board since commit 13d5b040363c ("drm/exynos: do not return negative values from .get_modes()"):

[drm] Exynos DRM: using 11c00000.fimd device for DMA mapping operations exynos-drm exynos-drm: bound 11c00000.fimd (ops fimdcomponentops) exynos-drm exynos-drm: bound 12c10000.mixer (ops mixercomponentops) exynos-dsi 11c80000.dsi: [drm:samsungdsimhostattach] Attached s6e8aa0 device (lanes:4 bpp:24 mode-flags:0x10b) exynos-drm exynos-drm: bound 11c80000.dsi (ops exynosdsicomponentops) exynos-drm exynos-drm: bound 12d00000.hdmi (ops hdmicomponentops) [drm] Initialized exynos 1.1.0 20180330 for exynos-drm on minor 1 exynos-hdmi 12d00000.hdmi: [drm:hdmiphyenable.part.0] *ERROR* PLL could not reach steady state panel-samsung-s6e8aa0 11c80000.dsi.0: ID: 0xa2, 0x20, 0x8c exynos-mixer 12c10000.mixer: timeout waiting for VSYNC ------------[ cut here ]------------ WARNING: CPU: 1 PID: 11 at drivers/gpu/drm/drmatomichelper.c:1682 drmatomichelperwaitforvblanks.part.0+0x2b0/0x2b8 [CRTC:70:crtc-1] vblank wait timed out Modules linked in: CPU: 1 PID: 11 Comm: kworker/u16:0 Not tainted 6.9.0-rc5-next-20240424 #14913 Hardware name: Samsung Exynos (Flattened Device Tree) Workqueue: eventsunbound deferredprobeworkfunc Call trace: unwindbacktrace from showstack+0x10/0x14 showstack from dumpstacklvl+0x68/0x88 dumpstacklvl from _warn+0x7c/0x1c4 _warn from warnslowpathfmt+0x11c/0x1a8 warnslowpathfmt from drmatomichelperwaitforvblanks.part.0+0x2b0/0x2b8 drmatomichelperwaitforvblanks.part.0 from drmatomichelpercommittailrpm+0x7c/0x8c drmatomichelpercommittailrpm from committail+0x9c/0x184 committail from drmatomichelpercommit+0x168/0x190 drmatomichelpercommit from drmatomiccommit+0xb4/0xe0 drmatomiccommit from drmclientmodesetcommitatomic+0x23c/0x27c drmclientmodesetcommitatomic from drmclientmodesetcommitlocked+0x60/0x1cc drmclientmodesetcommitlocked from drmclientmodesetcommit+0x24/0x40 drmclientmodesetcommit from _drmfbhelperrestorefbdevmodeunlocked+0x9c/0xc4 _drmfbhelperrestorefbdevmodeunlocked from drmfbhelpersetpar+0x2c/0x3c drmfbhelpersetpar from fbconinit+0x3d8/0x550 fbconinit from visualinit+0xc0/0x108 visualinit from dobindcondriver+0x1b8/0x3a4 dobindcondriver from dotakeoverconsole+0x140/0x1ec dotakeoverconsole from dofbcontakeover+0x70/0xd0 dofbcontakeover from fbconfbregistered+0x19c/0x1ac fbconfbregistered from registerframebuffer+0x190/0x21c registerframebuffer from _drmfbhelperinitialconfigandunlock+0x350/0x574 _drmfbhelperinitialconfigandunlock from exynosdrmfbdevclienthotplug+0x6c/0xb0 exynosdrmfbdevclienthotplug from drmclientregister+0x58/0x94 drmclientregister from exynosdrmbind+0x160/0x190 exynosdrmbind from trytobringupaggregatedevice+0x200/0x2d8 trytobringupaggregatedevice from _componentadd+0xb0/0x170 _componentadd from mixerprobe+0x74/0xcc mixerprobe from platformprobe+0x5c/0xb8 platformprobe from reallyprobe+0xe0/0x3d8 reallyprobe from _driverprobedevice+0x9c/0x1e4 _driverprobedevice from driverprobedevice+0x30/0xc0 driverprobedevice from _deviceattachdriver+0xa8/0x120 _deviceattachdriver from busforeachdrv+0x80/0xcc busforeachdrv from _deviceattach+0xac/0x1fc _deviceattach from busprobedevice+0x8c/0x90 busprobedevice from deferredprobeworkfunc+0 ---truncated---(CVE-2024-40916)

In the Linux kernel, the following vulnerability has been resolved: parisc: Try to fix random segmentation faults in package builds PA-RISC systems with PA8800 and PA8900 processors have had problems with random segmentation faults for many years. Systems with earlier processors are much more stable. Systems with PA8800 and PA8900 processors have a large L2 cache which needs per page flushing for decent performance when a large range is flushed. The combined cache in these systems is also more sensitive to non-equivalent aliases than the caches in earlier systems. The majority of random segmentation faults that I have looked at appear to be memory corruption in memory allocated using mmap and malloc. My first attempt at fixing the random faults didn't work. On reviewing the cache code, I realized that there were two issues which the existing code didn't handle correctly. Both relate to cache move-in. Another issue is that the present bit in PTEs is racy. 1) PA-RISC caches have a mind of their own and they can speculatively load data and instructions for a page as long as there is a entry in the TLB for the page which allows move-in. TLBs are local to each CPU. Thus, the TLB entry for a page must be purged before flushing the page. This is particularly important on SMP systems. In some of the flush routines, the flush routine would be called and then the TLB entry would be purged. This was because the flush routine needed the TLB entry to do the flush. 2) My initial approach to trying the fix the random faults was to try and use flushcachepageifpresent for all flush operations. This actually made things worse and led to a couple of hardware lockups. It finally dawned on me that some lines weren't being flushed because the pte check code was racy. This resulted in random inequivalent mappings to physical pages. The _flushcachepage tmpalias flush sets up its own TLB entry and it doesn't need the existing TLB entry. As long as we can find the pte pointer for the vm page, we can get the pfn and physical address of the page. We can also purge the TLB entry for the page before doing the flush. Further, _flushcachepage uses a special TLB entry that inhibits cache move-in. When switching page mappings, we need to ensure that lines are removed from the cache. It is not sufficient to just flush the lines to memory as they may come back. This made it clear that we needed to implement all the required flush operations using tmpalias routines. This includes flushes for user and kernel pages. After modifying the code to use tmpalias flushes, it became clear that the random segmentation faults were not fully resolved. The frequency of faults was worse on systems with a 64 MB L2 (PA8900) and systems with more CPUs (rp4440). The warning that I added to flushcachepageifpresent to detect pages that couldn't be flushed triggered frequently on some systems. Helge and I looked at the pages that couldn't be flushed and found that the PTE was either cleared or for a swap page. Ignoring pages that were swapped out seemed okay but pages with cleared PTEs seemed problematic. I looked at routines related to pteclear and noticed ptepclearflush. The default implementation just flushes the TLB entry. However, it was obvious that on parisc we need to flush the cache page as well. If we don't flush the cache page, stale lines will be left in the cache and cause random corruption. Once a PTE is cleared, there is no way to find the physical address associated with the PTE and flush the associated page at a later time. I implemented an updated change with a parisc specific version of ptepclearflush. It fixed the random data corruption on Helge's rp4440 and rp3440, as well as on my c8000. At this point, I realized that I could restore the code where we only flush in flushcachepageif_present if the page has been accessed. However, for this, we also need to flush the cache when the accessed bit is cleared in ---truncated---(CVE-2024-40918)

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

vmxnet3: disable rx data ring on dma allocation failure

When vmxnet3rqcreate() fails to allocate memory for rq->dataring.base, the subsequent call to vmxnet3rqdestroyallrxdataring does not reset rq->dataring.desc_size for the data ring that failed, which presumably causes the hypervisor to reference it on packet reception.

To fix this bug, rq->dataring.descsize needs to be set to 0 to tell the hypervisor to disable this feature.

[ 95.436876] kernel BUG at net/core/skbuff.c:207! [ 95.439074] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 95.440411] CPU: 7 PID: 0 Comm: swapper/7 Not tainted 6.9.3-dirty #1 [ 95.441558] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 12/12/2018 [ 95.443481] RIP: 0010:skbpanic+0x4d/0x4f [ 95.444404] Code: 4f 70 50 8b 87 c0 00 00 00 50 8b 87 bc 00 00 00 50 ff b7 d0 00 00 00 4c 8b 8f c8 00 00 00 48 c7 c7 68 e8 be 9f e8 63 58 f9 ff <0f> 0b 48 8b 14 24 48 c7 c1 d0 73 65 9f e8 a1 ff ff ff 48 8b 14 24 [ 95.447684] RSP: 0018:ffffa13340274dd0 EFLAGS: 00010246 [ 95.448762] RAX: 0000000000000089 RBX: ffff8fbbc72b02d0 RCX: 000000000000083f [ 95.450148] RDX: 0000000000000000 RSI: 00000000000000f6 RDI: 000000000000083f [ 95.451520] RBP: 000000000000002d R08: 0000000000000000 R09: ffffa13340274c60 [ 95.452886] R10: ffffffffa04ed468 R11: 0000000000000002 R12: 0000000000000000 [ 95.454293] R13: ffff8fbbdab3c2d0 R14: ffff8fbbdbd829e0 R15: ffff8fbbdbd809e0 [ 95.455682] FS: 0000000000000000(0000) GS:ffff8fbeefd80000(0000) knlGS:0000000000000000 [ 95.457178] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 95.458340] CR2: 00007fd0d1f650c8 CR3: 0000000115f28000 CR4: 00000000000406f0 [ 95.459791] Call Trace: [ 95.460515] <IRQ> [ 95.461180] ? _diebody.cold+0x19/0x27 [ 95.462150] ? die+0x2e/0x50 [ 95.462976] ? dotrap+0xca/0x110 [ 95.463973] ? doerrortrap+0x6a/0x90 [ 95.464966] ? skbpanic+0x4d/0x4f [ 95.465901] ? excinvalidop+0x50/0x70 [ 95.466849] ? skbpanic+0x4d/0x4f [ 95.467718] ? asmexcinvalidop+0x1a/0x20 [ 95.468758] ? skbpanic+0x4d/0x4f [ 95.469655] skbput.cold+0x10/0x10 [ 95.470573] vmxnet3rqrxcomplete+0x862/0x11e0 [vmxnet3] [ 95.471853] vmxnet3pollrxonly+0x36/0xb0 [vmxnet3] [ 95.473185] _napipoll+0x2b/0x160 [ 95.474145] netrxaction+0x2c6/0x3b0 [ 95.475115] handlesoftirqs+0xe7/0x2a0 [ 95.476122] _irqexitrcu+0x97/0xb0 [ 95.477109] commoninterrupt+0x85/0xa0 [ 95.478102] </IRQ> [ 95.478846] <TASK> [ 95.479603] asmcommoninterrupt+0x26/0x40 [ 95.480657] RIP: 0010:pvnativesafehalt+0xf/0x20 [ 95.481801] Code: 22 d7 e9 54 87 01 00 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa eb 07 0f 00 2d 93 ba 3b 00 fb f4 <e9> 2c 87 01 00 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 [ 95.485563] RSP: 0018:ffffa133400ffe58 EFLAGS: 00000246 [ 95.486882] RAX: 0000000000004000 RBX: ffff8fbbc1d14064 RCX: 0000000000000000 [ 95.488477] RDX: ffff8fbeefd80000 RSI: ffff8fbbc1d14000 RDI: 0000000000000001 [ 95.490067] RBP: ffff8fbbc1d14064 R08: ffffffffa0652260 R09: 00000000000010d3 [ 95.491683] R10: 0000000000000018 R11: ffff8fbeefdb4764 R12: ffffffffa0652260 [ 95.493389] R13: ffffffffa06522e0 R14: 0000000000000001 R15: 0000000000000000 [ 95.495035] acpisafehalt+0x14/0x20 [ 95.496127] acpiidledoentry+0x2f/0x50 [ 95.497221] acpiidleenter+0x7f/0xd0 [ 95.498272] cpuidleenterstate+0x81/0x420 [ 95.499375] cpuidleenter+0x2d/0x40 [ 95.500400] doidle+0x1e5/0x240 [ 95.501385] cpustartupentry+0x29/0x30 [ 95.502422] startsecondary+0x11c/0x140 [ 95.503454] commonstartup64+0x13e/0x141 [ 95.504466] </TASK> [ 95.505197] Modules linked in: nftfibinet nftfibipv4 nftfibipv6 nftfib nftrejectinet nfrejectipv4 nfrejectipv6 nftreject nftct nftchainnat nfnat nfconntrack nfdefragip ---truncated---(CVE-2024-40923)

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

wifi: iwlwifi: mvm: check n_ssids before accessing the ssids

In some versions of cfg80211, the ssids poinet might be a valid one even though nssids is 0. Accessing the pointer in this case will cuase an out-of-bound access. Fix this by checking nssids first.(CVE-2024-40929)

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

drm/exynos/vidi: fix memory leak in .get_modes()

The duplicated EDID is never freed. Fix it.(CVE-2024-40932)

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

cxl/region: Fix memregion leaks in devmcxladd_region()

Move the mode verification to _createregion() before allocating the memregion to avoid the memregion leaks.(CVE-2024-40936)

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

wifi: iwlwifi: mvm: don't read past the mfuart notifcation

In case the firmware sends a notification that claims it has more data than it has, we will read past that was allocated for the notification. Remove the print of the buffer, we won't see it by default. If needed, we can see the content with tracing.

This was reported by KFENCE.(CVE-2024-40941)

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

ocfs2: fix races between hole punching and AIO+DIO

After commit "ocfs2: return real error code in ocfs2diowrgetblock", fstests/generic/300 become from always failed to sometimes failed:

======================================================================== [ 473.293420 ] run fstests generic/300

[ 475.296983 ] JBD2: Ignoring recovery information on journal [ 475.302473 ] ocfs2: Mounting device (253,1) on (node local, slot 0) with ordered data mode. [ 494.290998 ] OCFS2: ERROR (device dm-1): ocfs2changeextentflag: Owner 5668 has an extent at cpos 78723 which can no longer be found [ 494.291609 ] On-disk corruption discovered. Please run fsck.ocfs2 once the filesystem is unmounted. [ 494.292018 ] OCFS2: File system is now read-only. [ 494.292224 ] (kworker/19:11,2628,19):ocfs2markextentwritten:5272 ERROR: status = -30 [ 494.292602 ] (kworker/19:11,2628,19):ocfs2dioendiowrite:2374 ERROR: status = -3

fio: io_u error on file /mnt/scratch/racer: Read-only file system: write offset=460849152, buflen=131072

In _blockdevdirectIO, ocfs2diowrgetblock is called to add unwritten extents to a list. extents are also inserted into extent tree in ocfs2writebeginnolock. Then another thread call fallocate to puch a hole at one of the unwritten extent. The extent at cpos was removed by ocfs2removeextent(). At end io worker thread, ocfs2searchextent_list found there is no such extent at the cpos.

T1                        T2                T3
                          inode lock
                            ...
                            insert extents
                            ...
                          inode unlock

ocfs2fallocate _ocfs2changefilespace inode lock lock ipallocsem ocfs2removeinoderange inode ocfs2removebtreerange ocfs2removeextent ^---remove the extent at cpos 78723 ... unlock ipallocsem inode unlock ocfs2dioendio ocfs2dioendiowrite lock ipallocsem ocfs2markextentwritten ocfs2changeextentflag ocfs2searchextentlist ^---failed to find extent ... unlock ipalloc_sem

In most filesystems, fallocate is not compatible with racing with AIO+DIO, so fix it by adding to wait for all dio before fallocate/punch_hole like ext4.(CVE-2024-40943)

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

ocfs2: fix NULL pointer dereference in ocfs2aborttrigger()

bdev->bdsuper has been removed and commit 8887b94d9322 change the usage from bdev->bdsuper to bassocmap->host->isb. Since ocfs2 hasn't set bh->bassocmap, it will trigger NULL pointer dereference when calling into ocfs2abort_trigger().

Actually this was pointed out in history, see commit 74e364ad1b13. But I've made a mistake when reviewing commit 8887b94d9322 and then re-introduce this regression.

Since we cannot revive bdev in buffer head, so fix this issue by initializing all types of ocfs2 triggers when fill super, and then get the specific ocfs2 trigger from ocfs2cachinginfo when access journal.

[joseph.qi@linux.alibaba.com: v2] Link: https://lkml.kernel.org/r/20240602112045.1112708-1-joseph.qi@linux.alibaba.com(CVE-2024-40951)

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

ocfs2: fix NULL pointer dereference in ocfs2journaldirty()

bdev->bdsuper has been removed and commit 8887b94d9322 change the usage from bdev->bdsuper to bassocmap->host->isb. This introduces the following NULL pointer dereference in ocfs2journaldirty() since bassoc_map is still not initialized. This can be easily reproduced by running xfstests generic/186, which simulate no more credits.

[ 134.351592] BUG: kernel NULL pointer dereference, address: 0000000000000000 ... [ 134.355341] RIP: 0010:ocfs2journaldirty+0x14f/0x160 [ocfs2] ... [ 134.365071] Call Trace: [ 134.365312] <TASK> [ 134.365524] ? _diebody+0x1e/0x60 [ 134.365868] ? pagefaultoops+0x13d/0x4f0 [ 134.366265] ? _pfxbitwaitio+0x10/0x10 [ 134.366659] ? schedule+0x27/0xb0 [ 134.366981] ? excpagefault+0x6a/0x140 [ 134.367356] ? asmexcpagefault+0x26/0x30 [ 134.367762] ? ocfs2journaldirty+0x14f/0x160 [ocfs2] [ 134.368305] ? ocfs2journaldirty+0x13d/0x160 [ocfs2] [ 134.368837] ocfs2createnewmetabhs.isra.51+0x139/0x2e0 [ocfs2] [ 134.369454] ocfs2growtree+0x688/0x8a0 [ocfs2] [ 134.369927] ocfs2splitandinsert.isra.67+0x35c/0x4a0 [ocfs2] [ 134.370521] ocfs2splitextent+0x314/0x4d0 [ocfs2] [ 134.371019] ocfs2changeextentflag+0x174/0x410 [ocfs2] [ 134.371566] ocfs2addrefcountflag+0x3fa/0x630 [ocfs2] [ 134.372117] ocfs2reflinkremapextent+0x21b/0x4c0 [ocfs2] [ 134.372994] ? inodeupdatetimestamps+0x4a/0x120 [ 134.373692] ? _pfxocfs2journalaccessdi+0x10/0x10 [ocfs2] [ 134.374545] ? _pfxocfs2journalaccessdi+0x10/0x10 [ocfs2] [ 134.375393] ocfs2reflinkremapblocks+0xe4/0x4e0 [ocfs2] [ 134.376197] ocfs2remapfilerange+0x1de/0x390 [ocfs2] [ 134.376971] ? securityfilepermission+0x29/0x50 [ 134.377644] vfsclonefilerange+0xfe/0x320 [ 134.378268] ioctlfileclone+0x45/0xa0 [ 134.378853] dovfsioctl+0x457/0x990 [ 134.379422] _x64sysioctl+0x6e/0xd0 [ 134.379987] dosyscall64+0x5d/0x170 [ 134.380550] entrySYSCALL64afterhwframe+0x76/0x7e [ 134.381231] RIP: 0033:0x7fa4926397cb [ 134.381786] Code: 73 01 c3 48 8b 0d bd 56 38 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8d 56 38 00 f7 d8 64 89 01 48 [ 134.383930] RSP: 002b:00007ffc2b39f7b8 EFLAGS: 00000246 ORIGRAX: 0000000000000010 [ 134.384854] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fa4926397cb [ 134.385734] RDX: 00007ffc2b39f7f0 RSI: 000000004020940d RDI: 0000000000000003 [ 134.386606] RBP: 0000000000000000 R08: 00111a82a4f015bb R09: 00007fa494221000 [ 134.387476] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 134.388342] R13: 0000000000f10000 R14: 0000558e844e2ac8 R15: 0000000000f10000 [ 134.389207] </TASK>

Fix it by only aborting transaction and journal in ocfs2journaldirty() now, and leave ocfs2_abort() later when detecting an aborted handle, e.g. start next transaction. Also log the handle details in this case.(CVE-2024-40952)

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

seg6: fix parameter passing when calling NF_HOOK() in End.DX4 and End.DX6 behaviors

inputactionenddx4() and inputactionenddx6() are called NFHOOK() for PREROUTING hook, in PREROUTING hook, we should passing a valid indev, and a NULL outdev to NFHOOK(), otherwise may trigger a NULL pointer dereference, as below:

[74830.647293] BUG: kernel NULL pointer dereference, address: 0000000000000090
[74830.655633] #PF: supervisor read access in kernel mode
[74830.657888] #PF: error_code(0x0000) - not-present page
[74830.659500] PGD 0 P4D 0
[74830.660450] Oops: 0000 [#1] PREEMPT SMP PTI
...
[74830.664953] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
[74830.666569] RIP: 0010:rpfilter_mt+0x44/0x15e [ipt_rpfilter]
...
[74830.689725] Call Trace:
[74830.690402]  <IRQ>
[74830.690953]  ? show_trace_log_lvl+0x1c4/0x2df
[74830.692020]  ? show_trace_log_lvl+0x1c4/0x2df
[74830.693095]  ? ipt_do_table+0x286/0x710 [ip_tables]
[74830.694275]  ? __die_body.cold+0x8/0xd
[74830.695205]  ? page_fault_oops+0xac/0x140
[74830.696244]  ? exc_page_fault+0x62/0x150
[74830.697225]  ? asm_exc_page_fault+0x22/0x30
[74830.698344]  ? rpfilter_mt+0x44/0x15e [ipt_rpfilter]
[74830.699540]  ipt_do_table+0x286/0x710 [ip_tables]
[74830.700758]  ? ip6_route_input+0x19d/0x240
[74830.701752]  nf_hook_slow+0x3f/0xb0
[74830.702678]  input_action_end_dx4+0x19b/0x1e0
[74830.703735]  ? input_action_end_t+0xe0/0xe0
[74830.704734]  seg6_local_input_core+0x2d/0x60
[74830.705782]  lwtunnel_input+0x5b/0xb0
[74830.706690]  __netif_receive_skb_one_core+0x63/0xa0
[74830.707825]  process_backlog+0x99/0x140
[74830.709538]  __napi_poll+0x2c/0x160
[74830.710673]  net_rx_action+0x296/0x350
[74830.711860]  __do_softirq+0xcb/0x2ac
[74830.713049]  do_softirq+0x63/0x90

inputactionenddx4() passing a NULL indev to NFHOOK(), and finally trigger a NULL dereference in rpfiltermt()->rpfilteris_loopback():

static bool
rpfilter_is_loopback(const struct sk_buff *skb,
               const struct net_device *in)
{
        // in is NULL
        return skb->pkt_type == PACKET_LOOPBACK ||
         in->flags & IFF_LOOPBACK;
}(CVE-2024-40957)

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

MIPS: Octeon: Add PCIe link status check

The standard PCIe configuration read-write interface is used to access the configuration space of the peripheral PCIe devices of the mips processor after the PCIe link surprise down, it can generate kernel panic caused by "Data bus error". So it is necessary to add PCIe link status check for system protection. When the PCIe link is down or in training, assigning a value of 0 to the configuration address can prevent read-write behavior to the configuration space of peripheral PCIe devices, thereby preventing kernel panic.(CVE-2024-40968)

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

powerpc/pseries: Enforce hcall result buffer validity and size

plparhcall(), plparhcall9(), and related functions expect callers to provide valid result buffers of certain minimum size. Currently this is communicated only through comments in the code and the compiler has no idea.

For example, if I write a bug like this:

long retbuf[PLPARHCALLBUFSIZE]; // should be PLPARHCALL9BUFSIZE plparhcall9(HALLOCATEVASWINDOW, retbuf, ...);

This compiles with no diagnostics emitted, but likely results in stack corruption at runtime when plpar_hcall9() stores results past the end of the array. (To be clear this is a contrived example and I have not found a real instance yet.)

To make this class of error less likely, we can use explicitly-sized array parameters instead of pointers in the declarations for the hcall APIs. When compiled with -Warray-bounds[1], the code above now provokes a diagnostic like this:

error: array argument is too small; is of size 32, callee requires at least 72 [-Werror,-Warray-bounds] 60 | plparhcall9(HALLOCATEVASWINDOW, retbuf, | ^ ~~~~~~

[1] Enabled for LLVM builds but not GCC for now. See commit 0da6e5fd6c37 ("gcc: disable '-Warray-bounds' for gcc-13 too") and related changes.(CVE-2024-40974)

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

platform/x86: x86-android-tablets: Unregister devices in reverse order

Not all subsystems support a device getting removed while there are still consumers of the device with a reference to the device.

One example of this is the regulator subsystem. If a regulator gets unregistered while there are still drivers holding a reference a WARN() at drivers/regulator/core.c:5829 triggers, e.g.:

WARNING: CPU: 1 PID: 1587 at drivers/regulator/core.c:5829 regulatorunregister Hardware name: Intel Corp. VALLEYVIEW C0 PLATFORM/BYT-T FFD8, BIOS BLADE21.X64.0005.R00.1504101516 FFD8X64R201504101516 04/10/2015 RIP: 0010:regulatorunregister Call Trace: <TASK> regulatorunregister devresreleasegroup i2cdeviceremove devicereleasedriverinternal busremovedevice devicedel deviceunregister x86androidtabletremove

On the Lenovo Yoga Tablet 2 series the bq24190 charger chip also provides a 5V boost converter output for powering USB devices connected to the micro USB port, the bq24190-charger driver exports this as a Vbus regulator.

On the 830 (8") and 1050 ("10") models this regulator is controlled by a platformdevice and x86androidtabletremove() removes platformdevice-s before i2cclients so the consumer gets removed first.

But on the 1380 (13") model there is a lc824206xa micro-USB switch connected over I2C and the extcon driver for that controls the regulator. The bq24190 i2c-client must be registered first, because that creates the regulator with the lc824206xa listed as its consumer. If the regulator has not been registered yet the lc824206xa driver will end up getting a dummy regulator.

Since in this case both the regulator provider and consumer are I2C devices, the only way to ensure that the consumer is unregistered first is to unregister the I2C devices in reverse order of in which they were created.

For consistency and to avoid similar problems in the future change x86androidtablet_remove() to unregister all device types in reverse order.(CVE-2024-40975)

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

wifi: mt76: mt7921s: fix potential hung tasks during chip recovery

During chip recovery (e.g. chip reset), there is a possible situation that kernel worker resetwork is holding the lock and waiting for kernel thread statworker to be parked, while stat_worker is waiting for the release of the same lock. It causes a deadlock resulting in the dumping of hung tasks messages and possible rebooting of the device.

This patch prevents the execution of stat_worker during the chip recovery.(CVE-2024-40977)

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

tipc: force a dst refcount before doing decryption

As it says in commit 3bc07321ccc2 ("xfrm: Force a dst refcount before entering the xfrm type handlers"):

"Crypto requests might return asynchronous. In this case we leave the rcu protected region, so force a refcount on the skb's destination entry before we enter the xfrm type input/output handlers."

On TIPC decryption path it has the same problem, and skbdstforce() should be called before doing decryption to avoid a possible crash.

Shuang reported this issue when this warning is triggered:

[] WARNING: include/net/dst.h:337 tipcskrcv+0x1055/0x1ea0 [tipc] [] Kdump: loaded Tainted: G W --------- - - 4.18.0-496.el8.x8664+debug [] Workqueue: crypto cryptdqueueworker [] RIP: 0010:tipcskrcv+0x1055/0x1ea0 [tipc] [] Call Trace: [] tipcskmcastrcv+0x548/0xea0 [tipc] [] tipcrcv+0xcf5/0x1060 [tipc] [] tipcaeaddecryptdone+0x215/0x2e0 [tipc] [] cryptdaeadcrypt+0xdb/0x190 [] cryptdqueueworker+0xed/0x190 [] processonework+0x93d/0x17e0(CVE-2024-40983)

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

ACPICA: Revert "ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine."

Undo the modifications made in commit d410ee5109a1 ("ACPICA: avoid "Info: mapping multiple BARs. Your kernel is fine.""). The initial purpose of this commit was to stop memory mappings for operation regions from overlapping page boundaries, as it can trigger warnings if different page attributes are present.

However, it was found that when this situation arises, mapping continues until the boundary's end, but there is still an attempt to read/write the entire length of the map, leading to a NULL pointer deference. For example, if a four-byte mapping request is made but only one byte is mapped because it hits the current page boundary's end, a four-byte read/write attempt is still made, resulting in a NULL pointer deference.

Instead, map the entire length, as the ACPI specification does not mandate that it must be within the same page boundary. It is permissible for it to be mapped across different regions.(CVE-2024-40984)

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

drm/amdgpu: fix UBSAN warning in kv_dpm.c

Adds bounds check for sumovidmapping_entry.(CVE-2024-40987)

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

tracing: Build event generation tests only as modules

The kprobes and synth event generation test modules add events and lock (get a reference) those event file reference in module init function, and unlock and delete it in module exit function. This is because those are designed for playing as modules.

If we make those modules as built-in, those events are left locked in the kernel, and never be removed. This causes kprobe event self-test failure as below.

[ 97.349708] ------------[ cut here ]------------ [ 97.353453] WARNING: CPU: 3 PID: 1 at kernel/trace/tracekprobe.c:2133 kprobetraceselftestsinit+0x3f1/0x480 [ 97.357106] Modules linked in: [ 97.358488] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 6.9.0-g699646734ab5-dirty #14 [ 97.361556] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 97.363880] RIP: 0010:kprobetraceselftestsinit+0x3f1/0x480 [ 97.365538] Code: a8 24 08 82 e9 ae fd ff ff 90 0f 0b 90 48 c7 c7 e5 aa 0b 82 e9 ee fc ff ff 90 0f 0b 90 48 c7 c7 2d 61 06 82 e9 8e fd ff ff 90 <0f> 0b 90 48 c7 c7 33 0b 0c 82 89 c6 e8 6e 03 1f ff 41 ff c7 e9 90 [ 97.370429] RSP: 0000:ffffc90000013b50 EFLAGS: 00010286 [ 97.371852] RAX: 00000000fffffff0 RBX: ffff888005919c00 RCX: 0000000000000000 [ 97.373829] RDX: ffff888003f40000 RSI: ffffffff8236a598 RDI: ffff888003f40a68 [ 97.375715] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 [ 97.377675] R10: ffffffff811c9ae5 R11: ffffffff8120c4e0 R12: 0000000000000000 [ 97.379591] R13: 0000000000000001 R14: 0000000000000015 R15: 0000000000000000 [ 97.381536] FS: 0000000000000000(0000) GS:ffff88807dcc0000(0000) knlGS:0000000000000000 [ 97.383813] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 97.385449] CR2: 0000000000000000 CR3: 0000000002244000 CR4: 00000000000006b0 [ 97.387347] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 97.389277] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 97.391196] Call Trace: [ 97.391967] <TASK> [ 97.392647] ? _warn+0xcc/0x180 [ 97.393640] ? kprobetraceselftestsinit+0x3f1/0x480 [ 97.395181] ? reportbug+0xbd/0x150 [ 97.396234] ? handlebug+0x3e/0x60 [ 97.397311] ? excinvalidop+0x1a/0x50 [ 97.398434] ? asmexcinvalidop+0x1a/0x20 [ 97.399652] ? tracekprobeisbusy+0x20/0x20 [ 97.400904] ? tracingresetallonlinecpus+0x15/0x90 [ 97.402304] ? kprobetraceselftestsinit+0x3f1/0x480 [ 97.403773] ? initkprobetrace+0x50/0x50 [ 97.404972] dooneinitcall+0x112/0x240 [ 97.406113] doinitcalllevel+0x95/0xb0 [ 97.407286] ? kernelinit+0x1a/0x1a0 [ 97.408401] doinitcalls+0x3f/0x70 [ 97.409452] kernelinitfreeable+0x16f/0x1e0 [ 97.410662] ? restinit+0x1f0/0x1f0 [ 97.411738] kernelinit+0x1a/0x1a0 [ 97.412788] retfromfork+0x39/0x50 [ 97.413817] ? restinit+0x1f0/0x1f0 [ 97.414844] retfromforkasm+0x11/0x20 [ 97.416285] </TASK> [ 97.417134] irq event stamp: 13437323 [ 97.418376] hardirqs last enabled at (13437337): [<ffffffff8110bc0c>] consoleunlock+0x11c/0x150 [ 97.421285] hardirqs last disabled at (13437370): [<ffffffff8110bbf1>] consoleunlock+0x101/0x150 [ 97.423838] softirqs last enabled at (13437366): [<ffffffff8108e17f>] handlesoftirqs+0x23f/0x2a0 [ 97.426450] softirqs last disabled at (13437393): [<ffffffff8108e346>] _irqexitrcu+0x66/0xd0 [ 97.428850] ---[ end trace 0000000000000000 ]---

And also, since we can not cleanup dynamic_event file, ftracetest are failed too.

To avoid these issues, build these tests only as modules.(CVE-2024-41004)

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

netpoll: Fix race condition in netpollowneractive

KCSAN detected a race condition in netpoll:

BUG: KCSAN: data-race in net_rx_action / netpoll_send_skb
write (marked) to 0xffff8881164168b0 of 4 bytes by interrupt on cpu 10:
net_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822)

<snip> read to 0xffff8881164168b0 of 4 bytes by task 1 on cpu 2: netpollsendskb (net/core/netpoll.c:319 net/core/netpoll.c:345 net/core/netpoll.c:393) netpollsendudp (net/core/netpoll.c:?) <snip> value changed: 0x0000000a -> 0xffffffff

This happens because netpollowneractive() needs to check if the current CPU is the owner of the lock, touching napi->pollowner non atomically. The ->pollowner field contains the current CPU holding the lock.

Use an atomic read to check if the poll owner is the current CPU.(CVE-2024-41005)

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

tcp: avoid too many retransmit packets

If a TCP socket is using TCPUSERTIMEOUT, and the other peer retracted its window to zero, tcpretransmittimer() can retransmit a packet every two jiffies (2 ms for HZ=1000), for about 4 minutes after TCPUSERTIMEOUT has 'expired'.

The fix is to make sure tcprtxprobe0timedout() takes icsk->icskusertimeout into account.

Before blamed commit, the socket would not timeout after icsk->icskusertimeout, but would use standard exponential backoff for the retransmits.

Also worth noting that before commit e89688e3e978 ("net: tcp: fix unexcepted socket die when snd_wnd is 0"), the issue would last 2 minutes instead of 4.(CVE-2024-41007)

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

bpf: Fix overrunning reservations in ringbuf

The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumerpos is the consumer counter to show which logical position the consumer consumed the data, and producerpos which is the producer counter denoting the amount of data reserved by all producers.

Each time a record is reserved, the producer that "owns" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write.

One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory.

Each record has a struct bpfringbufhdr { u32 len; u32 pgoff; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpfringbuf_reserve() return (void *)hdr + BPF_RINGBUF_HDR_SZ for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header.

For example, consider the creation of a BPFMAPTYPERINGBUF map with size of 0x4000. Next, the consumerpos is modified to 0x3000 /before/ a call to bpfringbufreserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumerpos was edited ahead of time to pass the new_prod_pos - cons_pos > rb->mask check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpfringbufsubmit() / bpfringbufdiscard() use the header's pgoff to then locate the bpfringbuf itself via bpfringbufrestorefromrec(). Once chunk B modified chunk A's header, then bpfringbuf_commit() refers to the wrong page and could cause a crash.

Fix it by calculating the oldest pendingpos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/runbench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter.(CVE-2024-41009)