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:

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:

i40e: fix vf may be used uninitialized in this function warning

To fix the regression introduced by commit 52424f974bc5, which causes servers hang in very hard to reproduce conditions with resets races. Using two sources for the information is the root cause. In this function before the fix bumping v didn't mean bumping vf pointer. But the code used this variables interchangeably, so stale vf could point to different/not intended vf.

Remove redundant "v" variable and iterate via single VF pointer across whole function instead to guarantee VF pointer validity.(CVE-2024-36020)

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:

pinctrl: devicetree: fix refcount leak in pinctrldtto_map()

If we fail to allocate propname buffer, we need to drop the reference count we just took. Because the pinctrldtfree_maps() includes the droping operation, here we call it directly.(CVE-2024-36959)

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:

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:

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:

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:

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)