gfs2: Fix NULL pointer dereference in gfs2logflush

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

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

ALSA: usb-audio: Fix out of bounds reads when finding clock sources

The current USB-audio driver code doesn't check bLength of each descriptor at traversing for clock descriptors. That is, when a device provides a bogus descriptor with a shorter bLength, the driver might hit out-of-bounds reads.

For addressing it, this patch adds sanity checks to the validator functions for the clock descriptor traversal. When the descriptor length is shorter than expected, it's skipped in the loop.

For the clock source and clock multiplier descriptors, we can just check bLength against the sizeof() of each descriptor type. OTOH, the clock selector descriptor of UAC2 and UAC3 has an array of bNrInPins elements and two more fields at its tail, hence those have to be checked in addition to the sizeof() check.

An out of bounds write exists in FreeType versions 2.13.0 and below (newer versions of FreeType are not vulnerable) when attempting to parse font subglyph structures related to TrueType GX and variable font files. The vulnerable code assigns a signed short value to an unsigned long and then adds a static value causing it to wrap around and allocate too small of a heap buffer. The code then writes up to 6 signed long integers out of bounds relative to this buffer. This may result in arbitrary code execution. This vulnerability may have been exploited in the wild.

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:

netfilter: bridge: replace physindev with physinif in nfbridgeinfo

An skb can be added to a neigh->arpqueue while waiting for an arp reply. Where original skb's skb->dev can be different to neigh's neigh->dev. For instance in case of bridging dnated skb from one veth to another, the skb would be added to a neigh->arpqueue of the bridge.

As skb->dev can be reset back to nfbridge->physindev and used, and as there is no explicit mechanism that prevents this physindev from been freed under us (for instance neighflushdev doesn't cleanup skbs from different device's neigh queue) we can crash on e.g. this stack:

arpprocess neighupdate skb = skbdequeue(&neigh->arpqueue) neighresolveoutput(..., skb) ... brnfdevxmit brnfpreroutingfinishbridgeslow skb->dev = nfbridge->physindev brhandleframefinish

Let's use plain ifindex instead of netdevice link. To peek into the original netdevice we will use devgetbyindexrcu(). Thus either we get device and are safe to use it or we don't get it and drop skb.

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:

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

nftunregisterflowtabletype() within nfflowinetmoduleexit() can concurrent with nftflowtabletypeget() within nftablesnewflowtable(). And thhere is not any protection when iterate over nftablesflowtables list in nftflowtabletypeget(). Therefore, there is pertential data-race of nftablesflowtables list entry.

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

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: nftsetpipapo: walk over current view on netlink dump

The generation mask can be updated while netlink dump is in progress. The pipapo set backend walk iterator cannot rely on it to infer what view of the datastructure is to be used. Add notation to specify if user wants to read/update the set.

Based on patch from Florian Westphal.

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.