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

net/mlx5: Fix peer devlink set for SF representor devlink port

The cited patch change register devlink flow, and neglect to reflect the changes for peer devlink set logic. Peer devlink set is triggering a call trace if done after devlregister.[1]

Hence, align peer devlink set logic with register devlink flow.

[1] WARNING: CPU: 4 PID: 3394 at net/devlink/core.c:155 devlinkrelnestedinadd+0x177/0x180 CPU: 4 PID: 3394 Comm: kworker/u40:1 Not tainted 6.9.0-rc4forlinustmindebug202404161408 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5vhcaevent0 mlx5vhcastateworkhandler [mlx5core] RIP: 0010:devlinkrelnestedinadd+0x177/0x180 Call Trace: <TASK> ? warn+0x78/0x120 ? devlinkrelnestedinadd+0x177/0x180 ? reportbug+0x16d/0x180 ? handlebug+0x3c/0x60 ? excinvalidop+0x14/0x70 ? asmexcinvalidop+0x16/0x20 ? devlinkportinit+0x30/0x30 ? devlinkporttypeclear+0x50/0x50 ? devlinkrelnestedinadd+0x177/0x180 ? devlinkrelnestedinadd+0xdd/0x180 mlx5sfmdevevent+0x74/0xb0 [mlx5core] notifiercallchain+0x35/0xb0 blockingnotifiercallchain+0x3d/0x60 mlx5blockingnotifiercallchain+0x22/0x30 [mlx5core] mlx5sfdevprobe+0x185/0x3e0 [mlx5core] auxiliarybusprobe+0x38/0x80 ? driversysfsadd+0x51/0x80 reallyprobe+0xc5/0x3a0 ? driverprobedevice+0x90/0x90 driverprobedevice+0x80/0x160 driverprobedevice+0x1e/0x90 deviceattachdriver+0x7d/0x100 busforeachdrv+0x80/0xd0 deviceattach+0xbc/0x1f0 busprobedevice+0x86/0xa0 deviceadd+0x64f/0x860 auxiliarydeviceadd+0x3b/0xa0 mlx5sfdevadd+0x139/0x330 [mlx5core] mlx5sfdevstatechangehandler+0x1e4/0x250 [mlx5core] notifiercallchain+0x35/0xb0 blockingnotifiercallchain+0x3d/0x60 mlx5vhcastateworkhandler+0x151/0x200 [mlx5core] processonework+0x13f/0x2e0 workerthread+0x2bd/0x3c0 ? rescuerthread+0x410/0x410 kthread+0xc4/0xf0 ? kthreadcompleteandexit+0x20/0x20 retfromfork+0x2d/0x50 ? kthreadcompleteandexit+0x20/0x20 retfromforkasm+0x11/0x20 </TASK>

btrfs: scrub: handle RST lookup error correctly

bpf: Reject narrower access to pointer ctx fields

bpf: Fix invalid prog->stats access when updateeffectiveprogs fails

bpf: Do not let BPF test infra emit invalid GSO types to stack

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

scsi: smartpqi: Fix device resources accessed after device removal

Correct possible race conditions during device removal.

Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues.

This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdevdestroy(), leading to use-after-free and improper access to freed resources.

- Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped.

- Cancel any pending TMF work that has not started in sdevdestroy().

- Ensure device freeing in sdevdestroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.

bpf: Check skb->transportheader is set in bpfskbcheckmtu

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

ext4: refresh inline data size before write operations

The cached ei->iinlinesize can become stale between the initial size check and when ext4updateinlinedata()/ext4createinlinedata() use it. Although ext4getmaxinlinesize() reads the correct value at the time of the check, concurrent xattr operations can modify iinlinesize before ext4writelockxattr() is acquired.

This causes ext4updateinlinedata() and ext4createinlinedata() to work with stale capacity values, leading to a BUGON() crash in ext4writeinlinedata():

kernel BUG at fs/ext4/inline.c:1331! BUGON(pos + len > EXT4I(inode)->iinlinesize);

The race window: 1. ext4getmaxinlinesize() reads iinlinesize = 60 (correct) 2. Size check passes for 50-byte write 3. [Another thread adds xattr, iinlinesize changes to 40] 4. ext4writelockxattr() acquires lock 5. ext4updateinlinedata() uses stale iinlinesize = 60 6. Attempts to write 50 bytes but only 40 bytes actually available 7. BUGON() triggers

Fix this by recalculating iinlinesize via ext4findinlinedatanolock() immediately after acquiring xattrsem. This ensures ext4updateinlinedata() and ext4createinlinedata() work with current values that are protected from concurrent modifications.

This is similar to commit a54c4613dac1 ("ext4: fix race writing to an inlinedata file while its xattrs are changing") which fixed iinlineoff staleness. This patch addresses the related iinlinesize staleness issue.

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

netfilter: ctnetlink: remove refcounting in expectation dumpers

Same pattern as previous patch: do not keep the expectation object alive via refcount, only store a cookie value and then use that as the skip hint for dump resumption.

AFAICS this has the same issue as the one resolved in the conntrack dumper, when we do if (!refcountincnotzero(&exp->use))

to increment the refcount, there is a chance that exp == last, which causes a double-increment of the refcount and subsequent memory leak.

bpf: Forget ranges when refining tnum after JSET

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

net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY

DSA has 2 kinds of drivers:

1. Those who call dsaswitchsuspend() and dsaswitchresume() from their device PM ops: qca8k-8xxx, bcmsf2, microchip ksz 2. Those who don't: all others. The above methods should be optional.

For type 1, dsaswitchsuspend() calls dsausersuspend() -> phylinkstop(), and dsaswitchresume() calls dsauserresume() -> phylinkstart(). These seem good candidates for setting macmanagedpm = true because that is essentially its definition [1], but that does not seem to be the biggest problem for now, and is not what this change focuses on.

Talking strictly about the 2nd category of DSA drivers here (which do not have MAC managed PM, meaning that for their attached PHYs, mdiobusphysuspend() and mdiobusphyresume() should run in full), I have noticed that the following warning from mdiobusphyresume() is triggered:

WARNON(phydev->state != PHYHALTED && phydev->state != PHYREADY && phydev->state != PHYUP);

because the PHY state machine is running.

It's running as a result of a previous dsauseropen() -> ... -> phylinkstart() -> phystart() having been initiated by the user.

The previous mdiobusphysuspend() was supposed to have called phystopmachine(), but it didn't. So this is why the PHY is in state PHYNOLINK by the time mdiobusphyresume() runs.

mdiobusphysuspend() did not call phystopmachine() because for phylink, the phydev->adjustlink function pointer is NULL. This seems a technicality introduced by commit fddd91016d16 ("phylib: fix PAL state machine restart on resume"). That commit was written before phylink existed, and was intended to avoid crashing with consumer drivers which don't use the PHY state machine - phylink always does, when using a PHY. But phylink itself has historically not been developed with suspend/resume in mind, and apparently not tested too much in that scenario, allowing this bug to exist unnoticed for so long. Plus, prior to the WARNON(), it would have likely been invisible.

This issue is not in fact restricted to type 2 DSA drivers (according to the above ad-hoc classification), but can be extrapolated to any MAC driver with phylink and MDIO-bus-managed PHY PM ops. DSA is just where the issue was reported. Assuming macmanagedpm is set correctly, a quick search indicates the following other drivers might be affected:

$ grep -Zlr PHYLINKNETDEV drivers/ | xargs -0 grep -L macmanagedpm drivers/net/ethernet/atheros/ag71xx.c drivers/net/ethernet/microchip/sparx5/sparx5main.c drivers/net/ethernet/microchip/lan966x/lan966xmain.c drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c drivers/net/ethernet/freescale/fsenet/fsenet-main.c drivers/net/ethernet/freescale/dpaa/dpaaeth.c drivers/net/ethernet/freescale/uccgeth.c drivers/net/ethernet/freescale/enetc/enetcpfcommon.c drivers/net/ethernet/marvell/mvpp2/mvpp2main.c drivers/net/ethernet/marvell/mvneta.c drivers/net/ethernet/marvell/prestera/presteramain.c drivers/net/ethernet/mediatek/mtkethsoc.c drivers/net/ethernet/altera/alteratsemain.c drivers/net/ethernet/wangxun/txgbe/txgbephy.c drivers/net/ethernet/meta/fbnic/fbnicphylink.c drivers/net/ethernet/tehuti/tn40phy.c drivers/net/ethernet/mscc/ocelotnet.c

Make the existing conditions dependent on the PHY device having a phydev->phylinkchange() implementation equal to the default phylinkchange() provided by phylib. Otherwise, we implicitly know that the phydev has the phylink-provided phylinkphychange() callback, and when phylink is used, the PHY state machine always needs to be stopped/ started on the suspend/resume path. The code is structured as such that if phydev->phylinkchange() is absent, it is a matter of time until the kernel will crash - no need to further complicate the test.

Thus, for the situation where the PM is not managed b ---truncated---

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

net: Remove RTNL dance for SIOCBRADDIF and SIOCBRDELIF.

SIOCBRDELIF is passed to devioctl() first and later forwarded to brioctlcall(), which causes unnecessary RTNL dance and the splat below [0] under RTNL pressure.

Let's say Thread A is trying to detach a device from a bridge and Thread B is trying to remove the bridge.

In devioctl(), Thread A bumps the bridge device's refcnt by netdevhold() and releases RTNL because the following brioctlcall() also re-acquires RTNL.

In the race window, Thread B could acquire RTNL and try to remove the bridge device. Then, rtnlunlock() by Thread B will release RTNL and wait for netdevput() by Thread A.

Thread A, however, must hold RTNL after the unlock in devifsioc(), which may take long under RTNL pressure, resulting in the splat by Thread B.

Thread A (SIOCBRDELIF) Thread B (SIOCBRDELBR) ---------------------- ---------------------- sockioctl sockioctl - sockdoioctl - brioctlcall - devioctl - brioctlstub |- rtnllock | |- devifsioc ' ' |- dev = devgetbyname(...) |- netdevhold(dev, ...) . / |- rtnlunlock ------. | | |- brioctlcall ---> |- rtnllock Race | | - brioctlstub |- brdelbridge Window | | | |- dev = devgetbyname(...) | | | May take long | - brdevdelete(dev, ...) | | | under RTNL pressure | - unregisternetdevicequeue(dev, ...) | | | | - rtnlunlock \ | |- rtnllock <-' - netdevruntodo | |- ... - netdevruntodo | - rtnlunlock |- rtnlunlock | |- netdevwaitallrefsany |- netdevput(dev, ...) <----------------' Wait refcnt decrement and log splat below

To avoid blocking SIOCBRDELBR unnecessarily, let's not call devioctl() for SIOCBRADDIF and SIOCBRDELIF.

In the devioctl() path, we do the following:

1. Copy struct ifreq by getuserifreq in sockdoioctl() 2. Check CAPNETADMIN in devioctl() 3. Call devload() in devioctl() 4. Fetch the master dev from ifr.ifrname in devifsioc()

3. can be done by requestmodule() in brioctlcall(), so we move 1., 2., and 4. to brioctlstub().

Note that 2. is also checked later in adddelif(), but it's better performed before RTNL.

SIOCBRADDIF and SIOCBRDELIF have been processed in devioctl() since the pre-git era, and there seems to be no specific reason to process them there.

[0]: unregisternetdevice: waiting for wpan3 to become free. Usage count = 2 reftracker: wpan3@ffff8880662d8608 has 1/1 users at netdevtrackeralloc include/linux/netdevice.h:4282 [inline] netdevhold include/linux/netdevice.h:4311 [inline] devifsioc+0xc6a/0x1160 net/core/devioctl.c:624 devioctl+0x255/0x10c0 net/core/devioctl.c:826 sockdoioctl+0x1ca/0x260 net/socket.c:1213 sockioctl+0x23a/0x6c0 net/socket.c:1318 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:906 [inline] sesysioctl fs/ioctl.c:892 [inline] x64sysioctl+0x1a4/0x210 fs/ioctl.c:892 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcb/0x250 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

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

PM: hibernate: Avoid deadlock in hibernatecompressorparamset()

syzbot reported a deadlock in locksystemsleep() (see below).

The write operation to "/sys/module/hibernate/parameters/compressor" conflicts with the registration of ieee80211 device, resulting in a deadlock when attempting to acquire systemtransitionmutex under paramlock.

To avoid this deadlock, change hibernatecompressorparamset() to use mutextrylock() for attempting to acquire systemtransitionmutex and return -EBUSY when it fails.

Task flags need not be saved or adjusted before calling mutextrylock(&systemtransitionmutex) because the caller is not going to end up waiting for this mutex and if it runs concurrently with system suspend in progress, it will be frozen properly when it returns to user space.

syzbot report:

syz-executor895/5833 is trying to acquire lock: ffffffff8e0828c8 (systemtransitionmutex){+.+.}-{4:4}, at: locksystemsleep+0x87/0xa0 kernel/power/main.c:56

but task is already holding lock: ffffffff8e07dc68 (paramlock){+.+.}-{4:4}, at: kernelparamlock kernel/params.c:607 [inline] ffffffff8e07dc68 (paramlock){+.+.}-{4:4}, at: paramattrstore+0xe6/0x300 kernel/params.c:586

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #3 (paramlock){+.+.}-{4:4}: mutexlockcommon kernel/locking/mutex.c:585 [inline] mutexlock+0x19b/0xb10 kernel/locking/mutex.c:730 ieee80211ratecontrolopsget net/mac80211/rate.c:220 [inline] ratecontrolalloc net/mac80211/rate.c:266 [inline] ieee80211initratectrlalg+0x18d/0x6b0 net/mac80211/rate.c:1015 ieee80211registerhw+0x20cd/0x4060 net/mac80211/main.c:1531 mac80211hwsimnewradio+0x304e/0x54e0 drivers/net/wireless/virtual/mac80211hwsim.c:5558 initmac80211hwsim+0x432/0x8c0 drivers/net/wireless/virtual/mac80211hwsim.c:6910 dooneinitcall+0x128/0x700 init/main.c:1257 doinitcalllevel init/main.c:1319 [inline] doinitcalls init/main.c:1335 [inline] dobasicsetup init/main.c:1354 [inline] kernelinitfreeable+0x5c7/0x900 init/main.c:1568 kernelinit+0x1c/0x2b0 init/main.c:1457 retfromfork+0x45/0x80 arch/x86/kernel/process.c:148 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:244

-> #2 (rtnlmutex){+.+.}-{4:4}: mutexlockcommon kernel/locking/mutex.c:585 [inline] mutexlock+0x19b/0xb10 kernel/locking/mutex.c:730 wgpmnotification drivers/net/wireguard/device.c:80 [inline] wgpmnotification+0x49/0x180 drivers/net/wireguard/device.c:64 notifiercallchain+0xb7/0x410 kernel/notifier.c:85 notifiercallchainrobust kernel/notifier.c:120 [inline] blockingnotifiercallchainrobust kernel/notifier.c:345 [inline] blockingnotifiercallchainrobust+0xc9/0x170 kernel/notifier.c:333 pmnotifiercallchainrobust+0x27/0x60 kernel/power/main.c:102 snapshotopen+0x189/0x2b0 kernel/power/user.c:77 miscopen+0x35a/0x420 drivers/char/misc.c:179 chrdevopen+0x237/0x6a0 fs/chardev.c:414 dodentryopen+0x735/0x1c40 fs/open.c:956 vfsopen+0x82/0x3f0 fs/open.c:1086 doopen fs/namei.c:3830 [inline] pathopenat+0x1e88/0x2d80 fs/namei.c:3989 dofilpopen+0x20c/0x470 fs/namei.c:4016 dosysopenat2+0x17a/0x1e0 fs/open.c:1428 dosysopen fs/open.c:1443 [inline] dosysopenat fs/open.c:1459 [inline] sesysopenat fs/open.c:1454 [inline] x64sysopenat+0x175/0x210 fs/open.c:1454 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x250 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

-> #1 ((pmchainhead).rwsem){++++}-{4:4}: downread+0x9a/0x330 kernel/locking/rwsem.c:1524 blockingnotifiercallchainrobust kerne ---truncated---

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

PCI: imx6: Fix suspend/resume support on i.MX6QDL

The suspend/resume functionality is currently broken on the i.MX6QDL platform, as documented in the NXP errata (ERR005723):

https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf

This patch addresses the issue by sharing most of the suspend/resume sequences used by other i.MX devices, while avoiding modifications to critical registers that disrupt the PCIe functionality. It targets the same problem as the following downstream commit:

https://github.com/nxp-imx/linux-imx/commit/4e92355e1f79d225ea842511fcfd42b343b32995

Unlike the downstream commit, this patch also resets the connected PCIe device if possible. Without this reset, certain drivers, such as ath10k or iwlwifi, will crash on resume. The device reset is also done by the driver on other i.MX platforms, making this patch consistent with existing practices.

Upon resuming, the kernel will hang and display an error. Here's an example of the error encountered with the ath10k driver:

ath10kpci 0000:01:00.0: Unable to change power state from D3hot to D0, device inaccessible Unhandled fault: imprecise external abort (0x1406) at 0x0106f944

Without this patch, suspend/resume will fail on i.MX6QDL devices if a PCIe device is connected.

[kwilczynski: commit log, added tag for stable releases]

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

ksm: use range-walk function to jump over holes in scangetnextrmapitem

Currently, scangetnextrmapitem() walks every page address in a VMA to locate mergeable pages. This becomes highly inefficient when scanning large virtual memory areas that contain mostly unmapped regions, causing ksmd to use large amount of cpu without deduplicating much pages.

This patch replaces the per-address lookup with a range walk using walkpagerange(). The range walker allows KSM to skip over entire unmapped holes in a VMA, avoiding unnecessary lookups. This problem was previously discussed in [1].

Consider the following test program which creates a 32 TiB mapping in the virtual address space but only populates a single page:

#include <unistd.h> #include <stdio.h> #include <sys/mman.h>

/ 32 TiB / const sizet size = 32ul 1024 1024 1024 1024;

int main() { char area = mmap(NULL, size, PROTREAD | PROTWRITE, MAPNORESERVE | MAPPRIVATE | MAPANON, -1, 0);

if (area == MAPFAILED) { perror("mmap() failed\n"); return -1; }

/ Populate a single page such that we get an anonvma. / area = 0;

/ Enable KSM. / madvise(area, size, MADVMERGEABLE); pause(); return 0; }

$ ./ksm-sparse & $ echo 1 > /sys/kernel/mm/ksm/run

Without this patch ksmd uses 100% of the cpu for a long time (more then 1 hour in my test machine) scanning all the 32 TiB virtual address space that contain only one mapped page. This makes ksmd essentially deadlocked not able to deduplicate anything of value. With this patch ksmd walks only the one mapped page and skips the rest of the 32 TiB virtual address space, making the scan fast using little cpu.

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

nvme-fabrics: use reserved tag for reg read/write command

In some scenarios, if too many commands are issued by nvme command in the same time by user tasks, this may exhaust all tags of adminq. If a reset (nvme reset or IO timeout) occurs before these commands finish, reconnect routine may fail to update nvme regs due to insufficient tags, which will cause kernel hang forever. In order to workaround this issue, maybe we can let regread32()/regread64()/regwrite32() use reserved tags. This maybe safe for nvmf:

1. For the disable ctrl path, we will not issue connect command 2. For the enable ctrl / fw activate path, since connect and regxx() are called serially.

So the reserved tags may still be enough while regxx() use reserved tags.

dlm: prevent NPD when writing a positive value to eventdone

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

md/raid1,raid10: don't ignore IO flags

If blk-wbt is enabled by default, it's found that raid write performance is quite bad because all IO are throttled by wbt of underlying disks, due to flag REQIDLE is ignored. And turns out this behaviour exist since blk-wbt is introduced.

Other than REQIDLE, other flags should not be ignored as well, for example REQMETA can be set for filesystems, clearing it can cause priority reverse problems; And REQNOWAIT should not be cleared as well, because io will wait instead of failing directly in underlying disks.

Fix those problems by keep IO flags from master bio.

Fises: f51d46d0e7cb ("md: add support for REQNOWAIT")

bonding: check xdp prog when set bond mode

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

nfsd: don't ignore the return code of svcprocregister()

Currently, nfsdprocstatinit() ignores the return value of svcprocregister(). If the procfile creation fails, then the kernel will WARN when it tries to remove the entry later.

Fix nfsdprocstatinit() to return the same type of pointer as svcprocregister(), and fix up nfsdnetinit() to check that and fail the nfsdnet construction if it occurs.

svcprocregister() can fail if the dentry can't be allocated, or if an identical dentry already exists. The second case is pretty unlikely in the nfsdnet construction codepath, so if this happens, return -ENOMEM.

drm/radeon: delete radeonfenceprocess in issignaled, no deadlock

dm-raid: really frozen syncthread during suspend

A flaw named "EntryBleed" was found in the Linux Kernel Page Table Isolation (KPTI). This issue could allow a local attacker to leak KASLR base via prefetch side-channels based on TLB timing for Intel systems.

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

timers: Fix NULL function pointer race in timershutdownsync()

There is a race condition between timershutdownsync() and timer expiration that can lead to hitting a WARNON in expiretimers().

The issue occurs when timershutdownsync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this:

CPU0 CPU1 <SOFTIRQ> locktimerbase() expiretimers() base->runningtimer = timer; unlocktimerbase() [calltimerfn enter] modtimer() ... timershutdownsync() locktimerbase() // For now, will not detach the timer but only clear its function to NULL if (base->runningtimer != timer) ret = detachifpending(timer, base, true); if (shutdown) timer->function = NULL; unlocktimerbase() [calltimerfn exit] locktimerbase() base->runningtimer = NULL; unlocktimerbase() ... // Now timer is pending while its function set to NULL. // next timer trigger <SOFTIRQ> expiretimers() WARNONONCE(!fn) // hit ... locktimerbase() // Now timer will detach if (base->runningtimer != timer) ret = detachifpending(timer, base, true); if (shutdown) timer->function = NULL; unlocktimerbase()

The problem is that timershutdownsync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARNONONCE(!fn) check in expiretimers().

Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.

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

mm: clear uffd-wp PTE/PMD state on mremap()

When mremap()ing a memory region previously registered with userfaultfd as write-protected but without UFFDFEATUREEVENTREMAP, an inconsistency in flag clearing leads to a mismatch between the vma flags (which have uffd-wp cleared) and the pte/pmd flags (which do not have uffd-wp cleared). This mismatch causes a subsequent mprotect(PROTWRITE) to trigger a warning in pagetablecheckpteflags() due to setting the pte to writable while uffd-wp is still set.

Fix this by always explicitly clearing the uffd-wp pte/pmd flags on any such mremap() so that the values are consistent with the existing clearing of VMUFFDWP. Be careful to clear the logical flag regardless of its physical form; a PTE bit, a swap PTE bit, or a PTE marker. Cover PTE, huge PMD and hugetlb paths.

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

RDMA/mlx5: Fix a race for an ODP MR which leads to CQE with error

This patch addresses a race condition for an ODP MR that can result in a CQE with an error on the UMR QP.

During the mlx5ibderegmr() flow, the following sequence of calls occurs:

mlx5revokemr() mlx5rumrrevokemr() mlx5rumrpostsendwait()

At this point, the lkey is freed from the hardware's perspective.

However, concurrently, mlx5ibinvalidaterange() might be triggered by another task attempting to invalidate a range for the same freed lkey.

This task will: - Acquire the umemodp->umemmutex lock. - Call mlx5rumrupdatexlt() on the UMR QP. - Since the lkey has already been freed, this can lead to a CQE error, causing the UMR QP to enter an error state [1].

To resolve this race condition, the umemodp->umemmutex lock is now also acquired as part of the mlx5revokemr() scope. Upon successful revoke, we set umemodp->private which points to that MR to NULL, preventing any further invalidation attempts on its lkey.

[1] From dmesg:

infiniband rocep8s0f0: dumpcqe:277:(pid 0): WC error: 6, Message: memory bind operation error cqedump: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqedump: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqedump: 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqedump: 00000030: 00 00 00 00 08 00 78 06 25 00 11 b9 00 0e dd d2

WARNING: CPU: 15 PID: 1506 at drivers/infiniband/hw/mlx5/umr.c:394 mlx5rumrpostsendwait+0x15a/0x2b0 [mlx5ib] Modules linked in: ip6tablemangle ip6tablenatip6tablefilter ip6tables iptablemangle xtconntrack xtMASQUERADE nfconntracknetlink nfnetlink xtaddrtype iptablenat nfnat brnetfilter rpcsecgsskrb5 authrpcgss oidregistry overlay rpcrdma rdmaucm ibiser libiscsi scsitransportiscsi rdmacm iwcm ibumad ibipoib ibcm mlx5ib ibuverbs ibcore fuse mlx5core CPU: 15 UID: 0 PID: 1506 Comm: ibvrcpingpong Not tainted 6.12.0-rc7+ #1626 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5rumrpostsendwait+0x15a/0x2b0 [mlx5ib] [..] Call Trace: <TASK> mlx5rumrupdatexlt+0x23c/0x3e0 [mlx5ib] mlx5ibinvalidaterange+0x2e1/0x330 [mlx5ib] mmunotifierinvalidaterangestart+0x1e1/0x240 zappagerangesingle+0xf1/0x1a0 madvisevmabehavior+0x677/0x6e0 domadvise+0x1a2/0x4b0 x64sysmadvise+0x25/0x30 dosyscall64+0x6b/0x140 entrySYSCALL64afterhwframe+0x76/0x7e

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

nbd: defer config unlock in nbdgenlconnect

There is one use-after-free warning when running NBDCMDCONNECT and NBDCLEARSOCK:

nbdgenlconnect nbdallocandinitconfig // configrefs=1 nbdstartdevice // configrefs=2 set NBDRTHASCONFIGREF open nbd // configrefs=3 recvwork done // configrefs=2 NBDCLEARSOCK // configrefs=1 close nbd // configrefs=0 refcountinc -> uaf

------------[ cut here ]------------ refcountt: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcountwarnsaturate+0x12e/0x290 nbdgenlconnect+0x16d0/0x1ab0 genlfamilyrcvmsgdoit+0x1f3/0x310 genlrcvmsg+0x44a/0x790

The issue can be easily reproduced by adding a small delay before refcountinc(&nbd->configrefs) in nbdgenlconnect():

mutexunlock(&nbd->configlock); if (!ret) { setbit(NBDRTHASCONFIGREF, &config->runtimeflags); + printk("before sleep\n"); + mdelay(5 1000); + printk("after sleep\n"); refcountinc(&nbd->configrefs); nbdconnectreply(info, nbd->index); }

drm, fbcon, vgaswitcheroo: Avoid race condition in fbcon setup

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

usbnet: Fix using smpprocessorid() in preemptible code warnings

Syzbot reported the following warning:

BUG: using smpprocessorid() in preemptible [00000000] code: dhcpcd/2879 caller is usbnetskbreturn+0x74/0x490 drivers/net/usb/usbnet.c:331 CPU: 1 UID: 0 PID: 2879 Comm: dhcpcd Not tainted 6.15.0-rc4-syzkaller-00098-g615dca38c2ea #0 PREEMPT(voluntary) Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x16c/0x1f0 lib/dumpstack.c:120 checkpreemptiondisabled+0xd0/0xe0 lib/smpprocessorid.c:49 usbnetskbreturn+0x74/0x490 drivers/net/usb/usbnet.c:331 usbnetresumerx+0x4b/0x170 drivers/net/usb/usbnet.c:708 usbnetchangemtu+0x1be/0x220 drivers/net/usb/usbnet.c:417 devsetmtu net/core/dev.c:9443 [inline] netifsetmtuext+0x369/0x5c0 net/core/dev.c:9496 netifsetmtu+0xb0/0x160 net/core/dev.c:9520 devsetmtu+0xae/0x170 net/core/devapi.c:247 devifsioc+0xa31/0x18d0 net/core/devioctl.c:572 devioctl+0x223/0x10e0 net/core/devioctl.c:821 sockdoioctl+0x19d/0x280 net/socket.c:1204 sockioctl+0x42f/0x6a0 net/socket.c:1311 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:906 [inline] sesysioctl fs/ioctl.c:892 [inline] x64sysioctl+0x190/0x200 fs/ioctl.c:892 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xcd/0x260 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

For historical and portability reasons, the netifrx() is usually run in the softirq or interrupt context, this commit therefore add localbhdisable/enable() protection in the usbnetresumerx().

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

scsi: sg: Do not sleep in atomic context

sgfinishremreq() calls blkrqunmapuser(). The latter function may sleep. Hence, call sgfinishremreq() with interrupts enabled instead of disabled.