The Linux Kernel, the operating system core itself.

Security Fix(es):

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

s390/qeth: fix deadlock during failing recovery

Commit 0b9902c1fcc5 ("s390/qeth: fix deadlock during recovery") removed taking disciplinemutex inside qethdoreset(), fixing potential deadlocks. An error path was missed though, that still takes disciplinemutex and thus has the original deadlock potential.

Intermittent deadlocks were seen when a qeth channel path is configured offline, causing a race between qethdoreset and ccwgroupremove. Call qethsetoffline() directly in the qethdoreset() error case and then a new variant of ccwgroupsetoffline(), without taking disciplinemutex.(CVE-2021-47382)

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

drm/i915/gt: Cleanup partial engine discovery failures

If we abort driver initialisation in the middle of gt/engine discovery, some engines will be fully setup and some not. Those incompletely setup engines only have 'engine->release == NULL' and so will leak any of the common objects allocated.

v2: - Drop the destroypinnedcontext() helper for now. It's not really worth it with just a single callsite at the moment. (Janusz)(CVE-2022-48893)

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

usb: gadget: ncm: Fix handling of zero block length packets

While connecting to a Linux host with CDCNCMNTBDEFSIZE_TX set to 65536, it has been observed that we receive short packets, which come at interval of 5-10 seconds sometimes and have block length zero but still contain 1-2 valid datagrams present.

According to the NCM spec:

"If wBlockLength = 0x0000, the block is terminated by a short packet. In this case, the USB transfer must still be shorter than dwNtbInMaxSize or dwNtbOutMaxSize. If exactly dwNtbInMaxSize or dwNtbOutMaxSize bytes are sent, and the size is a multiple of wMaxPacketSize for the given pipe, then no ZLP shall be sent.

wBlockLength= 0x0000 must be used with extreme care, because of the possibility that the host and device may get out of sync, and because of test issues.

wBlockLength = 0x0000 allows the sender to reduce latency by starting to send a very large NTB, and then shortening it when the sender discovers that there’s not sufficient data to justify sending a large NTB"

However, there is a potential issue with the current implementation, as it checks for the occurrence of multiple NTBs in a single giveback by verifying if the leftover bytes to be processed is zero or not. If the block length reads zero, we would process the same NTB infintely because the leftover bytes is never zero and it leads to a crash. Fix this by bailing out if block length reads zero.(CVE-2024-35825)

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

ipv6: fix race condition between ipv6getifaddr and ipv6deladdr

Although ipv6getifaddr walks inet6addrlst under the RCU lock, it still means hlistforeachentryrcu can return an item that got removed from the list. The memory itself of such item is not freed thanks to RCU but nothing guarantees the actual content of the memory is sane.

In particular, the reference count can be zero. This can happen if ipv6deladdr is called in parallel. ipv6deladdr removes the entry from inet6addrlst (hlistdelinitrcu(&ifp->addrlst)) and drops all references (_in6ifaput(ifp) + in6ifa_put(ifp)). With bad enough timing, this can happen:

1. In ipv6getifaddr, hlistforeachentryrcu returns an entry.

2. Then, the whole ipv6deladdr is executed for the given entry. The reference count drops to zero and kfree_rcu is scheduled.

3. ipv6getifaddr continues and tries to increments the reference count (in6ifahold).

4. The rcu is unlocked and the entry is freed.

5. The freed entry is returned.

Prevent increasing of the reference count in such case. The name in6ifaholdsafe is chosen to mimic the existing fib6infoholdsafe.

[ 41.506330] refcountt: addition on 0; use-after-free. [ 41.506760] WARNING: CPU: 0 PID: 595 at lib/refcount.c:25 refcountwarnsaturate+0xa5/0x130 [ 41.507413] Modules linked in: veth bridge stp llc [ 41.507821] CPU: 0 PID: 595 Comm: python3 Not tainted 6.9.0-rc2.main-00208-g49563be82afa #14 [ 41.508479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) [ 41.509163] RIP: 0010:refcountwarnsaturate+0xa5/0x130 [ 41.509586] Code: ad ff 90 0f 0b 90 90 c3 cc cc cc cc 80 3d c0 30 ad 01 00 75 a0 c6 05 b7 30 ad 01 01 90 48 c7 c7 38 cc 7a 8c e8 cc 18 ad ff 90 <0f> 0b 90 90 c3 cc cc cc cc 80 3d 98 30 ad 01 00 0f 85 75 ff ff ff [ 41.510956] RSP: 0018:ffffbda3c026baf0 EFLAGS: 00010282 [ 41.511368] RAX: 0000000000000000 RBX: ffff9e9c46914800 RCX: 0000000000000000 [ 41.511910] RDX: ffff9e9c7ec29c00 RSI: ffff9e9c7ec1c900 RDI: ffff9e9c7ec1c900 [ 41.512445] RBP: ffff9e9c43660c9c R08: 0000000000009ffb R09: 00000000ffffdfff [ 41.512998] R10: 00000000ffffdfff R11: ffffffff8ca58a40 R12: ffff9e9c4339a000 [ 41.513534] R13: 0000000000000001 R14: ffff9e9c438a0000 R15: ffffbda3c026bb48 [ 41.514086] FS: 00007fbc4cda1740(0000) GS:ffff9e9c7ec00000(0000) knlGS:0000000000000000 [ 41.514726] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 41.515176] CR2: 000056233b337d88 CR3: 000000000376e006 CR4: 0000000000370ef0 [ 41.515713] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 41.516252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 41.516799] Call Trace: [ 41.517037] <TASK> [ 41.517249] ? _warn+0x7b/0x120 [ 41.517535] ? refcountwarnsaturate+0xa5/0x130 [ 41.517923] ? reportbug+0x164/0x190 [ 41.518240] ? handlebug+0x3d/0x70 [ 41.518541] ? excinvalidop+0x17/0x70 [ 41.520972] ? asmexcinvalidop+0x1a/0x20 [ 41.521325] ? refcountwarnsaturate+0xa5/0x130 [ 41.521708] ipv6getifaddr+0xda/0xe0 [ 41.522035] inet6rtmgetaddr+0x342/0x3f0 [ 41.522376] ? _pfxinet6rtmgetaddr+0x10/0x10 [ 41.522758] rtnetlinkrcvmsg+0x334/0x3d0 [ 41.523102] ? netlinkunicast+0x30f/0x390 [ 41.523445] ? _pfxrtnetlinkrcvmsg+0x10/0x10 [ 41.523832] netlinkrcvskb+0x53/0x100 [ 41.524157] netlinkunicast+0x23b/0x390 [ 41.524484] netlinksendmsg+0x1f2/0x440 [ 41.524826] _syssendto+0x1d8/0x1f0 [ 41.525145] _x64syssendto+0x1f/0x30 [ 41.525467] dosyscall64+0xa5/0x1b0 [ 41.525794] entrySYSCALL64after_hwframe+0x72/0x7a [ 41.526213] RIP: 0033:0x7fbc4cfcea9a [ 41.526528] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 [ 41.527942] RSP: 002b:00007f ---truncated---(CVE-2024-35969)

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

netfilter: nf_tables: honor table dormant flag from netdev release event path

Check for table dormant flag otherwise netdev release event path tries to unregister an already unregistered hook.

[524854.857999] ------------[ cut here ]------------ [524854.858010] WARNING: CPU: 0 PID: 3386599 at net/netfilter/core.c:501 nfunregisternethook+0x21a/0x260 [...] [524854.858848] CPU: 0 PID: 3386599 Comm: kworker/u32:2 Not tainted 6.9.0-rc3+ #365 [524854.858869] Workqueue: netns cleanupnet [524854.858886] RIP: 0010:nfunregisternethook+0x21a/0x260 [524854.858903] Code: 24 e8 aa 73 83 ff 48 63 43 1c 83 f8 01 0f 85 3d ff ff ff e8 98 d1 f0 ff 48 8b 3c 24 e8 8f 73 83 ff 48 63 43 1c e9 26 ff ff ff <0f> 0b 48 83 c4 18 48 c7 c7 00 68 e9 82 5b 5d 41 5c 41 5d 41 5e 41 [524854.858914] RSP: 0018:ffff8881e36d79e0 EFLAGS: 00010246 [524854.858926] RAX: 0000000000000000 RBX: ffff8881339ae790 RCX: ffffffff81ba524a [524854.858936] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881c8a16438 [524854.858945] RBP: ffff8881c8a16438 R08: 0000000000000001 R09: ffffed103c6daf34 [524854.858954] R10: ffff8881e36d79a7 R11: 0000000000000000 R12: 0000000000000005 [524854.858962] R13: ffff8881c8a16000 R14: 0000000000000000 R15: ffff8881351b5a00 [524854.858971] FS: 0000000000000000(0000) GS:ffff888390800000(0000) knlGS:0000000000000000 [524854.858982] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [524854.858991] CR2: 00007fc9be0f16f4 CR3: 00000001437cc004 CR4: 00000000001706f0 [524854.859000] Call Trace: [524854.859006] <TASK> [524854.859013] ? _warn+0x9f/0x1a0 [524854.859027] ? _nfunregisternethook+0x21a/0x260 [524854.859044] ? reportbug+0x1b1/0x1e0 [524854.859060] ? handlebug+0x3c/0x70 [524854.859071] ? excinvalidop+0x17/0x40 [524854.859083] ? asmexcinvalidop+0x1a/0x20 [524854.859100] ? _nfunregisternethook+0x6a/0x260 [524854.859116] ? _nfunregisternethook+0x21a/0x260 [524854.859135] nftablesnetdevevent+0x337/0x390 [nftables] [524854.859304] ? _pfxnftablesnetdevevent+0x10/0x10 [nftables] [524854.859461] ? packetnotifier+0xb3/0x360 [524854.859476] ? rawspinunlockirqrestore+0x11/0x40 [524854.859489] ? dcbnlnetdeviceevent+0x35/0x140 [524854.859507] ? _pfxnftablesnetdevevent+0x10/0x10 [nftables] [524854.859661] notifiercallchain+0x7d/0x140 [524854.859677] unregisternetdevicemany_notify+0x5e1/0xae0(CVE-2024-36005)

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:

netfilter: tproxy: bail out if IP has been disabled on the device

syzbot reports: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] [..] RIP: 0010:nftproxyladdr4+0xb7/0x340 net/ipv4/netfilter/nftproxyipv4.c:62 Call Trace: nfttproxyevalv4 net/netfilter/nfttproxy.c:56 [inline] nfttproxyeval+0xa9a/0x1a00 net/netfilter/nft_tproxy.c:168

_indevgetrcu() can return NULL, so check for this.(CVE-2024-36270)

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:

nfc: llcp: fix nfcllcpsetsockopt() unsafe copies

syzbot reported unsafe calls to copyfromsockptr() [1]

Use copysafefrom_sockptr() instead.

[1]

BUG: KASAN: slab-out-of-bounds in copyfromsockptroffset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copyfromsockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in nfcllcpsetsockopt+0x6c2/0x850 net/nfc/llcpsock.c:255 Read of size 4 at addr ffff88801caa1ec3 by task syz-executor459/5078

CPU: 0 PID: 5078 Comm: syz-executor459 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:114 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x169/0x550 mm/kasan/report.c:488 kasanreport+0x143/0x180 mm/kasan/report.c:601 copyfromsockptroffset include/linux/sockptr.h:49 [inline] copyfromsockptr include/linux/sockptr.h:55 [inline] nfcllcpsetsockopt+0x6c2/0x850 net/nfc/llcpsock.c:255 dosocksetsockopt+0x3b1/0x720 net/socket.c:2311 _syssetsockopt+0x1ae/0x250 net/socket.c:2334 _dosyssetsockopt net/socket.c:2343 [inline] _sesyssetsockopt net/socket.c:2340 [inline] _x64syssetsockopt+0xb5/0xd0 net/socket.c:2340 dosyscall64+0xfd/0x240 entrySYSCALL64afterhwframe+0x6d/0x75 RIP: 0033:0x7f7fac07fd89 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 18 00 00 90 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 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff660eb788 EFLAGS: 00000246 ORIGRAX: 0000000000000036 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f7fac07fd89 RDX: 0000000000000000 RSI: 0000000000000118 RDI: 0000000000000004 RBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000000000 R10: 0000000020000a80 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000(CVE-2024-36915)

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

bna: ensure the copied buf is NUL terminated

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

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

phonet: fix rtmphonetnotify() skb allocation

fill_route() stores three components in the skb:

• struct rtmsg
• RTA_DST (u8)
• RTA_OIF (u32)

Therefore, rtmphonetnotify() should use

NLMSGALIGN(sizeof(struct rtmsg)) + nlatotalsize(1) + nlatotal_size(4)(CVE-2024-36946)

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

drm: vc4: Fix possible null pointer dereference

In vc4hdmiaudioinit() ofget_address() may return NULL which is later dereferenced. Fix this bug by adding NULL check.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-38546)

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

scsi: bfa: Ensure the copied buf is NUL terminated

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

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

media: i2c: et8ek8: Don't strip remove function when driver is builtin

Using _exit for the remove function results in the remove callback being discarded with CONFIGVIDEO_ET8EK8=y. When such a device gets unbound (e.g. using sysfs or hotplug), the driver is just removed without the cleanup being performed. This results in resource leaks. Fix it by compiling in the remove callback unconditionally.

This also fixes a W=1 modpost warning:

WARNING: modpost: drivers/media/i2c/et8ek8/et8ek8: section mismatch in reference: et8ek8_i2c_driver+0x10 (section: .data) -> et8ek8_remove (section: .exit.text)(CVE-2024-38611)

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

m68k: Fix spinlock race in kernel thread creation

Context switching does take care to retain the correct lock owner across the switch from 'prev' to 'next' tasks. This does rely on interrupts remaining disabled for the entire duration of the switch.

This condition is guaranteed for normal process creation and context switching between already running processes, because both 'prev' and 'next' already have interrupts disabled in their saved copies of the status register.

The situation is different for newly created kernel threads. The status register is set to PSS in copythread(), which does leave the IPL at 0. Upon restoring the 'next' thread's status register in switchto() aka resume(), interrupts then become enabled prematurely. resume() then returns via retfromkernelthread() and scheduletail() where run queue lock is released (see finishtaskswitch() and finishlock_switch()).

A timer interrupt calling schedulertick() before the lock is released in finishtask_switch() will find the lock already taken, with the current task as lock owner. This causes a spinlock recursion warning as reported by Guenter Roeck.

As far as I can ascertain, this race has been opened in commit 533e6903bea0 ("m68k: split retfromfork(), simplify kernel_thread()") but I haven't done a detailed study of kernel history so it may well predate that commit.

Interrupts cannot be disabled in the saved status register copy for kernel threads (init will complain about interrupts disabled when finally starting user space). Disable interrupts temporarily when switching the tasks' register sets in resume().

Note that a simple oriw 0x700,%sr after restoring sr is not enough here - this leaves enough of a race for the 'spinlock recursion' warning to still be observed.

Tested on ARAnyM and qemu (Quadra 800 emulation).(CVE-2024-38613)

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

enic: Validate length of nl attributes in enicsetvf_port

enicsetvfport assumes that the nl attribute IFLAPORTPROFILE is of length PORTPROFILEMAX and that the nl attributes IFLAPORTINSTANCEUUID, IFLAPORTHOSTUUID are of length PORTUUIDMAX. These attributes are validated (in the function dosetlink in rtnetlink.c) using the nlapolicy iflaportpolicy. The policy defines IFLAPORTPROFILE as NLASTRING, IFLAPORTINSTANCEUUID as NLABINARY and IFLAPORTHOSTUUID as NLASTRING. That means that the length validation using the policy is for the max size of the attributes and not on exact size so the length of these attributes might be less than the sizes that enicsetvfport expects. This might cause an out of bands read access in the memcpys of the data of these attributes in enicsetvfport.(CVE-2024-38659)

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

um: Add winch to winch_handlers before registering winch IRQ

Registering a winch IRQ is racy, an interrupt may occur before the winch is added to the winch_handlers list.

If that happens, registerwinchirq() adds to that list a winch that is scheduled to be (or has already been) freed, causing a panic later in winch_cleanup().

Avoid the race by adding the winch to the winchhandlers list before registering the IRQ, and rolling back if umrequest_irq() fails.(CVE-2024-39292)

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:

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:

drm/radeon: fix UBSAN warning in kv_dpm.c

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

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

fs/ntfs3: Validate ff offset

This adds sanity checks for ff offset. There is a check on rt->first_free at first, but walking through by ff without any check. If the second ff is a large offset. We may encounter an out-of-bound read.(CVE-2024-41019)

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

net/sched: Fix UAF when resolving a clash

KASAN reports the following UAF:

BUG: KASAN: slab-use-after-free in tcfctflowtableprocessconn+0x12b/0x380 [actct] Read of size 1 at addr ffff888c07603600 by task handler130/6469

Call Trace: <IRQ> dumpstacklvl+0x48/0x70 printaddressdescription.constprop.0+0x33/0x3d0 printreport+0xc0/0x2b0 kasanreport+0xd0/0x120 _asanload1+0x6c/0x80 tcfctflowtableprocessconn+0x12b/0x380 [actct] tcfctact+0x886/0x1350 [actct] tcfactionexec+0xf8/0x1f0 flclassify+0x355/0x360 [clsflower] _tcfclassify+0x1fd/0x330 tcfclassify+0x21c/0x3c0 schhandleingress.constprop.0+0x2c5/0x500 _netifreceiveskbcore.constprop.0+0xb25/0x1510 _netifreceiveskblistcore+0x220/0x4c0 netifreceiveskblistinternal+0x446/0x620 napicompletedone+0x157/0x3d0 grocellpoll+0xcf/0x100 _napipoll+0x65/0x310 netrxaction+0x30c/0x5c0 _dosoftirq+0x14f/0x491 _irqexitrcu+0x82/0xc0 irqexitrcu+0xe/0x20 commoninterrupt+0xa1/0xb0 </IRQ> <TASK> asmcommon_interrupt+0x27/0x40

Allocated by task 6469: kasansavestack+0x38/0x70 kasansettrack+0x25/0x40 kasansaveallocinfo+0x1e/0x40 _kasankrealloc+0x133/0x190 krealloc+0xaa/0x130 nfctextadd+0xed/0x230 [nfconntrack] tcfctact+0x1095/0x1350 [actct] tcfactionexec+0xf8/0x1f0 flclassify+0x355/0x360 [clsflower] _tcfclassify+0x1fd/0x330 tcfclassify+0x21c/0x3c0 schhandleingress.constprop.0+0x2c5/0x500 _netifreceiveskbcore.constprop.0+0xb25/0x1510 _netifreceiveskblistcore+0x220/0x4c0 netifreceiveskblistinternal+0x446/0x620 napicompletedone+0x157/0x3d0 grocellpoll+0xcf/0x100 _napipoll+0x65/0x310 netrxaction+0x30c/0x5c0 _dosoftirq+0x14f/0x491

Freed by task 6469: kasansavestack+0x38/0x70 kasansettrack+0x25/0x40 kasansavefreeinfo+0x2b/0x60 __kasanslabfree+0x180/0x1f0 _kasanslabfree+0x12/0x30 slabfreefreelisthook+0xd2/0x1a0 _kmemcachefree+0x1a2/0x2f0 kfree+0x78/0x120 nfconntrackfree+0x74/0x130 [nfconntrack] nfctdestroy+0xb2/0x140 [nfconntrack] _nfctresolveclash+0x529/0x5d0 [nfconntrack] nfctresolveclash+0xf6/0x490 [nfconntrack] _nfconntrackconfirm+0x2c6/0x770 [nfconntrack] tcfctact+0x12ad/0x1350 [actct] tcfactionexec+0xf8/0x1f0 flclassify+0x355/0x360 [clsflower] _tcfclassify+0x1fd/0x330 tcfclassify+0x21c/0x3c0 schhandleingress.constprop.0+0x2c5/0x500 _netifreceiveskbcore.constprop.0+0xb25/0x1510 _netifreceiveskblistcore+0x220/0x4c0 netifreceiveskblistinternal+0x446/0x620 napicompletedone+0x157/0x3d0 grocellpoll+0xcf/0x100 _napipoll+0x65/0x310 netrxaction+0x30c/0x5c0 _dosoftirq+0x14f/0x491

The ct may be dropped if a clash has been resolved but is still passed to the tcfctflowtableprocess_conn function for further usage. This issue can be fixed by retrieving ct from skb again after confirming conntrack.(CVE-2024-41040)

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

udp: Set SOCKRCUFREE earlier in udplibget_port().

syzkaller triggered the warning [0] in udpv4early_demux().

In udpv[46]earlydemux() and sklookup(), we do not touch the refcount of the looked-up sk and use sockpfree() as skb->destructor, so we check SOCKRCU_FREE to ensure that the sk is safe to access during the RCU grace period.

Currently, SOCKRCUFREE is flagged for a bound socket after being put into the hash table. Moreover, the SOCKRCUFREE check is done too early in udpv[46]earlydemux() and sklookup(), so there could be a small race window:

CPU1 CPU2 ---- ---- udpv4earlydemux() udplibgetport() | |- hlistaddheadrcu() |- sk = _udp4libdemuxlookup() | |- DEBUGNETWARNONONCE(skisrefcounted(sk)); `- socksetflag(sk, SOCKRCU_FREE)

We had the same bug in TCP and fixed it in commit 871019b22d1b ("net: set SOCKRCUFREE before inserting socket into hashtable").

Let's apply the same fix for UDP.

Modules linked in: CPU: 0 PID: 11198 Comm: syz-executor.1 Not tainted 6.9.0-g93bda33046e7 #13 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:udpv4earlydemux+0x481/0xb70 net/ipv4/udp.c:2599 Code: c5 7a 15 fe bb 01 00 00 00 44 89 e9 31 ff d3 e3 81 e3 bf ef ff ff 89 de e8 2c 74 15 fe 85 db 0f 85 02 06 00 00 e8 9f 7a 15 fe <0f> 0b e8 98 7a 15 fe 49 8d 7e 60 e8 4f 39 2f fe 49 c7 46 60 20 52 RSP: 0018:ffffc9000ce3fa58 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8318c92c RDX: ffff888036ccde00 RSI: ffffffff8318c2f1 RDI: 0000000000000001 RBP: ffff88805a2dd6e0 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0001ffffffffffff R12: ffff88805a2dd680 R13: 0000000000000007 R14: ffff88800923f900 R15: ffff88805456004e FS: 00007fc449127640(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc449126e38 CR3: 000000003de4b002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 PKRU: 55555554 Call Trace: <TASK> iprcvfinishcore.constprop.0+0xbdd/0xd20 net/ipv4/ipinput.c:349 iprcvfinish+0xda/0x150 net/ipv4/ipinput.c:447 NFHOOK include/linux/netfilter.h:314 [inline] NFHOOK include/linux/netfilter.h:308 [inline] iprcv+0x16c/0x180 net/ipv4/ipinput.c:569 _netifreceiveskbonecore+0xb3/0xe0 net/core/dev.c:5624 _netifreceiveskb+0x21/0xd0 net/core/dev.c:5738 netifreceiveskbinternal net/core/dev.c:5824 [inline] netifreceiveskb+0x271/0x300 net/core/dev.c:5884 tunrxbatched drivers/net/tun.c:1549 [inline] tungetuser+0x24db/0x2c50 drivers/net/tun.c:2002 tunchrwriteiter+0x107/0x1a0 drivers/net/tun.c:2048 newsyncwrite fs/readwrite.c:497 [inline] vfswrite+0x76f/0x8d0 fs/readwrite.c:590 ksyswrite+0xbf/0x190 fs/readwrite.c:643 _dosyswrite fs/readwrite.c:655 [inline] _sesyswrite fs/readwrite.c:652 [inline] _x64syswrite+0x41/0x50 fs/readwrite.c:652 x64syscall+0xe66/0x1990 arch/x86/include/generated/asm/syscalls64.h:2 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x4b/0x110 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x7fc44a68bc1f Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 e9 cf f5 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 3c d0 f5 ff 48 RSP: 002b:00007fc449126c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00000000004bc050 RCX: 00007fc44a68bc1f R ---truncated---(CVE-2024-41041)

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

skmsg: Skip zero length skb in skmsgrecvmsg

When running BPF selftests (./testprogs -t sockmapbasic) on a Loongarch platform, the following kernel panic occurs:

[...] Oops[#1]: CPU: 22 PID: 2824 Comm: testprogs Tainted: G OE 6.10.0-rc2+ #18 Hardware name: LOONGSON Dabieshan/Loongson-TC542F0, BIOS Loongson-UDK2018 ... ... ra: 90000000048bf6c0 skmsgrecvmsg+0x120/0x560 ERA: 9000000004162774 copypagetoiter+0x74/0x1c0 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 0000000c (PPLV0 +PIE +PWE) EUEN: 00000007 (+FPE +SXE +ASXE -BTE) ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) BADV: 0000000000000040 PRID: 0014c011 (Loongson-64bit, Loongson-3C5000) Modules linked in: bpftestmod(OE) xtCHECKSUM xtMASQUERADE xtconntrack Process testprogs (pid: 2824, threadinfo=0000000000863a31, task=...) Stack : ... Call Trace: [<9000000004162774>] copypagetoiter+0x74/0x1c0 [<90000000048bf6c0>] skmsgrecvmsg+0x120/0x560 [<90000000049f2b90>] tcpbpfrecvmsgparser+0x170/0x4e0 [<90000000049aae34>] inetrecvmsg+0x54/0x100 [<900000000481ad5c>] sockrecvmsg+0x7c/0xe0 [<900000000481e1a8>] _sysrecvfrom+0x108/0x1c0 [<900000000481e27c>] sysrecvfrom+0x1c/0x40 [<9000000004c076ec>] dosyscall+0x8c/0xc0 [<9000000003731da4>] handlesyscall+0xc4/0x160 Code: ... ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception Kernel relocated by 0x3510000 .text @ 0x9000000003710000 .data @ 0x9000000004d70000 .bss @ 0x9000000006469400 ---[ end Kernel panic - not syncing: Fatal exception ]--- [...]

This crash happens every time when running sockmapskbverdictshutdown subtest in sockmapbasic.

This crash is because a NULL pointer is passed to pageaddress() in the skmsgrecvmsg(). Due to the different implementations depending on the architecture, pageaddress(NULL) will trigger a panic on Loongarch platform but not on x86 platform. So this bug was hidden on x86 platform for a while, but now it is exposed on Loongarch platform. The root cause is that a zero length skb (skb->len == 0) was put on the queue.

This zero length skb is a TCP FIN packet, which was sent by shutdown(), invoked in testsockmapskbverdictshutdown():

shutdown(p1, SHUT_WR);

In this case, in skpsockskbingressenqueue(), numsge is zero, and no page is put to this sge (see sgsetpage in sgsetpage), but this empty sge is queued into ingressmsg list.

And in skmsgrecvmsg(), this empty sge is used, and a NULL page is got by sgpage(sge). Pass this NULL page to copypagetoiter(), which passes it to kmaplocalpage() and to page_address(), then kernel panics.

To solve this, we should skip this zero length skb. So in skmsgrecvmsg(), if copy is zero, that means it's a zero length skb, skip invoking copypagetoiter(). We are using the EFAULT return triggered by copypagetoiter to check for isfin in tcpbpf.c.(CVE-2024-41048)

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

filelock: fix potential use-after-free in posixlockinode

Light Hsieh reported a KASAN UAF warning in traceposixlock_inode(). The request pointer had been changed earlier to point to a lock entry that was added to the inode's list. However, before the tracepoint could fire, another task raced in and freed that lock.

Fix this by moving the tracepoint inside the spinlock, which should ensure that this doesn't happen.(CVE-2024-41049)

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

Bluetooth: hcicore: cancel all works upon hciunregister_dev()

syzbot is reporting that calling hcireleasedev() from hcierrorreset() due to hcidevput() from hcierrorreset() can cause deadlock at destroyworkqueue(), for hcierrorreset() is called from hdev->reqworkqueue which destroy_workqueue() needs to flush.

We need to make sure that hdev->{rxwork,cmdwork,txwork} which are queued into hdev->workqueue and hdev->{poweron,errorreset} which are queued into hdev->reqworkqueue are no longer running by the moment

   destroy_workqueue(hdev->workqueue);
   destroy_workqueue(hdev->req_workqueue);

are called from hcireleasedev().

Call cancelworksync() on these work items from hciunregisterdev() as soon as hdev->list is removed from hcidevlist.(CVE-2024-41063)

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

ASoC: topology: Fix references to freed memory

Most users after parsing a topology file, release memory used by it, so having pointer references directly into topology file contents is wrong. Use devm_kmemdup(), to allocate memory as needed.(CVE-2024-41069)

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

iouring: fix possible deadlock in ioregisteriowqmax_workers()

The ioregisteriowqmaxworkers() function calls ioputsqdata(), which acquires the sqd->lock without releasing the uringlock. Similar to the commit 009ad9f0c6ee ("iouring: drop ctx->uringlock before acquiring sqd->lock"), this can lead to a potential deadlock situation.

To resolve this issue, the uringlock is released before calling ioputsqdata(), and then it is re-acquired after the function call.

This change ensures that the locks are acquired in the correct order, preventing the possibility of a deadlock.(CVE-2024-41080)

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

tap: add missing verification for short frame

The cited commit missed to check against the validity of the frame length in the tapgetuserxdp() path, which could cause a corrupted skb to be sent downstack. Even before the skb is transmitted, the tapgetuserxdp()-->skbsetnetworkheader() may assume the size is more than ETHHLEN. Once transmitted, this could either cause out-of-bound access beyond the actual length, or confuse the underlayer with incorrect or inconsistent header length in the skb metadata.

In the alternative path, tapgetuser() already prohibits short frame which has the length less than Ethernet header size from being transmitted.

This is to drop any frame shorter than the Ethernet header size just like how tapgetuser() does.

CVE: CVE-2024-41090(CVE-2024-41090)

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

tun: add missing verification for short frame

The cited commit missed to check against the validity of the frame length in the tunxdpone() path, which could cause a corrupted skb to be sent downstack. Even before the skb is transmitted, the tunxdpone-->ethtypetrans() may access the Ethernet header although it can be less than ETH_HLEN. Once transmitted, this could either cause out-of-bound access beyond the actual length, or confuse the underlayer with incorrect or inconsistent header length in the skb metadata.

In the alternative path, tungetuser() already prohibits short frame which has the length less than Ethernet header size from being transmitted for IFF_TAP.

This is to drop any frame shorter than the Ethernet header size just like how tungetuser() does.

CVE: CVE-2024-41091(CVE-2024-41091)

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

bpf: Take return from setmemoryrox() into account with bpfjitbinarylockro()

setmemoryrox() can fail, leaving memory unprotected.

Check return and bail out when bpfjitbinarylockro() returns an error.(CVE-2024-42067)

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

iio: chemical: bme680: Fix overflows in compensate() functions

There are cases in the compensate functions of the driver that there could be overflows of variables due to bit shifting ops. These implications were initially discussed here [1] and they were mentioned in log message of Commit 1b3bd8592780 ("iio: chemical: Add support for Bosch BME680 sensor").

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

ALSA: emux: improve patch ioctl data validation

In loaddata(), make the validation of and skipping over the main info block match that in loadguspatch().

In loadguspatch(), add checking that the specified patch length matches the actually supplied data, like loaddata() already did.(CVE-2024-42097)

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

jffs2: Fix potential illegal address access in jffs2freeinode

During the stress testing of the jffs2 file system,the following abnormal printouts were found: [ 2430.649000] Unable to handle kernel paging request at virtual address 0069696969696948 [ 2430.649622] Mem abort info: [ 2430.649829] ESR = 0x96000004 [ 2430.650115] EC = 0x25: DABT (current EL), IL = 32 bits [ 2430.650564] SET = 0, FnV = 0 [ 2430.650795] EA = 0, S1PTW = 0 [ 2430.651032] FSC = 0x04: level 0 translation fault [ 2430.651446] Data abort info: [ 2430.651683] ISV = 0, ISS = 0x00000004 [ 2430.652001] CM = 0, WnR = 0 [ 2430.652558] [0069696969696948] address between user and kernel address ranges [ 2430.653265] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 2430.654512] CPU: 2 PID: 20919 Comm: cat Not tainted 5.15.25-g512f31242bf6 #33 [ 2430.655008] Hardware name: linux,dummy-virt (DT) [ 2430.655517] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2430.656142] pc : kfree+0x78/0x348 [ 2430.656630] lr : jffs2freeinode+0x24/0x48 [ 2430.657051] sp : ffff800009eebd10 [ 2430.657355] x29: ffff800009eebd10 x28: 0000000000000001 x27: 0000000000000000 [ 2430.658327] x26: ffff000038f09d80 x25: 0080000000000000 x24: ffff800009d38000 [ 2430.658919] x23: 5a5a5a5a5a5a5a5a x22: ffff000038f09d80 x21: ffff8000084f0d14 [ 2430.659434] x20: ffff0000bf9a6ac0 x19: 0169696969696940 x18: 0000000000000000 [ 2430.659969] x17: ffff8000b6506000 x16: ffff800009eec000 x15: 0000000000004000 [ 2430.660637] x14: 0000000000000000 x13: 00000001000820a1 x12: 00000000000d1b19 [ 2430.661345] x11: 0004000800000000 x10: 0000000000000001 x9 : ffff8000084f0d14 [ 2430.662025] x8 : ffff0000bf9a6b40 x7 : ffff0000bf9a6b48 x6 : 0000000003470302 [ 2430.662695] x5 : ffff00002e41dcc0 x4 : ffff0000bf9aa3b0 x3 : 0000000003470342 [ 2430.663486] x2 : 0000000000000000 x1 : ffff8000084f0d14 x0 : fffffc0000000000 [ 2430.664217] Call trace: [ 2430.664528] kfree+0x78/0x348 [ 2430.664855] jffs2freeinode+0x24/0x48 [ 2430.665233] icallback+0x24/0x50 [ 2430.665528] rcudobatch+0x1ac/0x448 [ 2430.665892] rcucore+0x28c/0x3c8 [ 2430.666151] rcucoresi+0x18/0x28 [ 2430.666473] _dosoftirq+0x138/0x3cc [ 2430.666781] irqexit+0xf0/0x110 [ 2430.667065] handledomainirq+0x6c/0x98 [ 2430.667447] gichandleirq+0xac/0xe8 [ 2430.667739] callonirqstack+0x28/0x54 The parameter passed to kfree was 5a5a5a5a, which corresponds to the target field of the jffsinodeinfo structure. It was found that all variables in the jffsinodeinfo structure were 5a5a5a5a, except for the first member sem. It is suspected that these variables are not initialized because they were set to 5a5a5a5a during memory testing, which is meant to detect uninitialized memory.The sem variable is initialized in the function jffs2iinitonce, while other members are initialized in the function jffs2initinodeinfo.

The function jffs2initinodeinfo is called after igetlocked, but in the igetlocked function, the destroyinode process is triggered, which releases the inode and consequently, the target member of the inode is not initialized.In concurrent high pressure scenarios, igetlocked may enter the destroyinode branch as described in the code.

Since the destroyinode functionality of jffs2 only releases the target, the fix method is to set target to NULL in jffs2iinitonce.(CVE-2024-42115)

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

leds: mlxreg: Use devmmutexinit() for mutex initialization

In this driver LEDs are registered using devmledclassdevregister() so they are automatically unregistered after module's remove() is done. ledclassdevunregister() calls module's ledset_brightness() to turn off the LEDs and that callback uses mutex which was destroyed already in module's remove() so use devm API instead.(CVE-2024-42129)

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

drm/amdgpu: Using uninitialized value *size when calling amdgpuvcecs_reloc

Initialize the size before calling amdgpuvcecs_reloc, such as case 0x03000001. V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian)(CVE-2024-42228)

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

net: nexthop: Initialize all fields in dumped nexthops

struct nexthopgrp contains two reserved fields that are not initialized by nlaputnhgroup(), and carry garbage. This can be observed e.g. with strace (edited for clarity):

# ip nexthop add id 1 dev lo
# ip nexthop add id 101 group 1
# strace -e recvmsg ip nexthop get id 101
...
recvmsg(... [{nla_len=12, nla_type=NHA_GROUP},
             [{id=1, weight=0, resvd1=0x69, resvd2=0x67}]] ...) = 52

The fields are reserved and therefore not currently used. But as they are, they leak kernel memory, and the fact they are not just zero complicates repurposing of the fields for new ends. Initialize the full structure.(CVE-2024-42283)

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

irqchip/imx-irqsteer: Handle runtime power management correctly

The power domain is automatically activated from clk_prepare(). However, on certain platforms like i.MX8QM and i.MX8QXP, the power-on handling invokes sleeping functions, which triggers the 'scheduling while atomic' bug in the context switch path during device probing:

BUG: scheduling while atomic: kworker/u13:1/48/0x00000002 Call trace: _schedulebug+0x54/0x6c _schedule+0x7f0/0xa94 schedule+0x5c/0xc4 schedulepreemptdisabled+0x24/0x40 _mutexlock.constprop.0+0x2c0/0x540 _mutexlockslowpath+0x14/0x20 mutexlock+0x48/0x54 clkpreparelock+0x44/0xa0 clkprepare+0x20/0x44 imxirqsteerresume+0x28/0xe0 pmgenericruntimeresume+0x2c/0x44 _genpdruntimeresume+0x30/0x80 genpdruntimeresume+0xc8/0x2c0 _rpmcallback+0x48/0x1d8 rpmcallback+0x6c/0x78 rpmresume+0x490/0x6b4 _pmruntimeresume+0x50/0x94 irqchippmget+0x2c/0xa0 _irqdosethandler+0x178/0x24c irqsetchainedhandleranddata+0x60/0xa4 mxcgpio_probe+0x160/0x4b0

Cure this by implementing the irqbuslock/sync_unlock() interrupt chip callbacks and handle power management in them as they are invoked from non-atomic context.

tglx: Rewrote change log, added Fixes tag

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

udf: Avoid using corrupted block bitmap buffer

When the filesystem block bitmap is corrupted, we detect the corruption while loading the bitmap and fail the allocation with error. However the next allocation from the same bitmap will notice the bitmap buffer is already loaded and tries to allocate from the bitmap with mixed results (depending on the exact nature of the bitmap corruption). Fix the problem by using BH_verified bit to indicate whether the bitmap is valid or not.(CVE-2024-42306)

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

drm/gma500: fix null pointer dereference in psbintellvdsgetmodes

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

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

media: venus: fix use after free in vdec_close

There appears to be a possible use after free with vdec_close(). The firmware will add buffer release work to the work queue through HFI callbacks as a normal part of decoding. Randomly closing the decoder device from userspace during normal decoding can incur a read after free for inst.

Fix it by cancelling the work in vdec_close.(CVE-2024-42313)

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

ipvs: properly dereference pe in ipvsadd_service

Use pe directly to resolve sparse warning:

net/netfilter/ipvs/ipvsctl.c:1471:27: warning: dereference of noderef expression(CVE-2024-42322)

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

PCI: keystone: Fix NULL pointer dereference in case of DT error in kspciesetuprcapp_regs()

If IORESOURCEMEM is not provided in Device Tree due to any error, resourcelistfirsttype() will return NULL and pciparserequestofpci_ranges() will just emit a warning.

This will cause a NULL pointer dereference. Fix this bug by adding NULL return check.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-43823)

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

leds: trigger: Unregister sysfs attributes before calling deactivate()

Triggers which have trigger specific sysfs attributes typically store related data in trigger-data allocated by the activate() callback and freed by the deactivate() callback.

Calling deviceremovegroups() after calling deactivate() leaves a window where the sysfs attributes show/store functions could be called after deactivation and then operate on the just freed trigger-data.

Move the deviceremovegroups() call to before deactivate() to close this race window.

This also makes the deactivation path properly do things in reverse order of the activation path which calls the activate() callback before calling deviceaddgroups().(CVE-2024-43830)

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

bpf, arm64: Fix trampoline for BPFTRAMPFCALLORIG

When BPFTRAMPFCALLORIG is set, the trampoline calls _bpftrampenter() and _bpftrampexit() functions, passing them the struct bpftrampimage *im pointer as an argument in R0.

The trampoline generation code uses emitaddrmovi64() to emit instructions for moving the bpftrampimage address into R0, but emitaddrmovi64() assumes the address to be in the vmalloc() space and uses only 48 bits. Because bpftrampimage is allocated using kzalloc(), its address can use more than 48-bits, in this case the trampoline will pass an invalid address to _bpftramp_enter/exit() causing a kernel crash.

Fix this by using emita64movi64() in place of emitaddrmovi64() as it can work with addresses that are greater than 48-bits.(CVE-2024-43840)

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

md: fix deadlock between mddev_suspend and flush bio

Deadlock occurs when mddev is being suspended while some flush bio is in progress. It is a complex issue.

T1. the first flush is at the ending stage, it clears 'mddev->flushbio' and tries to submit data, but is blocked because mddev is suspended by T4. T2. the second flush sets 'mddev->flushbio', and attempts to queue mdsubmitflushdata(), which is already running (T1) and won't execute again if on the same CPU as T1. T3. the third flush inc activeio and tries to flush, but is blocked because 'mddev->flushbio' is not NULL (set by T2). T4. mddevsuspend() is called and waits for active_io dec to 0 which is inc by T3.

T1 T2 T3 T4 (flush 1) (flush 2) (third 3) (suspend) mdsubmitflushdata mddev->flushbio = NULL; . . mdflushrequest . mddev->flushbio = bio . queue submitflushes . . . . mdhandlerequest . . activeio + 1 . . mdflushrequest . . wait !mddev->flushbio . . . . mddevsuspend . . wait !activeio . . . submitflushes . queuework mdsubmitflushdata . //mdsubmitflushdata is already running (T1) . mdhandlerequest wait resume

The root issue is non-atomic inc/dec of activeio during flush process. activeio is dec before mdsubmitflushdata is queued, and inc soon after mdsubmitflushdata() run. mdflushrequest activeio + 1 submitflushes activeio - 1 mdsubmitflushdata mdhandlerequest activeio + 1 makerequest active_io - 1

If activeio is dec after mdhandlerequest() instead of within submitflushes(), makerequest() can be called directly intead of mdhandlerequest() in mdsubmitflushdata(), and active_io will only inc and dec once in the whole flush process. Deadlock will be fixed.

Additionally, the only difference between fixing the issue and before is that there is no return error handling of makerequest(). But after previous patch cleaned mdwritestart(), makerequst() only return error in raid5makerequest() by dm-raid, see commit 41425f96d7aa ("dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape)". Since dm always splits data and flush operation into two separate io, io size of flush submitted by dm always is 0, makerequest() will not be called in mdsubmitflushdata(). To prevent future modifications from introducing issues, add WARNON to ensure makerequest() no error is returned in this context.(CVE-2024-43855)

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

RDMA/hns: Fix soft lockup under heavy CEQE load

CEQEs are handled in interrupt handler currently. This may cause the CPU core staying in interrupt context too long and lead to soft lockup under heavy load.

Handle CEQEs in BH workqueue and set an upper limit for the number of CEQE handled by a single call of work handler.(CVE-2024-43872)

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

memcg: protect concurrent access to memcgroupidr

Commit 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure after many small jobs") decoupled the memcg IDs from the CSS ID space to fix the cgroup creation failures. It introduced IDR to maintain the memcg ID space. The IDR depends on external synchronization mechanisms for modifications. For the memcgroupidr, the idralloc() and idrreplace() happen within css callback and thus are protected through cgroupmutex from concurrent modifications. However idrremove() for memcgroupidr was not protected against concurrency and can be run concurrently for different memcgs when they hit their refcnt to zero. Fix that.

We have been seeing listlru based kernel crashes at a low frequency in our fleet for a long time. These crashes were in different part of listlru code including listlruadd(), listlrudel() and reparenting code. Upon further inspection, it looked like for a given object (dentry and inode), the superblock's listlru didn't have listlruone for the memcg of that object. The initial suspicions were either the object is not allocated through kmemcachealloclru() or somehow memcglistlrualloc() failed to allocate listlruone() for a memcg but returned success. No evidence were found for these cases.

Looking more deeply, we started seeing situations where valid memcg's id is not present in memcgroupidr and in some cases multiple valid memcgs have same id and memcgroupidr is pointing to one of them. So, the most reasonable explanation is that these situations can happen due to race between multiple idrremove() calls or race between idralloc()/idrreplace() and idrremove(). These races are causing multiple memcgs to acquire the same ID and then offlining of one of them would cleanup listlrus on the system for all of them. Later access from other memcgs to the listlru cause crashes due to missing listlruone.(CVE-2024-43892)

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

serial: core: check uartclk for zero to avoid divide by zero

Calling ioctl TIOCSSERIAL with an invalid baudbase can result in uartclk being zero, which will result in a divide by zero error in uartgetdivisor(). The check for uartclk being zero in uartset_info() needs to be done before other settings are made as subsequent calls to ioctl TIOCSSERIAL for the same port would be impacted if the uartclk check was done where uartclk gets set.

Oops: divide error: 0000 PREEMPT SMP KASAN PTI RIP: 0010:uartgetdivisor (drivers/tty/serial/serialcore.c:580) Call Trace: <TASK> serial8250getdivisor (drivers/tty/serial/8250/8250port.c:2576 drivers/tty/serial/8250/8250port.c:2589) serial8250dosettermios (drivers/tty/serial/8250/8250port.c:502 drivers/tty/serial/8250/8250port.c:2741) serial8250settermios (drivers/tty/serial/8250/8250port.c:2862) uartchangelinesettings (./include/linux/spinlock.h:376 ./include/linux/serialcore.h:608 drivers/tty/serial/serialcore.c:222) uartportstartup (drivers/tty/serial/serialcore.c:342) uartstartup (drivers/tty/serial/serialcore.c:368) uartsetinfo (drivers/tty/serial/serialcore.c:1034) uartsetinfouser (drivers/tty/serial/serialcore.c:1059) ttysetserial (drivers/tty/ttyio.c:2637) ttyioctl (drivers/tty/ttyio.c:2647 drivers/tty/ttyio.c:2791) _x64sysioctl (fs/ioctl.c:52 fs/ioctl.c:907 fs/ioctl.c:893 fs/ioctl.c:893) dosyscall64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1)) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130)

Rule: add(CVE-2024-43893)

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

fou: remove warn in guegroreceive on unsupported protocol

Drop the WARNONONCE inn guegroreceive if the encapsulated type is not known or does not have a GRO handler.

Such a packet is easily constructed. Syzbot generates them and sets off this warning.

Remove the warning as it is expected and not actionable.

The warning was previously reduced from WARNON to WARNONONCE in commit 270136613bf7 ("fou: Do WARNONONCE in guegro_receive for bad proto callbacks").(CVE-2024-44940)

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

ALSA: line6: Fix racy access to midibuf

There can be concurrent accesses to line6 midibuf from both the URB completion callback and the rawmidi API access. This could be a cause of KMSAN warning triggered by syzkaller below (so put as reported-by here).

This patch protects the midibuf call of the former code path with a spinlock for avoiding the possible races.(CVE-2024-44954)

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

atm: idt77252: prevent use after free in dequeue_rx()

We can't dereference "skb" after calling vcc->push() because the skb is released.(CVE-2024-44998)

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

xhci: Fix Panther point NULL pointer deref at full-speed re-enumeration

re-enumerating full-speed devices after a failed address device command can trigger a NULL pointer dereference.

Full-speed devices may need to reconfigure the endpoint 0 Max Packet Size value during enumeration. Usb core calls usbep0reinit() in this case, which ends up calling xhciconfigureendpoint().

On Panther point xHC the xhciconfigureendpoint() function will additionally check and reserve bandwidth in software. Other hosts do this in hardware

If xHC address device command fails then a new xhcivirtdevice structure is allocated as part of re-enabling the slot, but the bandwidth table pointers are not set up properly here. This triggers the NULL pointer dereference the next time usbep0reinit() is called and xhciconfigureendpoint() tries to check and reserve bandwidth

[46710.713538] usb 3-1: new full-speed USB device number 5 using xhcihcd [46710.713699] usb 3-1: Device not responding to setup address. [46710.917684] usb 3-1: Device not responding to setup address. [46711.125536] usb 3-1: device not accepting address 5, error -71 [46711.125594] BUG: kernel NULL pointer dereference, address: 0000000000000008 [46711.125600] #PF: supervisor read access in kernel mode [46711.125603] #PF: errorcode(0x0000) - not-present page [46711.125606] PGD 0 P4D 0 [46711.125610] Oops: Oops: 0000 [#1] PREEMPT SMP PTI [46711.125615] CPU: 1 PID: 25760 Comm: kworker/1:2 Not tainted 6.10.32 #1 [46711.125620] Hardware name: Gigabyte Technology Co., Ltd. [46711.125623] Workqueue: usbhubwq hubevent [usbcore] [46711.125668] RIP: 0010:xhcireservebandwidth (drivers/usb/host/xhci.c

Fix this by making sure bandwidth table pointers are set up correctly after a failed address device command, and additionally by avoiding checking for bandwidth in cases like this where no actual endpoints are added or removed, i.e. only context for default control endpoint 0 is evaluated.(CVE-2024-45006)

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

s390/dasd: fix error recovery leading to data corruption on ESE devices

Extent Space Efficient (ESE) or thin provisioned volumes need to be formatted on demand during usual IO processing.

The dasdeseneeds_format function checks for error codes that signal the non existence of a proper track format.

The check for incorrect length is to imprecise since other error cases leading to transport of insufficient data also have this flag set. This might lead to data corruption in certain error cases for example during a storage server warmstart.

Fix by removing the check for incorrect length and replacing by explicitly checking for invalid track format in transport mode.

Also remove the check for file protected since this is not a valid ESE handling case.(CVE-2024-45026)

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

nfc: pn533: Add poll mod list filling check

In case of improtocols value is 1 and tmprotocols value is 0 this combination successfully passes the check 'if (!improtocols && !tmprotocols)' in the nfcstartpoll(). But then after pn533pollcreatemodlist() call in pn533startpoll() poll mod list will remain empty and dev->pollmodcount will remain 0 which lead to division by zero.

Normally no im protocol has value 1 in the mask, so this combination is not expected by driver. But these protocol values actually come from userspace via Netlink interface (NFCCMDSTARTPOLL operation). So a broken or malicious program may pass a message containing a "bad" combination of protocol parameter values so that dev->pollmodcount is not incremented inside pn533pollcreatemodlist(), thus leading to division by zero. Call trace looks like: nfcgenlstartpoll() nfcstartpoll() ->startpoll() pn533start_poll()

Add poll mod list filling check.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-46676)

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

usb: typec: ucsi: Fix null pointer dereference in trace

ucsiregisteraltmode checks ISERR for the alt pointer and treats NULL as valid. When CONFIGTYPECDPALTMODE is not enabled, ucsiregisterdisplayport returns NULL which causes a NULL pointer dereference in trace. Rather than return NULL, call typecportregisteraltmode to register DisplayPort alternate mode as a non-controllable mode when CONFIGTYPECDPALTMODE is not enabled.(CVE-2024-46719)

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

bpf: Remove tstrun from lwtseg6localprogops.

The syzbot reported that the lwtseg6 related BPF ops can be invoked via bpftestrun() without without entering inputactionendbpf() first.

Martin KaFai Lau said that self test for BPFPROGTYPELWTSEG6LOCAL probably didn't work since it was introduced in commit 04d4b274e2a ("ipv6: sr: Add seg6local action End.BPF"). The reason is that the per-CPU variable seg6bpfsrh_states::srh is never assigned in the self test case but each BPF function expects it.

Remove testrun for BPFPROGTYPELWT_SEG6LOCAL.(CVE-2024-46754)

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

ice: Add netifdeviceattach/detach into PF reset flow

Ethtool callbacks can be executed while reset is in progress and try to access deleted resources, e.g. getting coalesce settings can result in a NULL pointer dereference seen below.

Reproduction steps: Once the driver is fully initialized, trigger reset: # echo 1 > /sys/class/net/<interface>/device/reset when reset is in progress try to get coalesce settings using ethtool: # ethtool -c <interface>

BUG: kernel NULL pointer dereference, address: 0000000000000020 PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 11 PID: 19713 Comm: ethtool Tainted: G S 6.10.0-rc7+ #7 RIP: 0010:icegetqcoalesce+0x2e/0xa0 [ice] RSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206 RAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000 R13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40 FS: 00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0 Call Trace: <TASK> icegetcoalesce+0x17/0x30 [ice] coalescepreparedata+0x61/0x80 ethnldefaultdoit+0xde/0x340 genlfamilyrcvmsgdoit+0xf2/0x150 genlrcvmsg+0x1b3/0x2c0 netlinkrcvskb+0x5b/0x110 genlrcv+0x28/0x40 netlinkunicast+0x19c/0x290 netlinksendmsg+0x222/0x490 _syssendto+0x1df/0x1f0 _x64syssendto+0x24/0x30 dosyscall64+0x82/0x160 entrySYSCALL64after_hwframe+0x76/0x7e RIP: 0033:0x7faee60d8e27

Calling netifdevicedetach() before reset makes the net core not call the driver when ethtool command is issued, the attempt to execute an ethtool command during reset will result in the following message:

netlink error: No such device

instead of NULL pointer dereference. Once reset is done and icerebuild() is executing, the netifdevice_attach() is called to allow for ethtool operations to occur again in a safe manner.(CVE-2024-46770)

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

ksmbd: unset the binding mark of a reused connection

Steve French reported null pointer dereference error from sha256 lib. cifs.ko can send session setup requests on reused connection. If reused connection is used for binding session, conn->binding can still remain true and generatepreauthhash() will not set sess->PreauthHashValue and it will be NULL. It is used as a material to create an encryption key in ksmbdgensmb311encryptionkey. ->PreauthHashValue cause null pointer dereference error from cryptoshash_update().

BUG: kernel NULL pointer dereference, address: 0000000000000000

PF: supervisor read access in kernel mode

PF: error_code(0x0000) - not-present page

PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 8 PID: 429254 Comm: kworker/8:39 Hardware name: LENOVO 20MAS08500/20MAS08500, BIOS N2CET69W (1.52 ) Workqueue: ksmbd-io handleksmbdwork [ksmbd] RIP: 0010:libsha256basedoupdate.isra.0+0x11e/0x1d0 [sha256ssse3] <TASK> ? showregs+0x6d/0x80 ? _die+0x24/0x80 ? pagefaultoops+0x99/0x1b0 ? douseraddrfault+0x2ee/0x6b0 ? excpagefault+0x83/0x1b0 ? asmexcpagefault+0x27/0x30 ? _pfxsha256transformrorx+0x10/0x10 [sha256ssse3] ? libsha256basedoupdate.isra.0+0x11e/0x1d0 [sha256ssse3] ? _pfxsha256transformrorx+0x10/0x10 [sha256ssse3] ? _pfxsha256transformrorx+0x10/0x10 [sha256ssse3] _sha256update+0x77/0xa0 [sha256ssse3] sha256avx2update+0x15/0x30 [sha256ssse3] cryptoshashupdate+0x1e/0x40 hmacupdate+0x12/0x20 cryptoshashupdate+0x1e/0x40 generatekey+0x234/0x380 [ksmbd] generatesmb3encryptionkey+0x40/0x1c0 [ksmbd] ksmbdgensmb311encryptionkey+0x72/0xa0 [ksmbd] ntlmauthenticate.isra.0+0x423/0x5d0 [ksmbd] smb2sesssetup+0x952/0xaa0 [ksmbd] _processrequest+0xa3/0x1d0 [ksmbd] _handleksmbdwork+0x1c4/0x2f0 [ksmbd] handleksmbdwork+0x2d/0xa0 [ksmbd] processonework+0x16c/0x350 workerthread+0x306/0x440 ? _pfxworkerthread+0x10/0x10 kthread+0xef/0x120 ? _pfxkthread+0x10/0x10 retfromfork+0x44/0x70 ? _pfxkthread+0x10/0x10 retfromfork_asm+0x1b/0x30 </TASK>(CVE-2024-46795)

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

drm/amdgpu: the warning dereferencing obj for nbiov74

if ras_manager obj null, don't print NBIO err data(CVE-2024-46819)

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

ELF: fix kernel.randomizevaspace double read

ELF loader uses "randomizevaspace" twice. It is sysctl and can change at any moment, so 2 loads could see 2 different values in theory with unpredictable consequences.

Issue exactly one load for consistent value across one exec.(CVE-2024-46826)

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

sched: sch_cake: fix bulk flow accounting logic for host fairness

In sch_cake, we keep track of the count of active bulk flows per host, when running in dst/src host fairness mode, which is used as the round-robin weight when iterating through flows. The count of active bulk flows is updated whenever a flow changes state.

This has a peculiar interaction with the hash collision handling: when a hash collision occurs (after the set-associative hashing), the state of the hash bucket is simply updated to match the new packet that collided, and if host fairness is enabled, that also means assigning new per-host state to the flow. For this reason, the bulk flow counters of the host(s) assigned to the flow are decremented, before new state is assigned (and the counters, which may not belong to the same host anymore, are incremented again).

Back when this code was introduced, the host fairness mode was always enabled, so the decrement was unconditional. When the configuration flags were introduced the increment was made conditional, but the decrement was not. Which of course can lead to a spurious decrement (and associated wrap-around to U16_MAX).

AFAICT, when host fairness is disabled, the decrement and wrap-around happens as soon as a hash collision occurs (which is not that common in itself, due to the set-associative hashing). However, in most cases this is harmless, as the value is only used when host fairness mode is enabled. So in order to trigger an array overflow, sch_cake has to first be configured with host fairness disabled, and while running in this mode, a hash collision has to occur to cause the overflow. Then, the qdisc has to be reconfigured to enable host fairness, which leads to the array out-of-bounds because the wrapped-around value is retained and used as an array index. It seems that syzbot managed to trigger this, which is quite impressive in its own right.

This patch fixes the issue by introducing the same conditional check on decrement as is used on increment.

The original bug predates the upstreaming of cake, but the commit listed in the Fixes tag touched that code, meaning that this patch won't apply before that.(CVE-2024-46828)

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

btrfs: clean up our handling of refs == 0 in snapshot delete

In reada we BUGON(refs == 0), which could be unkind since we aren't holding a lock on the extent leaf and thus could get a transient incorrect answer. In walkdownproc we also BUGON(refs == 0), which could happen if we have extent tree corruption. Change that to return -EUCLEAN. In dowalkdown() we catch this case and handle it correctly, however we return -EIO, which -EUCLEAN is a more appropriate error code. Finally in walkupproc we have the same BUG_ON(refs == 0), so convert that to proper error handling. Also adjust the error message so we can actually do something with the information.(CVE-2024-46840)

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

perf/x86/intel: Limit the period on Haswell

Running the ltp test cve-2015-3290 concurrently reports the following warnings.

perfevents: irq loop stuck! WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174 intelpmuhandleirq+0x285/0x370 Call Trace: <NMI> ? _warn+0xa4/0x220 ? intelpmuhandleirq+0x285/0x370 ? _reportbug+0x123/0x130 ? intelpmuhandleirq+0x285/0x370 ? _reportbug+0x123/0x130 ? intelpmuhandleirq+0x285/0x370 ? reportbug+0x3e/0xa0 ? handlebug+0x3c/0x70 ? excinvalidop+0x18/0x50 ? asmexcinvalidop+0x1a/0x20 ? irqworkclaim+0x1e/0x40 ? intelpmuhandleirq+0x285/0x370 perfeventnmihandler+0x3d/0x60 nmi_handle+0x104/0x330

Thanks to Thomas Gleixner's analysis, the issue is caused by the low initial period (1) of the frequency estimation algorithm, which triggers the defects of the HW, specifically erratum HSW11 and HSW143. (For the details, please refer https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/)

The HSW11 requires a period larger than 100 for the INST_RETIRED.ALL event, but the initial period in the freq mode is 1. The erratum is the same as the BDM11, which has been supported in the kernel. A minimum period of 128 is enforced as well on HSW.

HSW143 is regarding that the fixed counter 1 may overcount 32 with the Hyper-Threading is enabled. However, based on the test, the hardware has more issues than it tells. Besides the fixed counter 1, the message 'interrupt took too long' can be observed on any counter which was armed with a period < 32 and two events expired in the same NMI. A minimum period of 32 is enforced for the rest of the events. The recommended workaround code of the HSW143 is not implemented. Because it only addresses the issue for the fixed counter. It brings extra overhead through extra MSR writing. No related overcounting issue has been reported so far.(CVE-2024-46848)

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

net: dpaa: Pad packets to ETH_ZLEN

When sending packets under 60 bytes, up to three bytes of the buffer following the data may be leaked. Avoid this by extending all packets to ETH_ZLEN, ensuring nothing is leaked in the padding. This bug can be reproduced by running

$ ping -s 11 destination(CVE-2024-46854)

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

netfilter: nft_socket: fix sk refcount leaks

We must put 'sk' reference before returning.(CVE-2024-46855)

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

mptcp: pm: Fix uaf in _timerdelete_sync

There are two paths to access mptcppmdeladdtimer, result in a race condition:

 CPU1               CPU2
 ====                               ====
 net_rx_action
 napi_poll                          netlink_sendmsg
 __napi_poll                        netlink_unicast
 process_backlog                    netlink_unicast_kernel
 __netif_receive_skb                genl_rcv
 __netif_receive_skb_one_core       netlink_rcv_skb
 NF_HOOK                            genl_rcv_msg
 ip_local_deliver_finish            genl_family_rcv_msg
 ip_protocol_deliver_rcu            genl_family_rcv_msg_doit
 tcp_v4_rcv                         mptcp_pm_nl_flush_addrs_doit
 tcp_v4_do_rcv                      mptcp_nl_remove_addrs_list
 tcp_rcv_established                mptcp_pm_remove_addrs_and_subflows
 tcp_data_queue                     remove_anno_list_by_saddr
 mptcp_incoming_options             mptcp_pm_del_add_timer
 mptcp_pm_del_add_timer             kfree(entry)

In removeannolistbysaddr(running on CPU2), after leaving the critical zone protected by "pm.lock", the entry will be released, which leads to the occurrence of uaf in the mptcppmdeladdtimer(running on CPU1).

Keeping a reference to addtimer inside the lock, and calling skstoptimersync() with this reference, instead of "entry->add_timer".

Move listdel(&entry->list) to mptcppmdeladd_timer and inside the pm lock, do not directly access any members of the entry outside the pm lock, which can avoid similar "entry->x" uaf.(CVE-2024-46858)

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

crypto: stm32/cryp - call finalize with bh disabled

The finalize operation in interrupt mode produce a produces a spinlock recursion warning. The reason is the fact that BH must be disabled during this process.(CVE-2024-47658)

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

spi: hisi-kunpeng: Add verification for the max_frequency provided by the firmware

If the value of maxspeedhz is 0, it may cause a division by zero error in hisicalceffectivespeed(). The value of maxspeedhz is provided by firmware. Firmware is generally considered as a trusted domain. However, as division by zero errors can cause system failure, for defense measure, the value of maxspeed is validated here. So 0 is regarded as invalid and an error code is returned.(CVE-2024-47664)

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

ocfs2: add bounds checking to ocfs2xattrfind_entry()

Add a paranoia check to make sure it doesn't stray beyond valid memory region containing ocfs2 xattr entries when scanning for a match. It will prevent out-of-bound access in case of crafted images.(CVE-2024-47670)

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

USB: usbtmc: prevent kernel-usb-infoleak

The syzbot reported a kernel-usb-infoleak in usbtmc_write, we need to clear the structure before filling fields.(CVE-2024-47671)

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

wifi: iwlwifi: mvm: don't wait for tx queues if firmware is dead

There is a WARNING in iwltranswaittxqueues_empty() (that was recently converted from just a message), that can be hit if we wait for TX queues to become empty after firmware died. Clearly, we can't expect anything from the firmware after it's declared dead.

Don't call iwltranswaittxqueues_empty() in this case. While it could be a good idea to stop the flow earlier, the flush functions do some maintenance work that is not related to the firmware, so keep that part of the code running even when the firmware is not running.

edit commit message