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

net: ks8851: Handle softirqs at the end of IRQ thread to fix hang

The ks8851irq() thread may call ks8851rxpkts() in case there are any packets in the MAC FIFO, which calls netifrx(). This netifrx() implementation is guarded by localbhdisable() and localbhenable(). The localbhenable() may call dosoftirq() to run softirqs in case any are pending. One of the softirqs is netrxaction, which ultimately reaches the driver .startxmit callback. If that happens, the system hangs. The entire call chain is below:

ks8851startxmitpar from netdevstartxmit netdevstartxmit from devhardstartxmit devhardstartxmit from schdirectxmit schdirectxmit from devqueuexmit devqueuexmit from neighupdate neighupdate from neighupdate neighupdate from arpprocess.constprop.0 arpprocess.constprop.0 from netifreceiveskbonecore netifreceiveskbonecore from processbacklog processbacklog from napipoll.constprop.0 napipoll.constprop.0 from netrxaction netrxaction from dosoftirq dosoftirq from callwithstack callwithstack from dosoftirq dosoftirq from localbhenableip localbhenableip from netifrx netifrx from ks8851irq ks8851irq from irqthreadfn irqthreadfn from irqthread irqthread from kthread kthread from retfromfork

The hang happens because ks8851irq() first locks a spinlock in ks8851par.c ks8851lockpar() spinlockirqsave(&ksp->lock, ...) and with that spinlock locked, calls netifrx(). Once the execution reaches ks8851startxmitpar(), it calls ks8851lockpar() again which attempts to claim the already locked spinlock again, and the hang happens.

Move the dosoftirq() call outside of the spinlock protected section of ks8851irq() by disabling BHs around the entire spinlock protected section of ks8851irq() handler. Place localbhenable() outside of the spinlock protected section, so that it can trigger dosoftirq() without the ks8851par.c ks8851lockpar() spinlock being held, and safely call ks8851startxmitpar() without attempting to lock the already locked spinlock.

Since ks8851irq() is protected by localbhdisable()/localbhenable() now, replace netifrx() with netifrx() which is not duplicating the localbhdisable()/localbhenable() calls.

drm/panfrost: Fix the error path in panfrostmmumapfaultaddr()

ax25: fix use-after-free bugs caused by ax25dsdeltimer

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

smb: client: fix potential UAF in cifsstatsprocwrite()

Skip sessions that are being teared down (status == SESEXITING) to avoid UAF.

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

regmap: maple: Fix cache corruption in regcachemapledrop()

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

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024053044-CVE-2024-36019-59fb@gregkh/T

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

epoll: be better about file lifetimes

epoll can call out to vfspoll() with a file pointer that may race with the last 'fput()'. That would make fcount go down to zero, and while the ep->mtx locking means that the resulting file pointer tear-down will be blocked until the poll returns, it means that fcount is already dead, and any use of it won't actually get a reference to the file any more: it's dead regardless.

Make sure we have a valid ref on the file pointer before we call down to vfspoll() from the epoll routines.

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

drm/amdgpu/mes: fix use-after-free issue

Delete fence fallback timer to fix the ramdom use-after-free issue.

v2: move to amdgpumes.c

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:

net: phy: micrel: Fix potential null pointer dereference

In lan8814getsigrx() and lan8814getsigtx() ptpparseheader() may return NULL as ptpheader due to abnormal packet type or corrupted packet. Fix this bug by adding ptpheader check.

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

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: 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:

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:

scsi: qla2xxx: Fix double free of the ha->vpmap pointer

Coverity scan reported potential risk of double free of the pointer ha->vpmap. ha->vpmap was freed in qla2x00memalloc(), and again freed in function qla2x00memfree(ha).

Assign NULL to vpmap and kfree take care of NULL.

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:

drm/i915/vma: Fix UAF on destroy against retire race

Object debugging tools were sporadically reporting illegal attempts to free a still active i915 VMA object when parking a GT believed to be idle.

[161.359441] ODEBUG: free active (active state 0) object: ffff88811643b958 object type: i915active hint: i915vmaactive+0x0/0x50 [i915] [161.360082] WARNING: CPU: 5 PID: 276 at lib/debugobjects.c:514 debugprintobject+0x80/0xb0 ... [161.360304] CPU: 5 PID: 276 Comm: kworker/5:2 Not tainted 6.5.0-rc1-CIDRM13375-g003f860e5577+ #1 [161.360314] Hardware name: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 04/21/2022 [161.360322] Workqueue: i915-unordered intelwakerefputwork [i915] [161.360592] RIP: 0010:debugprintobject+0x80/0xb0 ... [161.361347] debugobjectfree+0xeb/0x110 [161.361362] i915activefini+0x14/0x130 [i915] [161.361866] releasereferences+0xfe/0x1f0 [i915] [161.362543] i915vmaparked+0x1db/0x380 [i915] [161.363129] gtpark+0x121/0x230 [i915] [161.363515] intelwakerefputlast+0x1f/0x70 [i915]

That has been tracked down to be happening when another thread is deactivating the VMA inside activeretire() helper, after the VMA's active counter has been already decremented to 0, but before deactivation of the VMA's object is reported to the object debugging tool.

We could prevent from that race by serializing i915activefini() with activeretire() via ref->treelock, but that wouldn't stop the VMA from being used, e.g. from i915vmaretire() called at the end of activeretire(), after that VMA has been already freed by a concurrent i915vmadestroy() on return from the i915activefini(). Then, we should rather fix the issue at the VMA level, not in i915active.

Since i915vmaparked() is called from gtpark() on last put of the GT's wakeref, the issue could be addressed by holding the GT wakeref long enough for activeretire() to complete before that wakeref is released and the GT parked.

I believe the issue was introduced by commit d93939730347 ("drm/i915: Remove the vma refcount") which moved a call to i915activefini() from a dropped i915vmarelease(), called on last put of the removed VMA kref, to i915vmaparked() processing path called on last put of a GT wakeref. However, its visibility to the object debugging tool was suppressed by a bug in i915active that was fixed two weeks later with commit e92eb246feb9 ("drm/i915/active: Fix missing debug object activation").

A VMA associated with a request doesn't acquire a GT wakeref by itself. Instead, it depends on a wakeref held directly by the request's active intelcontext for a GT associated with its VM, and indirectly on that intelcontext's engine wakeref if the engine belongs to the same GT as the VMA's VM. Those wakerefs are released asynchronously to VMA deactivation.

Fix the issue by getting a wakeref for the VMA's GT when activating it, and putting that wakeref only after the VMA is deactivated. However, exclude global GTT from that processing path, otherwise the GPU never goes idle. Since i915vmaretire() may be called from atomic contexts, use async variant of wakeref put. Also, to avoid circular locking dependency, take care of acquiring the wakeref before VM mutex when both are needed.

v7: Add inline comments with justifications for: - using untracked variants of intelgtpmget/put() (Nirmoy), - using async variant of put(), - not getting the wakeref in case of a global GTT, - always getting the first wakeref outside vm->mutex. v6: Since i915vmaactive/retire() callbacks are not serialized, storing a wakeref tracking handle inside struct i915vma is not safe, and there is no other good place for that. Use untracked variants of intelgtpmget/putasync(). v5: Replace "tile" with "GT" across commit description (Rodrigo), - ---truncated---

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]

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

smb: client: fix potential UAF in cifsstatsprocshow()

Skip sessions that are being teared down (status == SESEXITING) to avoid UAF.

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

smb: client: fix potential UAF in cifsdumpfullkey()

Skip sessions that are being teared down (status == SESEXITING) to avoid UAF.

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

smb: client: fix potential UAF in cifsdebugfilesprocshow()

Skip sessions that are being teared down (status == SESEXITING) to avoid UAF.

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.

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

interconnect: Don't access reqlist while it's being manipulated

The icclock mutex was split into separate icclock and iccbwlock mutexes in [1] to avoid lockdep splats. However, this didn't adequately protect access to iccnode::reqlist.

The iccsetbw() function will eventually iterate over reqlist while only holding iccbwlock, but reqlist can be modified while only holding icclock. This causes races between iccsetbw(), oficcget(), and iccput().

Example A:

CPU0 CPU1 ---- ---- iccsetbw(patha) mutexlock(&iccbwlock); iccput(pathb) mutexlock(&icclock); aggregaterequests() hlistforeachentry(r, ... hlistdel(... <r = invalid pointer>

Example B:

CPU0 CPU1 ---- ---- iccsetbw(patha) mutexlock(&iccbwlock); pathb = oficcget() oficcgetbyindex() mutexlock(&icclock); pathfind() pathinit() aggregaterequests() hlistforeachentry(r, ... hlistaddhead(... <r = invalid pointer>

Fix this by ensuring iccbwlock is always held before manipulating iccnode::reqlist. The additional places iccbwlock is held don't perform any memory allocations, so we should still be safe from the original lockdep splats that motivated the separate locks.

[1] commit af42269c3523 ("interconnect: Fix locking for runpm vs reclaim")

ax25: Fix netdev refcount issue

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

drm/amdkfd: don't allow mapping the MMIO HDP page with large pages

We don't get the right offset in that case. The GPU has an unused 4K area of the register BAR space into which you can remap registers. We remap the HDP flush registers into this space to allow userspace (CPU or GPU) to flush the HDP when it updates VRAM. However, on systems with >4K pages, we end up exposing PAGESIZE of MMIO space.

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

fs/9p: only translate RWX permissions for plain 9P2000

Garbage in plain 9P2000's perm bits is allowed through, which causes it to be able to set (among others) the suid bit. This was presumably not the intent since the unix extended bits are handled explicitly and conditionally on .u.

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

tracefs: Reset permissions on remount if permissions are options

There's an inconsistency with the way permissions are handled in tracefs. Because the permissions are generated when accessed, they default to the root inode's permission if they were never set by the user. If the user sets the permissions, then a flag is set and the permissions are saved via the inode (for tracefs files) or an internal attribute field (for eventfs).

But if a remount happens that specify the permissions, all the files that were not changed by the user gets updated, but the ones that were are not. If the user were to remount the file system with a given permission, then all files and directories within that file system should be updated.

This can cause security issues if a file's permission was updated but the admin forgot about it. They could incorrectly think that remounting with permissions set would update all files, but miss some.

For example:

# cd /sys/kernel/tracing # chgrp 1002 currenttracer # ls -l [..] -rw-r----- 1 root root 0 May 1 21:25 buffersizekb -rw-r----- 1 root root 0 May 1 21:25 buffersubbufsizekb -r--r----- 1 root root 0 May 1 21:25 buffertotalsizekb -rw-r----- 1 root lkp 0 May 1 21:25 currenttracer -rw-r----- 1 root root 0 May 1 21:25 dynamicevents -r--r----- 1 root root 0 May 1 21:25 dynftracetotalinfo -r--r----- 1 root root 0 May 1 21:25 enabledfunctions

Where currenttracer now has group "lkp".

# mount -o remount,gid=1001 . # ls -l -rw-r----- 1 root tracing 0 May 1 21:25 buffersizekb -rw-r----- 1 root tracing 0 May 1 21:25 buffersubbufsizekb -r--r----- 1 root tracing 0 May 1 21:25 buffertotalsizekb -rw-r----- 1 root lkp 0 May 1 21:25 currenttracer -rw-r----- 1 root tracing 0 May 1 21:25 dynamicevents -r--r----- 1 root tracing 0 May 1 21:25 dynftracetotalinfo -r--r----- 1 root tracing 0 May 1 21:25 enabledfunctions

Everything changed but the "currenttracer".

Add a new link list that keeps track of all the tracefsinodes which has the permission flags that tell if the file/dir should use the root inode's permission or not. Then on remount, clear all the flags so that the default behavior of using the root inode's permission is done for all files and directories.

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

thermal/debugfs: Fix two locking issues with thermal zone debug

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

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024060344-CVE-2024-36961-58bb@gregkh/T

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

drm/vmwgfx: Fix invalid reads in fence signaled events

Correctly set the length of the drmevent to the size of the structure that's actually used.

The length of the drmevent was set to the parent structure instead of to the drmvmweventfence which is supposed to be read. drmread uses the length parameter to copy the event to the user space thus resuling in oob reads.