The Linux Kernel, the operating system core itself.

Security Fix(es):

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

mlxsw: spectrumacltcam: Fix stack corruption

When tc filters are first added to a net device, the corresponding local port gets bound to an ACL group in the device. The group contains a list of ACLs. In turn, each ACL points to a different TCAM region where the filters are stored. During forwarding, the ACLs are sequentially evaluated until a match is found.

One reason to place filters in different regions is when they are added with decreasing priorities and in an alternating order so that two consecutive filters can never fit in the same region because of their key usage.

In Spectrum-2 and newer ASICs the firmware started to report that the maximum number of ACLs in a group is more than 16, but the layout of the register that configures ACL groups (PAGT) was not updated to account for that. It is therefore possible to hit stack corruption [1] in the rare case where more than 16 ACLs in a group are required.

Fix by limiting the maximum ACL group size to the minimum between what the firmware reports and the maximum ACLs that fit in the PAGT register.

Add a test case to make sure the machine does not crash when this condition is hit.

[1] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxswspacltcamgroupupdate+0x116/0x120 [...] dumpstacklvl+0x36/0x50 panic+0x305/0x330 stackchkfail+0x15/0x20 mlxswspacltcamgroupupdate+0x116/0x120 mlxswspacltcamgroupregionattach+0x69/0x110 mlxswspacltcamvchunkget+0x492/0xa20 mlxswspacltcamventryadd+0x25/0xe0 mlxswspaclruleadd+0x47/0x240 mlxswspflowerreplace+0x1a9/0x1d0 tcsetupcbadd+0xdc/0x1c0 flhwreplacefilter+0x146/0x1f0 flchange+0xc17/0x1360 tcnewtfilter+0x472/0xb90 rtnetlinkrcvmsg+0x313/0x3b0 netlinkrcvskb+0x58/0x100 netlinkunicast+0x244/0x390 netlinksendmsg+0x1e4/0x440 syssendmsg+0x164/0x260 _syssendmsg+0x9a/0xe0 _syssendmsg+0x7a/0xc0 dosyscall64+0x40/0xe0 entrySYSCALL64afterhwframe+0x63/0x6b(CVE-2024-26586)

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

KVM: arm64: vgic-its: Avoid potential UAF in LPI translation cache

There is a potential UAF scenario in the case of an LPI translation cache hit racing with an operation that invalidates the cache, such as a DISCARD ITS command. The root of the problem is that vgicitscheckcache() does not elevate the refcount on the vgicirq before dropping the lock that serializes refcount changes.

Have vgicitscheckcache() raise the refcount on the returned vgicirq and add the corresponding decrement after queueing the interrupt.(CVE-2024-26598)

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

net: relax socket state check at accept time.

Christoph reported the following splat:

WARNING: CPU: 1 PID: 772 at net/ipv4/afinet.c:761 inetaccept+0x1f4/0x4a0 Modules linked in: CPU: 1 PID: 772 Comm: syz-executor510 Not tainted 6.9.0-rc7-g7da7119fe22b #56 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 RIP: 0010:inetaccept+0x1f4/0x4a0 net/ipv4/afinet.c:759 Code: 04 38 84 c0 0f 85 87 00 00 00 41 c7 04 24 03 00 00 00 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ec b7 da fd <0f> 0b e9 7f fe ff ff e8 e0 b7 da fd 0f 0b e9 fe fe ff ff 89 d9 80 RSP: 0018:ffffc90000c2fc58 EFLAGS: 00010293 RAX: ffffffff836bdd14 RBX: 0000000000000000 RCX: ffff888104668000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: dffffc0000000000 R08: ffffffff836bdb89 R09: fffff52000185f64 R10: dffffc0000000000 R11: fffff52000185f64 R12: dffffc0000000000 R13: 1ffff92000185f98 R14: ffff88810754d880 R15: ffff8881007b7800 FS: 000000001c772880(0000) GS:ffff88811b280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb9fcf2e178 CR3: 00000001045d2002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> inetaccept+0x138/0x1d0 net/ipv4/afinet.c:786 doaccept+0x435/0x620 net/socket.c:1929 _sysaccept4file net/socket.c:1969 [inline] _sysaccept4+0x9b/0x110 net/socket.c:1999 _dosysaccept net/socket.c:2016 [inline] _sesysaccept net/socket.c:2013 [inline] _x64sysaccept+0x7d/0x90 net/socket.c:2013 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x58/0x100 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x76/0x7e RIP: 0033:0x4315f9 Code: fd ff 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 ab b4 fd ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007ffdb26d9c78 EFLAGS: 00000246 ORIGRAX: 000000000000002b RAX: ffffffffffffffda RBX: 0000000000400300 RCX: 00000000004315f9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004 RBP: 00000000006e1018 R08: 0000000000400300 R09: 0000000000400300 R10: 0000000000400300 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000040cdf0 R14: 000000000040ce80 R15: 0000000000000055 </TASK>

The reproducer invokes shutdown() before entering the listener status. After commit 94062790aedb ("tcp: defer shutdown(SENDSHUTDOWN) for TCPSYNRECV sockets"), the above causes the child to reach the accept syscall in FINWAIT1 status.

Eric noted we can relax the existing assertion in _inetaccept()(CVE-2024-36484)

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

Bluetooth: qca: add missing firmware sanity checks

Add the missing sanity checks when parsing the firmware files before downloading them to avoid accessing and corrupting memory beyond the vmalloced buffer.(CVE-2024-36880)

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

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

The devlink reload process will access the hardware resources, but the register operation is done before the hardware is initialized. So, processing the devlink reload during initialization may lead to kernel crash.

This patch fixes this by registering the devlink after hardware initialization.(CVE-2024-36900)

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

tcp: Use refcountincnotzero() in tcptwsk_unique().

Anderson Nascimento reported a use-after-free splat in tcptwskunique() with nice analysis.

Since commit ec94c2696f0b ("tcp/dccp: avoid one atomic operation for timewait hashdance"), inettwskhashdance() sets TIME-WAIT socket's sk_refcnt after putting it into ehash and releasing the bucket lock.

Thus, there is a small race window where other threads could try to reuse the port during connect() and call sockhold() in tcptwsk_unique() for the TIME-WAIT socket with zero refcnt.

If that happens, the refcnt taken by tcptwskunique() is overwritten and sock_put() will cause underflow, triggering a real use-after-free somewhere else.

To avoid the use-after-free, we need to use refcountincnotzero() in tcptwsk_unique() and give up on reusing the port if it returns false.

WARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcountwarnsaturate+0xe5/0x110 CPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x8664 #1 Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023 RIP: 0010:refcountwarnsaturate+0xe5/0x110 Code: 42 8e ff 0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea 01 01 e8 7b 42 8e ff <0f> 0b c3 cc cc cc cc 48 c7 c7 50 8f b7 82 c6 05 7a 13 ea 01 01 e8 RSP: 0018:ffffc90006b43b60 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027 RDX: ffff88807be218c8 RSI: 0000000000000001 RDI: ffff88807be218c0 RBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0 R10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84 R13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0 FS: 00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0 PKRU: 55555554 Call Trace: <TASK> ? refcountwarnsaturate+0xe5/0x110 ? warn+0x81/0x130 ? refcountwarnsaturate+0xe5/0x110 ? reportbug+0x171/0x1a0 ? refcountwarnsaturate+0xe5/0x110 ? handlebug+0x3c/0x80 ? excinvalidop+0x17/0x70 ? asmexcinvalidop+0x1a/0x20 ? refcountwarnsaturate+0xe5/0x110 tcptwskunique+0x186/0x190 _inetcheckestablished+0x176/0x2d0 _inethashconnect+0x74/0x7d0 ? _pfxinetcheckestablished+0x10/0x10 tcpv4connect+0x278/0x530 _inetstreamconnect+0x10f/0x3d0 inetstreamconnect+0x3a/0x60 _sysconnect+0xa8/0xd0 _x64sysconnect+0x18/0x20 dosyscall64+0x83/0x170 entrySYSCALL64afterhwframe+0x78/0x80 RIP: 0033:0x7f62c11a885d 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 a3 45 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007f62c1091e58 EFLAGS: 00000296 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000020ccb004 RCX: 00007f62c11a885d RDX: 0000000000000010 RSI: 0000000020ccb000 RDI: 0000000000000003 RBP: 00007f62c1091e90 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 00007f62c10926c0 R13: ffffffffffffff88 R14: 0000000000000000 R15: 00007ffe237885b0 </TASK>(CVE-2024-36904)

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

drm/amd/display: Skip on writeback when it's not applicable

[WHY] dynamic memory safety error detector (KASAN) catches and generates error messages "BUG: KASAN: slab-out-of-bounds" as writeback connector does not support certain features which are not initialized.

[HOW] Skip them when connector type is DRMMODECONNECTOR_WRITEBACK.(CVE-2024-36914)

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

nsh: Restore skb->{protocol,data,macheader} for outer header in nshgso_segment().

syzbot triggered various splats (see [0] and links) by a crafted GSO packet of VIRTIONETHDRGSOUDP layering the following protocols:

ETHP8021AD + ETHPNSH + ETHPIPV6 + IPPROTO_UDP

NSH can encapsulate IPv4, IPv6, Ethernet, NSH, and MPLS. As the inner protocol can be Ethernet, NSH GSO handler, nshgsosegment(), calls skbmacgso_segment() to invoke inner protocol GSO handlers.

nshgsosegment() does the following for the original skb before calling skbmacgso_segment()

1. reset skb->network_header
2. save the original skb->{macheaeder,maclen} in a local variable
3. pull the NSH header
4. resets skb->mac_header
5. set up skb->mac_len and skb->protocol for the inner protocol.

and does the following for the segmented skb

6. set ntohs(ETHPNSH) to skb->protocol
7. push the NSH header
8. restore skb->mac_header
9. set skb->macheader + maclen to skb->networkheader
   10. restore skb->maclen

There are two problems in 6-7 and 8-9.

(a) After 6 & 7, skb->data points to the NSH header, so the outer header (ETHP8021AD in this case) is stripped when skb is sent out of netdev.

Also, if NSH is encapsulated by NSH + Ethernet (so NSH-Ethernet-NSH), skbpull() in the first nshgsosegment() will make skb->data point to the middle of the outer NSH or Ethernet header because the Ethernet header is not pulled by the second nshgso_segment().

(b) While restoring skb->{macheader,networkheader} in 8 & 9, nshgsosegment() does not assume that the data in the linear buffer is shifted.

However, udp6ufofragment() could shift the data and change skb->mac_header accordingly as demonstrated by syzbot.

If this happens, even the restored skb->mac_header points to the middle of the outer header.

It seems nshgsosegment() has never worked with outer headers so far.

At the end of nshgsosegment(), the outer header must be restored for the segmented skb, instead of the NSH header.

To do that, let's calculate the outer header position relatively from the inner header and set skb->{data,mac_header,protocol} properly.

BUG: KMSAN: uninit-value in ipvlanxmitmodel3 drivers/net/ipvlan/ipvlancore.c:602 [inline] BUG: KMSAN: uninit-value in ipvlanqueuexmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlancore.c:668 ipvlanprocessoutbound drivers/net/ipvlan/ipvlancore.c:524 [inline] ipvlanxmitmodel3 drivers/net/ipvlan/ipvlancore.c:602 [inline] ipvlanqueuexmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlancore.c:668 ipvlanstartxmit+0x5c/0x1a0 drivers/net/ipvlan/ipvlanmain.c:222 _netdevstartxmit include/linux/netdevice.h:4989 [inline] netdevstartxmit include/linux/netdevice.h:5003 [inline] xmitone net/core/dev.c:3547 [inline] devhardstartxmit+0x244/0xa10 net/core/dev.c:3563 _devqueuexmit+0x33ed/0x51c0 net/core/dev.c:4351 devqueuexmit include/linux/netdevice.h:3171 [inline] packetxmit+0x9c/0x6b0 net/packet/afpacket.c:276 packetsnd net/packet/afpacket.c:3081 [inline] packetsendmsg+0x8aef/0x9f10 net/packet/afpacket.c:3113 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg net/socket.c:745 [inline] _syssendto+0x735/0xa10 net/socket.c:2191 _dosyssendto net/socket.c:2203 [inline] _sesyssendto net/socket.c:2199 [inline] _x64syssendto+0x125/0x1c0 net/socket.c:2199 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcf/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x63/0x6b

Uninit was created at: slabpostallochook mm/slub.c:3819 [inline] slaballocnode mm/slub.c:3860 [inline] _dokmallocnode mm/slub.c:3980 [inline] _kmallocnodetrackcaller+0x705/0x1000 mm/slub.c:4001 kmallocreserve+0x249/0x4a0 net/core/skbuff.c:582 _ ---truncated---(CVE-2024-36933)

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

bpf, skmsg: Fix NULL pointer dereference in skpsockskbingressenqueue

Fix NULL pointer data-races in skpsockskbingressenqueue() which syzbot reported [1].

[1] BUG: KCSAN: data-race in skpsockdrop / skpsockskbingressenqueue

write to 0xffff88814b3278b8 of 8 bytes by task 10724 on cpu 1: skpsockstopverdict net/core/skmsg.c:1257 [inline] skpsockdrop+0x13e/0x1f0 net/core/skmsg.c:843 skpsockput include/linux/skmsg.h:459 [inline] sockmapclose+0x1a7/0x260 net/core/sockmap.c:1648 unixrelease+0x4b/0x80 net/unix/afunix.c:1048 _sockrelease net/socket.c:659 [inline] sockclose+0x68/0x150 net/socket.c:1421 _fput+0x2c1/0x660 fs/filetable.c:422 _fputsync+0x44/0x60 fs/filetable.c:507 _dosysclose fs/open.c:1556 [inline] _sesysclose+0x101/0x1b0 fs/open.c:1541 _x64sysclose+0x1f/0x30 fs/open.c:1541 dosyscall64+0xd3/0x1d0 entrySYSCALL64after_hwframe+0x6d/0x75

read to 0xffff88814b3278b8 of 8 bytes by task 10713 on cpu 0: skpsockdataready include/linux/skmsg.h:464 [inline] skpsockskbingressenqueue+0x32d/0x390 net/core/skmsg.c:555 skpsockskbingressself+0x185/0x1e0 net/core/skmsg.c:606 skpsockverdictapply net/core/skmsg.c:1008 [inline] skpsockverdictrecv+0x3e4/0x4a0 net/core/skmsg.c:1202 unixreadskb net/unix/afunix.c:2546 [inline] unixstreamreadskb+0x9e/0xf0 net/unix/afunix.c:2682 skpsockverdictdataready+0x77/0x220 net/core/skmsg.c:1223 unixstreamsendmsg+0x527/0x860 net/unix/afunix.c:2339 socksendmsgnosec net/socket.c:730 [inline] socksendmsg+0x140/0x180 net/socket.c:745 syssendmsg+0x312/0x410 net/socket.c:2584 _syssendmsg net/socket.c:2638 [inline] _syssendmsg+0x1e9/0x280 net/socket.c:2667 _dosyssendmsg net/socket.c:2676 [inline] _sesyssendmsg net/socket.c:2674 [inline] _x64syssendmsg+0x46/0x50 net/socket.c:2674 dosyscall64+0xd3/0x1d0 entrySYSCALL64after_hwframe+0x6d/0x75

value changed: 0xffffffff83d7feb0 -> 0x0000000000000000

Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 10713 Comm: syz-executor.4 Tainted: G W 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024

Prior to this, commit 4cd12c6065df ("bpf, sockmap: Fix NULL pointer dereference in skpsockverdictdataready()") fixed one NULL pointer similarly due to no protection of saveddataready. Here is another different caller causing the same issue because of the same reason. So we should protect it with skcallbacklock read lock because the writer side in the skpsockdrop() uses "writelockbh(&sk->skcallbacklock);".

To avoid errors that could happen in future, I move those two pairs of lock into the skpsockdata_ready(), which is suggested by John Fastabend.(CVE-2024-36938)

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

RDMA/rxe: Fix seg fault in rxecompqueue_pkt

In rxecompqueuepkt() an incoming response packet skb is enqueued to the resppkts queue and then a decision is made whether to run the completer task inline or schedule it. Finally the skb is dereferenced to bump a 'hw' performance counter. This is wrong because if the completer task is already running in a separate thread it may have already processed the skb and freed it which can cause a seg fault. This has been observed infrequently in testing at high scale.

This patch fixes this by changing the order of enqueuing the packet until after the counter is accessed.(CVE-2024-38544)

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

eth: sungem: remove .ndopollcontroller to avoid deadlocks

Erhard reports netpoll warnings from sungem:

netpollsendskbondev(): eth0 enabled interrupts in poll (gemstartxmit+0x0/0x398) WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpollsendskb+0x1fc/0x20c

gempollcontroller() disables interrupts, which may sleep. We can't sleep in netpoll, it has interrupts disabled completely. Strangely, gempollcontroller() doesn't even poll the completions, and instead acts as if an interrupt has fired so it just schedules NAPI and exits. None of this has been necessary for years, since netpoll invokes NAPI directly.(CVE-2024-38597)

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

ext4: fix mbcacheentry's erefcnt leak in ext4xattrblockcache_find()

Syzbot reports a warning as follows:

============================================ WARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mbcachedestroy+0x224/0x290 Modules linked in: CPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7 RIP: 0010:mbcachedestroy+0x224/0x290 fs/mbcache.c:419 Call Trace: <TASK> ext4putsuper+0x6d4/0xcd0 fs/ext4/super.c:1375 genericshutdownsuper+0x136/0x2d0 fs/super.c:641 killblocksuper+0x44/0x90 fs/super.c:1675 ext4killsb+0x68/0xa0 fs/ext4/super.c:7327

[...]

This is because when finding an entry in ext4xattrblockcachefind(), if ext4sbbread() returns -ENOMEM, the ce's erefcnt, which has already grown in the _entryfind(), won't be put away, and eventually trigger the above issue in mbcache_destroy() due to reference count leakage.

So call mbcacheentry_put() on the -ENOMEM error branch as a quick fix.(CVE-2024-39276)

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

jfs: xattr: fix buffer overflow for invalid xattr

When an xattr size is not what is expected, it is printed out to the kernel log in hex format as a form of debugging. But when that xattr size is bigger than the expected size, printing it out can cause an access off the end of the buffer.

Fix this all up by properly restricting the size of the debug hex dump in the kernel log.(CVE-2024-40902)

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

tty: add the option to have a tty reject a new ldisc

... and use it to limit the virtual terminals to just NTTY. They are kind of special, and in particular, the "conwrite()" routine violates the "writes cannot sleep" rule that some ldiscs rely on.

This avoids the

BUG: sleeping function called from invalid context at kernel/printk/printk.c:2659

when NGSM has been attached to a virtual console, and gsmldwrite() calls conwrite() while holding a spinlock, and conwrite() then tries to get the console lock.(CVE-2024-40966)

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

ibmvnic: Add tx check to prevent skb leak

Below is a summary of how the driver stores a reference to an skb during transmit: txbuff[freemap[consumerindex]]->skb = newskb; freemap[consumerindex] = IBMVNICINVALIDMAP; consumerindex ++; Where variable data looks like this: freemap == [4, IBMVNICINVALIDMAP, IBMVNICINVALIDMAP, 0, 3] consumerindex^ txbuff == [skb=null, skb=<ptr>, skb=<ptr>, skb=null, skb=null]

The driver has checks to ensure that freemap[consumerindex] pointed to a valid index but there was no check to ensure that this index pointed to an unused/null skb address. So, if, by some chance, our freemap and txbuff lists become out of sync then we were previously risking an skb memory leak. This could then cause tcp congestion control to stop sending packets, eventually leading to ETIMEDOUT.

Therefore, add a conditional to ensure that the skb address is null. If not then warn the user (because this is still a bug that should be patched) and free the old pointer to prevent memleak/tcp problems.(CVE-2024-41066)

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

nvme: avoid double free special payload

If a discard request needs to be retried, and that retry may fail before a new special payload is added, a double free will result. Clear the RQFSPECIALLOAD when the request is cleaned.(CVE-2024-41073)

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

ata: libata-core: Fix double free on error

If e.g. the ataportalloc() call in atahostalloc() fails, we will jump to the errout label, which will call devresreleasegroup(). devresreleasegroup() will trigger a call to atahostrelease(). atahostrelease() calls kfree(host), so executing the kfree(host) in atahost_alloc() will lead to a double free:

kernel BUG at mm/slub.c:553! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:kfree+0x2cf/0x2f0 Code: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da RSP: 0018:ffffc90000f377f0 EFLAGS: 00010246 RAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320 RDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0 RBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780 R13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006 FS: 00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? _diebody.cold+0x19/0x27 ? die+0x2e/0x50 ? dotrap+0xca/0x110 ? doerrortrap+0x6a/0x90 ? kfree+0x2cf/0x2f0 ? excinvalidop+0x50/0x70 ? kfree+0x2cf/0x2f0 ? asmexcinvalidop+0x1a/0x20 ? atahostalloc+0xf5/0x120 [libata] ? atahostalloc+0xf5/0x120 [libata] ? kfree+0x2cf/0x2f0 atahostalloc+0xf5/0x120 [libata] atahostallocpinfo+0x14/0xa0 [libata] ahciinit_one+0x6c9/0xd20 [ahci]

Ensure that we will not call kfree(host) twice, by performing the kfree() only if the devresopengroup() call failed.(CVE-2024-41087)

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

can: mcp251xfd: fix infinite loop when xmit fails

When the mcp251xfdstartxmit() function fails, the driver stops processing messages, and the interrupt routine does not return, running indefinitely even after killing the running application.

Error messages: [ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfdstartxmit: -16 [ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, teftail=0x000017cf, tefhead=0x000017d0, tx_head=0x000017d3). ... and repeat forever.

The issue can be triggered when multiple devices share the same SPI interface. And there is concurrent access to the bus.

The problem occurs because txring->head increments even if mcp251xfdstartxmit() fails. Consequently, the driver skips one TX package while still expecting a response in mcp251xfdhandletefifone().

Resolve the issue by starting a workqueue to write the tx obj synchronously if err = -EBUSY. In case of another error, decrement tx_ring->head, remove skb from the echo stack, and drop the message.

mkl: use more imperative wording in patch description

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

netfilter: nftables: fully validate NFTDATA_VALUE on store to data registers

register store validation for NFTDATAVALUE is conditional, however, the datatype is always either NFTDATAVALUE or NFTDATAVERDICT. This only requires a new helper function to infer the register type from the set datatype so this conditional check can be removed. Otherwise, pointer to chain object can be leaked through the registers.(CVE-2024-42070)

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

powerpc: Avoid nmienter/nmiexit in real mode interrupt.

nmienter()/nmiexit() touches per cpu variables which can lead to kernel crash when invoked during real mode interrupt handling (e.g. early HMI/MCE interrupt handler) if percpu allocation comes from vmalloc area.

Early HMI/MCE handlers are called through DEFINEINTERRUPTHANDLERNMI() wrapper which invokes nmienter/nmiexit calls. We don't see any issue when percpu allocation is from the embedded first chunk. However with CONFIGNEEDPERCPUPAGEFIRST_CHUNK enabled there are chances where percpu allocation can come from the vmalloc area.

With kernel command line "percpualloc=page" we can force percpu allocation to come from vmalloc area and can see kernel crash in machinecheck_early:

[ 1.215714] NIP [c000000000e49eb4] rcunmienter+0x24/0x110 [ 1.215717] LR [c0000000000461a0] machinecheckearly+0xf0/0x2c0 [ 1.215719] --- interrupt: 200 [ 1.215720] [c000000fffd73180] [0000000000000000] 0x0 (unreliable) [ 1.215722] [c000000fffd731b0] [0000000000000000] 0x0 [ 1.215724] [c000000fffd73210] [c000000000008364] machinecheckearly_common+0x134/0x1f8

Fix this by avoiding use of nmienter()/nmiexit() in real mode if percpu first chunk is not embedded.(CVE-2024-42126)

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

drm/lima: fix shared irq handling on driver remove

lima uses a shared interrupt, so the interrupt handlers must be prepared to be called at any time. At driver removal time, the clocks are disabled early and the interrupts stay registered until the very end of the remove process due to the devm usage. This is potentially a bug as the interrupts access device registers which assumes clocks are enabled. A crash can be triggered by removing the driver in a kernel with CONFIGDEBUGSHIRQ enabled. This patch frees the interrupts at each lima device finishing callback so that the handlers are already unregistered by the time we fully disable clocks.(CVE-2024-42127)

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

mm: avoid overflows in dirty throttling logic

The dirty throttling logic is interspersed with assumptions that dirty limits in PAGESIZE units fit into 32-bit (so that various multiplications fit into 64-bits). If limits end up being larger, we will hit overflows, possible divisions by 0 etc. Fix these problems by never allowing so large dirty limits as they have dubious practical value anyway. For dirtybytes / dirtybackgroundbytes interfaces we can just refuse to set so large limits. For dirtyratio / dirtybackgroundratio it isn't so simple as the dirty limit is computed from the amount of available memory which can change due to memory hotplug etc. So when converting dirty limits from ratios to numbers of pages, we just don't allow the result to exceed UINTMAX.

This is root-only triggerable problem which occurs when the operator sets dirty limits to >16 TB.(CVE-2024-42131)

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

libceph: fix race between delayedwork() and cephmonc_stop()

The way the delayed work is handled in cephmoncstop() is prone to races with monfault() and possibly also finishhunting(). Both of these can requeue the delayed work which wouldn't be canceled by any of the following code in case that happens after canceldelayedworksync() runs -- _closesession() doesn't mess with the delayed work in order to avoid interfering with the hunting interval logic. This part was missed in commit b5d91704f53e ("libceph: behave in monfault() if cur_mon < 0") and use-after-free can still ensue on monc and objects that hang off of it, with monc->auth and monc->monmap being particularly susceptible to quickly being reused.

To fix this:

• clear monc->curmon and monc->hunting as part of closing the session in cephmonc_stop()
• bail from delayedwork() if monc->curmon is cleared, similar to how it's done in monfault() and finishhunting() (based on monc->hunting)
• call canceldelayedwork_sync() after the session is closed(CVE-2024-42232)

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

usb: gadget: configfs: Prevent OOB read/write in usbstringcopy()

Userspace provided string 's' could trivially have the length zero. Left unchecked this will firstly result in an OOB read in the form if (str[0 - 1] == '\n') followed closely by an OOB write in the form str[0 - 1] = '\0'`.

There is already a validating check to catch strings that are too long. Let's supply an additional check for invalid strings that are too short.(CVE-2024-42236)

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

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

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

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

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

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

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

drm/gma500: fix null pointer dereference in cdvintellvdsgetmodes

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

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

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

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

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

And replace sprintf with snprintf.

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