The Linux Kernel, the operating system core itself.

Security Fix(es):

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

ALSA: gus: fix null pointer dereference on pointer block

The pointer block return from sndgf1dmanextblock could be null, so there is a potential null pointer dereference issue. Fix this by adding a null check before dereference.(CVE-2021-47207)

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:

sched/membarrier: reduce the ability to hammer on sys_membarrier

On some systems, sys_membarrier can be very expensive, causing overall slowdowns for everything. So put a lock on the path in order to serialize the accesses to prevent the ability for this to be called at too high of a frequency and saturate the machine.(CVE-2024-26602)

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

tun: limit printing rate when illegal packet received by tun dev

vhostworker will call tun call backs to receive packets. If too many illegal packets arrives, tundo_read will keep dumping packet contents. When console is enabled, it will costs much more cpu time to dump packet and soft lockup will be detected.

net_ratelimit mechanism can be used to limit the dumping rate.

PID: 33036 TASK: ffff949da6f20000 CPU: 23 COMMAND: "vhost-32980" #0 [fffffe00003fce50] crashnmicallback at ffffffff89249253 #1 [fffffe00003fce58] nmihandle at ffffffff89225fa3 #2 [fffffe00003fceb0] defaultdonmi at ffffffff8922642e #3 [fffffe00003fced0] donmi at ffffffff8922660d #4 [fffffe00003fcef0] endrepeatnmi at ffffffff89c01663 [exception RIP: ioserialin+20] RIP: ffffffff89792594 RSP: ffffa655314979e8 RFLAGS: 00000002 RAX: ffffffff89792500 RBX: ffffffff8af428a0 RCX: 0000000000000000 RDX: 00000000000003fd RSI: 0000000000000005 RDI: ffffffff8af428a0 RBP: 0000000000002710 R8: 0000000000000004 R9: 000000000000000f R10: 0000000000000000 R11: ffffffff8acbf64f R12: 0000000000000020 R13: ffffffff8acbf698 R14: 0000000000000058 R15: 0000000000000000 ORIGRAX: ffffffffffffffff CS: 0010 SS: 0018 #5 [ffffa655314979e8] ioserialin at ffffffff89792594 #6 [ffffa655314979e8] waitforxmitr at ffffffff89793470 #7 [ffffa65531497a08] serial8250consoleputchar at ffffffff897934f6 #8 [ffffa65531497a20] uartconsolewrite at ffffffff8978b605 #9 [ffffa65531497a48] serial8250consolewrite at ffffffff89796558 #10 [ffffa65531497ac8] consoleunlock at ffffffff89316124 #11 [ffffa65531497b10] vprintkemit at ffffffff89317c07 #12 [ffffa65531497b68] printk at ffffffff89318306 #13 [ffffa65531497bc8] printhexdump at ffffffff89650765 #14 [ffffa65531497ca8] tundoread at ffffffffc0b06c27 [tun] #15 [ffffa65531497d38] tunrecvmsg at ffffffffc0b06e34 [tun] #16 [ffffa65531497d68] handlerx at ffffffffc0c5d682 [vhostnet] #17 [ffffa65531497ed0] vhostworker at ffffffffc0c644dc [vhost] #18 [ffffa65531497f10] kthread at ffffffff892d2e72 #19 [ffffa65531497f50] retfrom_fork at ffffffff89c0022f(CVE-2024-27013)

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

netfilter: nfnetlinkqueue: acquire rcureadlock() in instancedestroy_rcu()

syzbot reported that nfreinject() could be called without rcuread_lock() :

WARNING: suspicious RCU usage 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not tainted

net/netfilter/nfnetlinkqueue.c:263 suspicious rcudereference_check() usage!

other info that might help us debug this:

rcuscheduleractive = 2, debuglocks = 1 2 locks held by syz-executor.4/13427: #0: ffffffff8e334f60 (rcucallback){....}-{0:0}, at: rculockacquire include/linux/rcupdate.h:329 [inline] #0: ffffffff8e334f60 (rcucallback){....}-{0:0}, at: rcudobatch kernel/rcu/tree.c:2190 [inline] #0: ffffffff8e334f60 (rcucallback){....}-{0:0}, at: rcucore+0xa86/0x1830 kernel/rcu/tree.c:2471 #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: spinlockbh include/linux/spinlock.h:356 [inline] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: nfqnlflush net/netfilter/nfnetlinkqueue.c:405 [inline] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: instancedestroyrcu+0x30/0x220 net/netfilter/nfnetlinkqueue.c:172

stack backtrace: CPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/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 nfreinject net/netfilter/nfnetlinkqueue.c:323 [inline] nfqnlreinject+0x6ec/0x1120 net/netfilter/nfnetlinkqueue.c:397 nfqnlflush net/netfilter/nfnetlinkqueue.c:410 [inline] instancedestroyrcu+0x1ae/0x220 net/netfilter/nfnetlinkqueue.c:172 rcudobatch kernel/rcu/tree.c:2196 [inline] rcucore+0xafd/0x1830 kernel/rcu/tree.c:2471 handlesoftirqs+0x2d6/0x990 kernel/softirq.c:554 _dosoftirq kernel/softirq.c:588 [inline] invokesoftirq kernel/softirq.c:428 [inline] _irqexitrcu+0xf4/0x1c0 kernel/softirq.c:637 irqexitrcu+0x9/0x30 kernel/softirq.c:649 instrsysvecapictimerinterrupt arch/x86/kernel/apic/apic.c:1043 [inline] sysvecapictimerinterrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043 </IRQ> <TASK>(CVE-2024-36286)

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:

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:

wifi: ar5523: enable proper endpoint verification

Syzkaller reports [1] hitting a warning about an endpoint in use not having an expected type to it.

Fix the issue by checking for the existence of all proper endpoints with their according types intact.

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

[1] Syzkaller report: ------------[ cut here ]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usbsubmiturb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> ar5523cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275 ar5523cmdread drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline] ar5523hostavailable drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline] ar5523probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655 usbprobeinterface+0x30f/0x7f0 drivers/usb/core/driver.c:396 calldriverprobe drivers/base/dd.c:560 [inline] reallyprobe+0x249/0xb90 drivers/base/dd.c:639 _driverprobedevice+0x1df/0x4d0 drivers/base/dd.c:778 driverprobedevice+0x4c/0x1a0 drivers/base/dd.c:808 _deviceattachdriver+0x1d4/0x2e0 drivers/base/dd.c:936 busforeachdrv+0x163/0x1e0 drivers/base/bus.c:427 _deviceattach+0x1e4/0x530 drivers/base/dd.c:1008 busprobedevice+0x1e8/0x2a0 drivers/base/bus.c:487 deviceadd+0xbd9/0x1e90 drivers/base/core.c:3517 usbsetconfiguration+0x101d/0x1900 drivers/usb/core/message.c:2170 usbgenericdriverprobe+0xbe/0x100 drivers/usb/core/generic.c:238 usbprobedevice+0xd8/0x2c0 drivers/usb/core/driver.c:293 calldriverprobe drivers/base/dd.c:560 [inline] reallyprobe+0x249/0xb90 drivers/base/dd.c:639 _driverprobedevice+0x1df/0x4d0 drivers/base/dd.c:778 driverprobedevice+0x4c/0x1a0 drivers/base/dd.c:808 _deviceattachdriver+0x1d4/0x2e0 drivers/base/dd.c:936 busforeachdrv+0x163/0x1e0 drivers/base/bus.c:427 _deviceattach+0x1e4/0x530 drivers/base/dd.c:1008 busprobedevice+0x1e8/0x2a0 drivers/base/bus.c:487 deviceadd+0xbd9/0x1e90 drivers/base/core.c:3517 usbnewdevice.cold+0x685/0x10ad drivers/usb/core/hub.c:2573 hubportconnect drivers/usb/core/hub.c:5353 [inline] hubportconnectchange drivers/usb/core/hub.c:5497 [inline] portevent drivers/usb/core/hub.c:5653 [inline] hubevent+0x26cb/0x45d0 drivers/usb/core/hub.c:5735 processonework+0x9bf/0x1710 kernel/workqueue.c:2289 workerthread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 retfromfork+0x1f/0x30 arch/x86/entry/entry64.S:306 </TASK>(CVE-2024-38565)

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:

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:

crypto: aead,cipher - zeroize key buffer after use

I.G 9.7.B for FIPS 140-3 specifies that variables temporarily holding cryptographic information should be zeroized once they are no longer needed. Accomplish this by using kfree_sensitive for buffers that previously held the private key.(CVE-2024-42229)

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)