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

ipv4: Fix uninit-value access in ipmakeskb()

KMSAN reported uninit-value access in ipmakeskb() [1]. ipmakeskb() tests HDRINCL to know if the skb has icmphdr. However, HDRINCL can cause a race condition. If calling setsockopt(2) with IPHDRINCL changes HDRINCL while ipmakeskb() is running, the function will access icmphdr in the skb even if it is not included. This causes the issue reported by KMSAN.

Check FLOWIFLAGKNOWNNH on fl4->flowi4flags instead of testing HDRINCL on the socket.

Also, fl4->fl4icmptype and fl4->fl4icmpcode are not initialized. These are union in struct flowi4 and are implicitly initialized by flowi4initoutput(), but we should not rely on specific union layout.

Initialize these explicitly in rawsendmsg().

[1] BUG: KMSAN: uninit-value in ipmakeskb+0x2b74/0x2d20 net/ipv4/ipoutput.c:1481 ipmakeskb+0x2b74/0x2d20 net/ipv4/ipoutput.c:1481 ipfinishskb include/net/ip.h:243 [inline] ippushpendingframes+0x4c/0x5c0 net/ipv4/ipoutput.c:1508 rawsendmsg+0x2381/0x2690 net/ipv4/raw.c:654 inetsendmsg+0x27b/0x2a0 net/ipv4/afinet.c:851 socksendmsgnosec net/socket.c:730 [inline] socksendmsg+0x274/0x3c0 net/socket.c:745 syssendto+0x62c/0x7b0 net/socket.c:2191 dosyssendto net/socket.c:2203 [inline] sesyssendto net/socket.c:2199 [inline] x64syssendto+0x130/0x200 net/socket.c:2199 dosyscall64+0xd8/0x1f0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x6d/0x75

Uninit was created at: slabpostallochook mm/slub.c:3804 [inline] slaballocnode mm/slub.c:3845 [inline] kmemcacheallocnode+0x5f6/0xc50 mm/slub.c:3888 kmallocreserve+0x13c/0x4a0 net/core/skbuff.c:577 allocskb+0x35a/0x7c0 net/core/skbuff.c:668 allocskb include/linux/skbuff.h:1318 [inline] ipappenddata+0x49ab/0x68c0 net/ipv4/ipoutput.c:1128 ipappenddata+0x1e7/0x260 net/ipv4/ipoutput.c:1365 rawsendmsg+0x22b1/0x2690 net/ipv4/raw.c:648 inetsendmsg+0x27b/0x2a0 net/ipv4/afinet.c:851 socksendmsgnosec net/socket.c:730 [inline] socksendmsg+0x274/0x3c0 net/socket.c:745 syssendto+0x62c/0x7b0 net/socket.c:2191 dosyssendto net/socket.c:2203 [inline] sesyssendto net/socket.c:2199 [inline] x64syssendto+0x130/0x200 net/socket.c:2199 dosyscall64+0xd8/0x1f0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x6d/0x75

CPU: 1 PID: 15709 Comm: syz-executor.7 Not tainted 6.8.0-11567-gb3603fcb79b1 #25 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014

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

wifi: iwlwifi: mvm: ensure offloading TID queue exists

The Linux kernel CVE team has assigned CVE-2024-27056 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050115-CVE-2024-27056-98c0@gregkh/T

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

net/sched: Fix mirred deadlock on device recursion

The Linux kernel CVE team has assigned CVE-2024-27010 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050148-CVE-2024-27010-5a68@gregkh/T

Android contains an unspecified vulnerability in the kernel that allows for remote code execution. This vulnerability resides in Linux Kernel and could impact other products, including but not limited to Android OS.

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

sched/membarrier: reduce the ability to hammer on sysmembarrier

On some systems, sysmembarrier 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.

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

powerpc/eeh: avoid possible crash when edev->pdev changes

If a PCI device is removed during eehpereportedev(), edev->pdev will change and can cause a crash, hold the PCI rescan/remove lock while taking a copy of edev->pdev->bus.

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

drm/vmwgfx: Fix the lifetime of the bo cursor memory

The cleanup can be dispatched while the atomic update is still active, which means that the memory acquired in the atomic update needs to not be invalidated by the cleanup. The buffer objects in vmwplanestate instead of using the builtin mapandcache were trying to handle the lifetime of the mapped memory themselves, leading to crashes.

Use the mapandcache instead of trying to manage the lifetime of the buffer objects held by the vmwplanestate.

Fixes kernel oops'es in IGT's kmscursorlegacy forked-bo.

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

misc: lis3lv02di2c: Fix regulators getting en-/dis-abled twice on suspend/resume

The Linux kernel CVE team has assigned CVE-2024-35824 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051737-CVE-2024-35824-7302@gregkh/T

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

ext4: fix corruption during on-line resize

The Linux kernel CVE team has assigned CVE-2024-35807 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051740-CVE-2024-35807-2a9e@gregkh/T

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

net/mlx5e: fix a double-free in arfscreategroups

The Linux kernel CVE team has assigned CVE-2024-35835 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051730-CVE-2024-35835-d75f@gregkh/T

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

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

Input: aiptek - properly check endpoint type

Syzbot reported warning in usbsubmiturb() which is caused by wrong endpoint type. There was a check for the number of endpoints, but not for the type of endpoint.

Fix it by replacing old desc.bNumEndpoints check with usbfindcommonendpoints() helper for finding endpoints

Fail log:

usb 5-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 2 PID: 48 at drivers/usb/core/urb.c:502 usbsubmiturb+0xed2/0x18a0 drivers/usb/core/urb.c:502 Modules linked in: CPU: 2 PID: 48 Comm: kworker/2:2 Not tainted 5.17.0-rc6-syzkaller-00226-g07ebd38a0da2 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Workqueue: usbhubwq hubevent ... Call Trace: aiptekopen+0xd5/0x130 drivers/input/tablet/aiptek.c:830 inputopendevice+0x1bb/0x320 drivers/input/input.c:629 kbdconnect+0xfe/0x160 drivers/tty/vt/keyboard.c:1593

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

cppccpufreq: Fix possible null pointer dereference

cppccpufreqgetrate() and hisicppccpufreqgetrate() can be called from different places with various parameters. So cpufreqcpuget() can return null as 'policy' in some circumstances. Fix this bug by adding null return check.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

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

irqchip/gic-v3-its: Prevent double free on error

The error handling path in itsvpeirqdomainalloc() causes a double free when itsvpeinit() fails after successfully allocating at least one interrupt. This happens because itsvpeirqdomainfree() frees the interrupts along with the area bitmap and the vproppage and itsvpeirqdomainalloc() subsequently frees the area bitmap and the vproppage again.

Fix this by unconditionally invoking itsvpeirqdomainfree() which handles all cases correctly and by removing the bitmap/vproppage freeing from itsvpeirqdomainalloc().

[ tglx: Massaged change log ]

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

mlxsw: spectrumacltcam: Fix possible use-after-free during rehash

The Linux kernel CVE team has assigned CVE-2024-35854 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051740-CVE-2024-35854-d17b@gregkh/T

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

mlxsw: spectrumacltcam: Fix possible use-after-free during activity update

The Linux kernel CVE team has assigned CVE-2024-35855 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051741-CVE-2024-35855-c1fb@gregkh/T

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

netfilter: nftables: use timestamp to check for set element timeout

Add a timestamp field at the beginning of the transaction, store it in the nftables per-netns area.

Update set backend .insert, .deactivate and sync gc path to use the timestamp, this avoids that an element expires while control plane transaction is still unfinished.

.lookup and .update, which are used from packet path, still use the current time to check if the element has expired. And .get path and dump also since this runs lockless under rcu read size lock. Then, there is async gc which also needs to check the current time since it runs asynchronously from a workqueue.

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

powerpc/pseries: Fix potential memleak in paprgetattr()

buf is allocated in paprgetattr(), and krealloc() of buf could fail. We need to free the original buf in the case of failure.

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

crypto: qat - resolve race condition during AER recovery

During the PCI AER system's error recovery process, the kernel driver may encounter a race condition with freeing the resetdata structure's memory. If the device restart will take more than 10 seconds the function scheduling that restart will exit due to a timeout, and the resetdata structure will be freed. However, this data structure is used for completion notification after the restart is completed, which leads to a UAF bug.

This results in a KFENCE bug notice.

BUG: KFENCE: use-after-free read in adfdeviceresetworker+0x38/0xa0 [intelqat] Use-after-free read at 0x00000000bc56fddf (in kfence-#142): adfdeviceresetworker+0x38/0xa0 [intelqat] processonework+0x173/0x340

To resolve this race condition, the memory associated to the container of the workstruct is freed on the worker if the timeout expired, otherwise on the function that schedules the worker. The timeout detection can be done by checking if the caller is still waiting for completion or not by using completiondone() function.

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

netfilter: nftables: Fix potential data-race in nftobjtypeget()

nftunregisterobj() can concurrent with nftobjtypeget(), and there is not any protection when iterate over nftablesobjects list in nftobjtypeget(). Therefore, there is potential data-race of nftablesobjects list entry.

Use listforeachentryrcu() to iterate over nftablesobjects list in nftobjtypeget(), and use rcureadlock() in the caller nftobjtypeget() to protect the entire type query process.

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

net/mlx5e: Prevent deadlock while disabling aRFS

The Linux kernel CVE team has assigned CVE-2024-27014 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050149-CVE-2024-27014-d2dc@gregkh/T

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

USB: core: Fix deadlock in port "disable" sysfs attribute

The show and store callback routines for the "disable" sysfs attribute file in port.c acquire the device lock for the port's parent hub device. This can cause problems if another process has locked the hub to remove it or change its configuration:

Removing the hub or changing its configuration requires the hub interface to be removed, which requires the port device to be removed, and devicedel() waits until all outstanding sysfs attribute callbacks for the ports have returned. The lock can't be released until then.

But the disableshow() or disablestore() routine can't return until after it has acquired the lock.

The resulting deadlock can be avoided by calling sysfsbreakactiveprotection(). This will cause the sysfs core not to wait for the attribute's callback routine to return, allowing the removal to proceed. The disadvantage is that after making this call, there is no guarantee that the hub structure won't be deallocated at any moment. To prevent this, we have to acquire a reference to it first by calling hubget().

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

USB: core: Fix deadlock in usbdeauthorizeinterface()

Among the attribute file callback routines in drivers/usb/core/sysfs.c, the interfaceauthorizedstore() function is the only one which acquires a device lock on an ancestor device: It calls usbdeauthorizeinterface(), which locks the interface's parent USB device.

The will lead to deadlock if another process already owns that lock and tries to remove the interface, whether through a configuration change or because the device has been disconnected. As part of the removal procedure, devicedel() waits for all ongoing sysfs attribute callbacks to complete. But usbdeauthorizeinterface() can't complete until the device lock has been released, and the lock won't be released until the removal has finished.

The mechanism provided by sysfs to prevent this kind of deadlock is to use the sysfsbreakactiveprotection() function, which tells sysfs not to wait for the attribute callback.

Reported-and-tested by: Yue Sun <samsun1006219@gmail.com> Reported by: xingwei lee <xrivendell7@gmail.com>

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

netfilter: nftables: Fix potential data-race in nftexprtypeget()

nftunregisterexpr() can concurrent with nftexprtypeget(), and there is not any protection when iterate over nftablesexpressions list in nftexprtypeget(). Therefore, there is potential data-race of nftablesexpressions list entry.

Use listforeachentryrcu() to iterate over nftablesexpressions list in nftexprtypeget(), and use rcureadlock() in the caller nftexprtypeget() to protect the entire type query process.

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

nfs: fix UAF in direct writes

In production we have been hitting the following warning consistently

------------[ cut here ]------------ refcountt: underflow; use-after-free. WARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcountwarnsaturate+0x9c/0xe0 Workqueue: nfsiod nfsdirectwriteschedulework [nfs] RIP: 0010:refcountwarnsaturate+0x9c/0xe0 PKRU: 55555554 Call Trace: ? warn+0x9f/0x130 ? refcountwarnsaturate+0x9c/0xe0 ? reportbug+0xcc/0x150 ? handlebug+0x3d/0x70 ? excinvalidop+0x16/0x40 ? asmexcinvalidop+0x16/0x20 ? refcountwarnsaturate+0x9c/0xe0 nfsdirectwriteschedulework+0x237/0x250 [nfs] processonework+0x12f/0x4a0 workerthread+0x14e/0x3b0 ? ZSTDgetCParamsinternal+0x220/0x220 kthread+0xdc/0x120 ? btfnamevalid+0xa0/0xa0 retfromfork+0x1f/0x30

This is because we're completing the nfsdirectrequest twice in a row.

The source of this is when we have our commit requests to submit, we process them and send them off, and then in the completion path for the commit requests we have

if (nfscommitend(cinfo.mds)) nfsdirectwritecomplete(dreq);

However since we're submitting asynchronous requests we sometimes have one that completes before we submit the next one, so we end up calling complete on the nfsdirectrequest twice.

The only other place we use nfsgenericcommitlist() is in nfscommitinode, which wraps this call in a

nfscommitbegin(); nfscommitend();

Which is a common pattern for this style of completion handling, one that is also repeated in the direct code with getdreq()/putdreq() calls around where we process events as well as in the completion paths.

Fix this by using the same pattern for the commit requests.

Before with my 200 node rocksdb stress running this warning would pop every 10ish minutes. With my patch the stress test has been running for several hours without popping.

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

net: iptunnel: prevent perpetual headroom growth

syzkaller triggered following kasan splat: BUG: KASAN: use-after-free in skbflowdissect+0x19d1/0x7a50 net/core/flowdissector.c:1170 Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191 [..] kasanreport+0xda/0x110 mm/kasan/report.c:588 skbflowdissect+0x19d1/0x7a50 net/core/flowdissector.c:1170 skbflowdissectflowkeys include/linux/skbuff.h:1514 [inline] skbgethash net/core/flowdissector.c:1791 [inline] skbgethash+0xc7/0x540 net/core/flowdissector.c:1856 skbgethash include/linux/skbuff.h:1556 [inline] iptunnelxmit+0x1855/0x33c0 net/ipv4/iptunnel.c:748 ipiptunnelxmit+0x3cc/0x4e0 net/ipv4/ipip.c:308 netdevstartxmit include/linux/netdevice.h:4940 [inline] netdevstartxmit include/linux/netdevice.h:4954 [inline] xmitone net/core/dev.c:3548 [inline] devhardstartxmit+0x13d/0x6d0 net/core/dev.c:3564 devqueuexmit+0x7c1/0x3d60 net/core/dev.c:4349 devqueuexmit include/linux/netdevice.h:3134 [inline] neighconnectedoutput+0x42c/0x5d0 net/core/neighbour.c:1592 ... ipfinishoutput2+0x833/0x2550 net/ipv4/ipoutput.c:235 ipfinishoutput+0x31/0x310 net/ipv4/ipoutput.c:323 .. iptunnelxmit+0x5b4/0x9b0 net/ipv4/iptunnelcore.c:82 iptunnelxmit+0x1dbc/0x33c0 net/ipv4/iptunnel.c:831 ipgrexmit+0x4a1/0x980 net/ipv4/ipgre.c:665 netdevstartxmit include/linux/netdevice.h:4940 [inline] netdevstartxmit include/linux/netdevice.h:4954 [inline] xmitone net/core/dev.c:3548 [inline] devhardstartxmit+0x13d/0x6d0 net/core/dev.c:3564 ...

The splat occurs because skb->data points past skb->head allocated area. This is because neigh layer does: skbpull(skb, skbnetworkoffset(skb));

... but skbnetworkoffset() returns a negative offset and skbpull() arg is unsigned. IOW, we skb->data gets "adjusted" by a huge value.

The negative value is returned because skb->head and skb->data distance is more than 64k and skb->networkheader (u16) has wrapped around.

The bug is in the iptunnel infrastructure, which can cause dev->neededheadroom to increment ad infinitum.

The syzkaller reproducer consists of packets getting routed via a gre tunnel, and route of gre encapsulated packets pointing at another (ipip) tunnel. The ipip encapsulation finds gre0 as next output device.

This results in the following pattern:

1). First packet is to be sent out via gre0. Route lookup found an output device, ipip0.

2). iptunnelxmit for gre0 bumps gre0->neededheadroom based on the future output device, rt.dev->neededheadroom (ipip0).

3). ip output / startxmit moves skb on to ipip0. which runs the same code path again (xmit recursion).

4). Routing step for the post-gre0-encap packet finds gre0 as output device to use for ipip0 encapsulated packet.

tunl0->neededheadroom is then incremented based on the (already bumped) gre0 device headroom.

This repeats for every future packet:

gre0->neededheadroom gets inflated because previous packets' ipip0 step incremented rt->dev (gre0) headroom, and ipip0 incremented because gre0 neededheadroom was increased.

For each subsequent packet, gre/ipip0->neededheadroom grows until post-expand-head reallocations result in a skb->head/data distance of more than 64k.

Once that happens, skb->networkheader (u16) wraps around when pskbexpandhead tries to make sure that skbnetworkoffset() is unchanged after the headroom expansion/reallocation.

After this skbnetworkoffset(skb) returns a different (and negative) result post headroom expansion.

The next trip to neigh layer (or anything else that would skbpull the network header) makes skb->data point to a memory location outside skb->head area.

v2: Cap the neededheadroom update to an arbitarily chosen upperlimit to prevent perpetual increase instead of dropping the headroom increment completely.

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

Bluetooth: Avoid potential use-after-free in hcierrorreset

The Linux kernel CVE team has assigned CVE-2024-26801 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024040403-CVE-2024-26801-da9f@gregkh/T

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

mtd: require write permissions for locking and badblock ioctls

MEMLOCK, MEMUNLOCK and OTPLOCK modify protection bits. Thus require write permission. Depending on the hardware MEMLOCK might even be write-once, e.g. for SPI-NOR flashes with their WP# tied to GND. OTPLOCK is always write-once.

MEMSETBADBLOCK modifies the bad block table.

gfs2: Fix kernel NULL pointer dereference in gfs2rgrpdump

Syzkaller has reported a NULL pointer dereference when accessing rgd->rdrgl in gfs2rgrpdump(). This can happen when creatingrgd->rdgl fails in readrindexentry(). Add a NULL pointer check in gfs2rgrpdump() to prevent that.

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

Squashfs: check the inode number is not the invalid value of zero

Syskiller has produced an out of bounds access in fillmetaindex().

That out of bounds access is ultimately caused because the inode has an inode number with the invalid value of zero, which was not checked.

The reason this causes the out of bounds access is due to following sequence of events:

1. Fillmetaindex() is called to allocate (via emptymetaindex()) and fill a metadata index. It however suffers a data read error and aborts, invalidating the newly returned empty metadata index. It does this by setting the inode number of the index to zero, which means unused (zero is not a valid inode number).

2. When fillmetaindex() is subsequently called again on another read operation, locatemetaindex() returns the previous index because it matches the inode number of 0. Because this index has been returned it is expected to have been filled, and because it hasn't been, an out of bounds access is performed.

This patch adds a sanity check which checks that the inode number is not zero when the inode is created and returns -EINVAL if it is.

[phillip@squashfs.org.uk: whitespace fix]