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

net: add proper RCU protection to /proc/net/ptype

Yin Fengwei reported an RCU stall in ptypeseqshow() and provided a patch.

Real issue is that ptypeseqnext() and ptypeseqshow() violate RCU rules.

ptypeseqshow() runs under rcureadlock(), and reads pt->dev to get device name without any barrier.

At the same time, concurrent writers can remove a packettype structure (which is correctly freed after an RCU grace period) and clear pt->dev without an RCU grace period.

Define ptypeiterstate to carry a dev pointer along seqnetprivate:

struct ptypeiterstate { struct seqnetprivate p; struct netdevice dev; // added in this patch };

We need to record the device pointer in ptypegetidx() and ptypeseqnext() so that ptypeseqshow() is safe against concurrent pt->dev changes.

We also need to add full RCU protection in ptypeseqnext(). (Missing READONCE() when reading list.next values)

Many thanks to Dong Chenchen for providing a repro.

btrfs: send: check for inline extents in rangeisholeinparent()

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

scsi: core: Wake up the error handler when final completions race against each other

The fragile ordering between marking commands completed or failed so that the error handler only wakes when the last running command completes or times out has race conditions. These race conditions can cause the SCSI layer to fail to wake the error handler, leaving I/O through the SCSI host stuck as the error state cannot advance.

First, there is an memory ordering issue within scsidechostbusy(). The write which clears SCMDSTATEINFLIGHT may be reordered with reads counting in scsihostbusy(). While the local CPU will see its own write, reordering can allow other CPUs in scsidechostbusy() or scsiehinchostfailed() to see a raised busy count, causing no CPU to see a host busy equal to the hostfailed count.

This race condition can be prevented with a memory barrier on the error path to force the write to be visible before counting host busy commands.

Second, there is a general ordering issue with scsiehinchostfailed(). By counting busy commands before incrementing hostfailed, it can race with a final command in scsidechostbusy(), such that scsidechostbusy() does not see hostfailed incremented but scsiehinchostfailed() counts busy commands before SCMDSTATEINFLIGHT is cleared by scsidechostbusy(), resulting in neither waking the error handler task.

This needs the call to scsihostbusy() to be moved after hostfailed is incremented to close the race condition.

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

scsi: xen: scsiback: Fix potential memory leak in scsibackremove()

Memory allocated for struct vscsiblkinfo in scsibackprobe() is not freed in scsibackremove() leading to potential memory leaks on remove, as well as in the scsibackprobe() error paths. Fix that by freeing it in scsibackremove().

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

dmaengine: athdmac: fix device leak on ofdmaxlate()

Make sure to drop the reference taken when looking up the DMA platform device during ofdmaxlate() when releasing channel resources.

Note that commit 3832b78b3ec2 ("dmaengine: athdmac: add missing putdevice() call in atdmaxlate()") fixed the leak in a couple of error paths but the reference is still leaking on successful allocation.

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

dmaengine: stm32: dmamux: fix device leak on route allocation

Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation.

Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.

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

mptcp: fallback earlier on simult connection

Syzkaller reports a simult-connect race leading to inconsistent fallback status:

WARNING: CPU: 3 PID: 33 at net/mptcp/subflow.c:1515 subflowdataready+0x40b/0x7c0 net/mptcp/subflow.c:1515 Modules linked in: CPU: 3 UID: 0 PID: 33 Comm: ksoftirqd/3 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:subflowdataready+0x40b/0x7c0 net/mptcp/subflow.c:1515 Code: 89 ee e8 78 61 3c f6 40 84 ed 75 21 e8 8e 66 3c f6 44 89 fe bf 07 00 00 00 e8 c1 61 3c f6 41 83 ff 07 74 09 e8 76 66 3c f6 90 <0f> 0b 90 e8 6d 66 3c f6 48 89 df e8 e5 ad ff ff 31 ff 89 c5 89 c6 RSP: 0018:ffffc900006cf338 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888031acd100 RCX: ffffffff8b7f2abf RDX: ffff88801e6ea440 RSI: ffffffff8b7f2aca RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000007 R10: 0000000000000004 R11: 0000000000002c10 R12: ffff88802ba69900 R13: 1ffff920000d9e67 R14: ffff888046f81800 R15: 0000000000000004 FS: 0000000000000000(0000) GS:ffff8880d69bc000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000560fc0ca1670 CR3: 0000000032c3a000 CR4: 0000000000352ef0 Call Trace: <TASK> tcpdataqueue+0x13b0/0x4f90 net/ipv4/tcpinput.c:5197 tcprcvstateprocess+0xfdf/0x4ec0 net/ipv4/tcpinput.c:6922 tcpv6dorcv+0x492/0x1740 net/ipv6/tcpipv6.c:1672 tcpv6rcv+0x2976/0x41e0 net/ipv6/tcpipv6.c:1918 ip6protocoldeliverrcu+0x188/0x1520 net/ipv6/ip6input.c:438 ip6inputfinish+0x1e4/0x4b0 net/ipv6/ip6input.c:489 NFHOOK include/linux/netfilter.h:318 [inline] NFHOOK include/linux/netfilter.h:312 [inline] ip6input+0x105/0x2f0 net/ipv6/ip6input.c:500 dstinput include/net/dst.h:471 [inline] ip6rcvfinish net/ipv6/ip6input.c:79 [inline] NFHOOK include/linux/netfilter.h:318 [inline] NFHOOK include/linux/netfilter.h:312 [inline] ipv6rcv+0x264/0x650 net/ipv6/ip6input.c:311 netifreceiveskbonecore+0x12d/0x1e0 net/core/dev.c:5979 netifreceiveskb+0x1d/0x160 net/core/dev.c:6092 processbacklog+0x442/0x15e0 net/core/dev.c:6444 napipoll.constprop.0+0xba/0x550 net/core/dev.c:7494 napipoll net/core/dev.c:7557 [inline] netrxaction+0xa9f/0xfe0 net/core/dev.c:7684 handlesoftirqs+0x216/0x8e0 kernel/softirq.c:579 runksoftirqd kernel/softirq.c:968 [inline] runksoftirqd+0x3a/0x60 kernel/softirq.c:960 smpbootthreadfn+0x3f7/0xae0 kernel/smpboot.c:160 kthread+0x3c2/0x780 kernel/kthread.c:463 retfromfork+0x5d7/0x6f0 arch/x86/kernel/process.c:148 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:245 </TASK>

The TCP subflow can process the simult-connect syn-ack packet after transitioning to TCPFIN1 state, bypassing the MPTCP fallback check, as the skstatechange() callback is not invoked for -> FINWAIT1 transitions.

That will move the msk socket to an inconsistent status and the next incoming data will hit the reported splat.

Close the race moving the simult-fallback check at the earliest possible stage - that is at syn-ack generation time.

About the fixes tags: [2] was supposed to also fix this issue introduced by [3]. [1] is required as a dependence: it was not explicitly marked as a fix, but it is one and it has already been backported before [3]. In other words, this commit should be backported up to [3], including [2] and [1] if that's not already there.

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

net: nfc: fix deadlock between nfcunregisterdevice and rfkillfopwrite

A deadlock can occur between nfcunregisterdevice() and rfkillfopwrite() due to lock ordering inversion between devicelock and rfkillglobalmutex.

The problematic lock order is:

Thread A (rfkillfopwrite): rfkillfopwrite() mutexlock(&rfkillglobalmutex) rfkillsetblock() nfcrfkillsetblock() nfcdevdown() devicelock(&dev->dev) <- waits for devicelock

Thread B (nfcunregisterdevice): nfcunregisterdevice() devicelock(&dev->dev) rfkillunregister() mutexlock(&rfkillglobalmutex) <- waits for rfkillglobalmutex

This creates a classic ABBA deadlock scenario.

Fix this by moving rfkillunregister() and rfkilldestroy() outside the devicelock critical section. Store the rfkill pointer in a local variable before releasing the lock, then call rfkillunregister() after releasing devicelock.

This change is safe because rfkillfopwrite() holds rfkillglobalmutex while calling the rfkill callbacks, and rfkillunregister() also acquires rfkillglobalmutex before cleanup. Therefore, rfkillunregister() will wait for any ongoing callback to complete before proceeding, and devicedel() is only called after rfkillunregister() returns, preventing any use-after-free.

The similar lock ordering in nfcregisterdevice() (devicelock -> rfkillglobalmutex via rfkillregister) is safe because during registration the device is not yet in rfkilllist, so no concurrent rfkill operations can occur on this device.

fsnotify: do not generate ACCESS/MODIFY events on child for special files

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

spi: fsl-cpm: Check length parity before switching to 16 bit mode

Commit fc96ec826bce ("spi: fsl-cpm: Use 16 bit mode for large transfers with even size") failed to make sure that the size is really even before switching to 16 bit mode. Until recently the problem went unnoticed because kernfs uses a pre-allocated bounce buffer of size PAGESIZE for reading EEPROM.

But commit 8ad6249c51d0 ("eeprom: at25: convert to spi-mem API") introduced an additional dynamically allocated bounce buffer whose size is exactly the size of the transfer, leading to a buffer overrun in the fsl-cpm driver when that size is odd.

Add the missing length parity verification and remain in 8 bit mode when the length is not even.

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.

Bluetooth: bcsp: receive data only if registered

amd/amdkfd: resolve a race in amdgpuamdkfddevicefinisw

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

drm/amdkfd: Fix mmap write lock not release

If mmap write lock is taken while draining retry fault, mmap write lock is not released because svmrangerestorepages calls mmapreadunlock then returns. This causes deadlock and system hangs later because mmap read or write lock cannot be taken.

Downgrade mmap write lock to read lock if draining retry fault fix this bug.

drm/amdgpu: fix nullptr err of vmhandlemoved

backlight: led-bl: Add devlink to supplier LEDs

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

clk: thead: th1520-ap: set all AXI clocks to CLKISCRITICAL

The AXI crossbar of TH1520 has no proper timeout handling, which means gating AXI clocks can easily lead to bus timeout and thus system hang.

Set all AXI clock gates to CLKISCRITICAL. All these clock gates are ungated by default on system reset.

In addition, convert all current CLKIGNOREUNUSED usage to CLKISCRITICAL to prevent unwanted clock gating.

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

pinctrl: s32cc: fix uninitialized memory in s32pinctrldesc

s32pinctrldesc is allocated with devmkmalloc(), but not all of its fields are initialized. Notably, numcustomparams is used in pinconfgenericparsedtconfig(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx:

WARNING: CPU: 0 PID: 176 at mm/pagealloc.c:4795 allocpagesnoprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: allocpagesnoprof+0x290/0x300 (P) kmalloclargenode+0x84/0x168 kmalloclargenodenoprof+0x34/0x120 kmallocnoprof+0x2ac/0x378 pinconfgenericparsedtconfig+0x68/0x1a0 s32dtnodetomap+0x104/0x248 dttomaponeconfig+0x154/0x1d8 pinctrldttomap+0x12c/0x280 createpinctrl+0x6c/0x270 pinctrlget+0xc0/0x170 devmpinctrlget+0x50/0xa0 pinctrlbindpins+0x60/0x2a0 reallyprobe+0x60/0x3a0 [...] platformdriverregister+0x2c/0x40 i2cadapimxinit+0x28/0xff8 [i2cimx] [...]

This results in later parse failures that can cause issues in dependent drivers:

s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered

Fix this by initializing s32pinctrldesc with devmkzalloc() instead of devmkmalloc() in s32pinctrlprobe(), which sets the previously uninitialized fields to zero.

crash: fix crashkernel resource shrink

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:

scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3)

According to UFS specifications, the power-off sequence for a UFS device includes:

- Sending an SSU command with PowerCondition=3 and await a response.

- Asserting RSTN low.

- Turning off REFCLK.

- Turning off VCC.

- Turning off VCCQ/VCCQ2.

As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current.

This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator.

To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode.

Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.

drm/tegra: Add call to putpid()

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

comedi: multiq3: sanitize config options in multiq3attach()

Syzbot identified an issue [1] in multiq3attach() that induces a task timeout due to open() or COMEDIDEVCONFIG ioctl operations, specifically, in the case of multiq3 driver.

This problem arose when syzkaller managed to craft weird configuration options used to specify the number of channels in encoder subdevice. If a particularly great number is passed to s->nchan in multiq3attach() via it->options[2], then multiple calls to multiq3encoderreset() at the end of driver-specific attach() method will be running for minutes, thus blocking tasks and affected devices as well.

While this issue is most likely not too dangerous for real-life devices, it still makes sense to sanitize configuration inputs. Enable a sensible limit on the number of encoder chips (4 chips max, each with 2 channels) to stop this behaviour from manifesting.

[1] Syzbot crash: INFO: task syz.2.19:6067 blocked for more than 143 seconds. ... Call Trace: <TASK> contextswitch kernel/sched/core.c:5254 [inline] schedule+0x17c4/0x4d60 kernel/sched/core.c:6862 scheduleloop kernel/sched/core.c:6944 [inline] schedule+0x165/0x360 kernel/sched/core.c:6959 schedulepreemptdisabled+0x13/0x30 kernel/sched/core.c:7016 mutexlockcommon kernel/locking/mutex.c:676 [inline] mutexlock+0x7e6/0x1350 kernel/locking/mutex.c:760 comediopen+0xc0/0x590 drivers/comedi/comedifops.c:2868 chrdevopen+0x4cc/0x5e0 fs/chardev.c:414 dodentryopen+0x953/0x13f0 fs/open.c:965 vfsopen+0x3b/0x340 fs/open.c:1097 ...

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

ASoC: SDCA: bug fix while parsing mipi-sdca-control-cn-list

"struct sdcacontrol" declares "values" field as integer array. But the memory allocated to it is of char array. This causes crash for sdcaparsefunction API. This patch addresses the issue by allocating correct data size.

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

usb: gadget: udc: fix use-after-free in usbgadgetstatework

A race condition during gadget teardown can lead to a use-after-free in usbgadgetstatework(), as reported by KASAN:

BUG: KASAN: invalid-access in sysfsnotify+0x2c/0xd0 Workqueue: events usbgadgetstatework

The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usbgadgetsetstate() and schedule gadget->work at any time during the cleanup process in usbdelgadget().

Commit 399a45e5237c ("usb: gadget: core: flush gadget workqueue after device removal") attempted to fix this by moving flushwork() to after devicedel(). However, this does not fully solve the race, as a new work item can still be scheduled after flushwork() completes but before the gadget's memory is freed, leading to the same use-after-free.

This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'statelock' spinlock to the usbgadget struct. The flag is set during cleanup in usbdelgadget() before calling flushwork() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usbgadgetsetstate(), now checks this flag under the lock before queueing the work, thus safely closing the race window.

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

usb: gadget: feem: Fix memory leak in eemunwrap

The existing code did not handle the failure case of usbepqueue in the command path, potentially leading to memory leaks.

Improve error handling to free all allocated resources on usbepqueue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers.

kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slabpostallochook+0xbc/0x3a4 kmemcachealloc+0x1b4/0x358 skbclone+0x90/0xd8 eemunwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slabpostallochook+0xbc/0x3a4 kmemcacheallocnode+0x1b4/0x2dc kmalloctrace+0x48/0x140 dwc3gadgetepallocrequest+0x58/0x11c usbepallocrequest+0x40/0xe4 eemunwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slabpostallochook+0xbc/0x3a4 kmemcacheallocnode+0x1b4/0x2dc kmalloc+0x64/0x1a8 eemunwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slabpostallochook+0xbc/0x3a4 kmemcacheallocnode+0x1b4/0x2dc kmalloctrace+0x48/0x140 eemunwrap+0x238/0x36c

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

parisc: Avoid crash due to unaligned access in unwinder

Guenter Roeck reported this kernel crash on his emulated B160L machine:

Starting network: udhcpc: started, v1.36.1 Backtrace: [<104320d4>] unwindonce+0x1c/0x5c [<10434a00>] walkstackframe.isra.0+0x74/0xb8 [<10434a6c>] archstackwalk+0x28/0x38 [<104e5efc>] stacktracesave+0x48/0x5c [<105d1bdc>] settrackprepare+0x44/0x6c [<105d9c80>] slaballoc+0xfc4/0x1024 [<105d9d38>] slaballoc.isra.0+0x58/0x90 [<105dc80c>] kmemcacheallocnoprof+0x2ac/0x4a0 [<105b8e54>] anonvmaprepare+0x60/0x280 [<105a823c>] vmfanonprepare+0x68/0x94 [<105a8b34>] dowppage+0x8cc/0xf10 [<105aad88>] handlemmfault+0x6c0/0xf08 [<10425568>] dopagefault+0x110/0x440 [<10427938>] handleinterruption+0x184/0x748 [<11178398>] schedule+0x4c/0x190 BUG: spinlock recursion on CPU#0, ifconfig/2420 lock: terminatelock.2+0x0/0x1c, .magic: dead4ead, .owner: ifconfig/2420, .ownercpu: 0

While creating the stack trace, the unwinder uses the stack pointer to guess the previous frame to read the previous stack pointer from memory. The crash happens, because the unwinder tries to read from unaligned memory and as such triggers the unalignment trap handler which then leads to the spinlock recursion and finally to a deadlock.

Fix it by checking the alignment before accessing the memory.

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

ocfs2: relax BUG() to ocfs2error() in ocfs2moveextent()

In 'ocfs2moveextent()', relax 'BUG()' to 'ocfs2error()' just to avoid crashing the whole kernel due to a filesystem corruption.

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

regulator: core: Protect regulatorsupplyaliaslist with regulatorlistmutex

regulatorsupplyaliaslist was accessed without any locking in regulatorsupplyalias(), regulatorregistersupplyalias(), and regulatorunregistersupplyalias(). Concurrent registration, unregistration and lookups can race, leading to:

1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers.

Protect all traversals, insertions and deletions on regulatorsupplyaliaslist with the existing regulatorlistmutex.

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

ntfs3: fix uninit memory after failed miread in miformatnew

Fix a KMSAN un-init bug found by syzkaller.

ntfsgetbh() expects a buffer from sbgetblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN.

Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.