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:

OPP: add index check to assert to avoid buffer overflow in readfreq()

Pass the freq index to the assert function to make sure we do not read a freq out of the opp->rates[] table when called from the indexed variants: devpmoppfindfreqexactindexed() or devpmoppfindfreqceil/floorindexed().

Add a secondary parameter to the assert function, unused for assertsingleclk() then add assertclkindex() which will check for the clock index when called from the indexed() find functions.

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

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

ntbhwswitchtec: Fix shift-out-of-bounds in switchtecntbmwsettrans

There is a kernel API ntbmwcleartrans() would pass 0 to both addr and size. This would make xlatepos negative.

[ 23.734156] switchtec switchtec0: MW 0: part 0 addr 0x0000000000000000 size 0x0000000000000000 [ 23.734158] ================================================================================ [ 23.734172] UBSAN: shift-out-of-bounds in drivers/ntb/hw/mscc/ntbhwswitchtec.c:293:7 [ 23.734418] shift exponent -1 is negative

Ensuring xlatepos is a positive or zero before BIT.

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

net/sched: mqprio: fix stack out-of-bounds write in tc entry parsing

TCAMQPRIOTCENTRYINDEX is validated using NLAPOLICYMAX(NLAU32, TCQOPTMAXQUEUE), which allows the value TCQOPTMAXQUEUE (16). This leads to a 4-byte out-of-bounds stack write in the fp[] array, which only has room for 16 elements (0–15).

Fix this by changing the policy to allow only up to TCQOPTMAXQUEUE - 1.

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

net/mlx5e: Check for NOTREADY flag state after locking

Currently the check for NOTREADY flag is performed before obtaining the necessary lock. This opens a possibility for race condition when the flow is concurrently removed from unreadyflows list by the workqueue task, which causes a double-removal from the list and a crash[0]. Fix the issue by moving the flag check inside the section protected by uplinkpriv->unreadyflowslock mutex.

[0]: [44376.389654] general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP [44376.391665] CPU: 7 PID: 59123 Comm: tc Not tainted 6.4.0-rc4+ #1 [44376.392984] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [44376.395342] RIP: 0010:mlx5etcdelfdbflow+0xb3/0x340 [mlx5core] [44376.396857] Code: 00 48 8b b8 68 ce 02 00 e8 8a 4d 02 00 4c 8d a8 a8 01 00 00 4c 89 ef e8 8b 79 88 e1 48 8b 83 98 06 00 00 48 8b 93 90 06 00 00 <48> 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 83 90 06 [44376.399167] RSP: 0018:ffff88812cc97570 EFLAGS: 00010246 [44376.399680] RAX: dead000000000122 RBX: ffff8881088e3800 RCX: ffff8881881bac00 [44376.400337] RDX: dead000000000100 RSI: ffff88812cc97500 RDI: ffff8881242f71b0 [44376.401001] RBP: ffff88811cbb0940 R08: 0000000000000400 R09: 0000000000000001 [44376.401663] R10: 0000000000000001 R11: 0000000000000000 R12: ffff88812c944000 [44376.402342] R13: ffff8881242f71a8 R14: ffff8881222b4000 R15: 0000000000000000 [44376.402999] FS: 00007f0451104800(0000) GS:ffff88852cb80000(0000) knlGS:0000000000000000 [44376.403787] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [44376.404343] CR2: 0000000000489108 CR3: 0000000123a79003 CR4: 0000000000370ea0 [44376.405004] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [44376.405665] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [44376.406339] Call Trace: [44376.406651] <TASK> [44376.406939] ? dieaddr+0x33/0x90 [44376.407311] ? excgeneralprotection+0x192/0x390 [44376.407795] ? asmexcgeneralprotection+0x22/0x30 [44376.408292] ? mlx5etcdelfdbflow+0xb3/0x340 [mlx5core] [44376.408876] mlx5etcdelfdbpeerflow+0xbc/0xe0 [mlx5core] [44376.409482] mlx5etcdelflow+0x42/0x210 [mlx5core] [44376.410055] mlx5eflowput+0x25/0x50 [mlx5core] [44376.410529] mlx5edeleteflower+0x24b/0x350 [mlx5core] [44376.411043] tcsetupcbreoffload+0x22/0x80 [44376.411462] flreoffload+0x261/0x2f0 [clsflower] [44376.411907] ? mlx5erepindrsetupftcb+0x160/0x160 [mlx5core] [44376.412481] ? mlx5erepindrsetupftcb+0x160/0x160 [mlx5core] [44376.413044] tcfblockplaybackoffloads+0x76/0x170 [44376.413497] tcfblockunbind+0x7b/0xd0 [44376.413881] tcfblocksetup+0x17d/0x1c0 [44376.414269] tcfblockoffloadcmd.isra.0+0xf1/0x130 [44376.414725] tcfblockoffloadunbind+0x43/0x70 [44376.415153] tcfblockput+0x82/0x150 [44376.415532] ingressdestroy+0x22/0x30 [schingress] [44376.415986] qdiscdestroy+0x3b/0xd0 [44376.416343] qdiscgraft+0x4d0/0x620 [44376.416706] tcgetqdisc+0x1c9/0x3b0 [44376.417074] rtnetlinkrcvmsg+0x29c/0x390 [44376.419978] ? repmovsalternative+0x3a/0xa0 [44376.420399] ? rtnlcalcit.isra.0+0x120/0x120 [44376.420813] netlinkrcvskb+0x54/0x100 [44376.421192] netlinkunicast+0x1f6/0x2c0 [44376.421573] netlinksendmsg+0x232/0x4a0 [44376.421980] socksendmsg+0x38/0x60 [44376.422328] syssendmsg+0x1d0/0x1e0 [44376.422709] ? copymsghdrfromuser+0x6d/0xa0 [44376.423127] syssendmsg+0x80/0xc0 [44376.423495] ? sysrecvmsg+0x8b/0xc0 [44376.423869] syssendmsg+0x51/0x90 [44376.424226] dosyscall64+0x3d/0x90 [44376.424587] entrySYSCALL64afterhwframe+0x46/0xb0 [44376.425046] RIP: 0033:0x7f045134f887 [44376.425403] Code: 0a 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 ---truncated---

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

ASoC: Intel: bytcrrt5640: Fix invalid quirk input mapping

When an invalid value is passed via quirk option, currently bytcrrt5640 driver only shows an error message but leaves as is. This may lead to unepxected results like OOB access.

This patch corrects the input mapping to the certain default value if an invalid value is passed.

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

drm/vmwgfx: Validate command header size against SVGACMDMAXDATASIZE

This data originates from userspace and is used in buffer offset calculations which could potentially overflow causing an out-of-bounds access.

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

RDMA/rxe: Fix incomplete state save in rxerequester

If a send packet is dropped by the IP layer in rxerequester() the call to rxexmitpacket() can fail with err == -EAGAIN. To recover, the state of the wqe is restored to the state before the packet was sent so it can be resent. However, the routines that save and restore the state miss a significnt part of the variable state in the wqe, the dma struct which is used to process through the sge table. And, the state is not saved before the packet is built which modifies the dma struct.

Under heavy stress testing with many QPs on a fast node sending large messages to a slow node dropped packets are observed and the resent packets are corrupted because the dma struct was not restored. This patch fixes this behavior and allows the test cases to succeed.

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

net: use dstdevrcu() in sksetupcaps()

Use RCU to protect accesses to dst->dev from sksetupcaps() and skdstgsomaxsize().

Also use dstdevrcu() in ip6dstmtumaybeforward(), and ipdstmtumaybeforward().

ip4dsthoplimit() can use dstdevnetrcu().

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

Bluetooth: hcisync: Fix UAF in hcidisconnectallsync

Use-after-free can occur in hcidisconnectallsync if a connection is deleted by concurrent processing of a controller event.

To prevent this the code now tries to iterate over the list backwards to ensure the links are cleanup before its parents, also it no longer relies on a cursor, instead it always uses the last element since hciabortconnsync is guaranteed to call hciconndel.

UAF crash log: ================================================================== BUG: KASAN: slab-use-after-free in hcisetpoweredsync (net/bluetooth/hcisync.c:5424) [bluetooth] Read of size 8 at addr ffff888009d9c000 by task kworker/u9:0/124

CPU: 0 PID: 124 Comm: kworker/u9:0 Tainted: G W 6.5.0-rc1+ #10 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014 Workqueue: hci0 hcicmdsyncwork [bluetooth] Call Trace: <TASK> dumpstacklvl+0x5b/0x90 printreport+0xcf/0x670 ? virtaddrvalid+0xdd/0x160 ? hcisetpoweredsync+0x2c9/0x4a0 [bluetooth] kasanreport+0xa6/0xe0 ? hcisetpoweredsync+0x2c9/0x4a0 [bluetooth] ? pfxsetpoweredsync+0x10/0x10 [bluetooth] hcisetpoweredsync+0x2c9/0x4a0 [bluetooth] ? pfxhcisetpoweredsync+0x10/0x10 [bluetooth] ? pfxlockrelease+0x10/0x10 ? pfxsetpoweredsync+0x10/0x10 [bluetooth] hcicmdsyncwork+0x137/0x220 [bluetooth] processonework+0x526/0x9d0 ? pfxprocessonework+0x10/0x10 ? pfxdorawspinlock+0x10/0x10 ? markheldlocks+0x1a/0x90 workerthread+0x92/0x630 ? pfxworkerthread+0x10/0x10 kthread+0x196/0x1e0 ? pfxkthread+0x10/0x10 retfromfork+0x2c/0x50 </TASK>

Allocated by task 1782: kasansavestack+0x33/0x60 kasansettrack+0x25/0x30 kasankmalloc+0x8f/0xa0 hciconnadd+0xa5/0xa80 [bluetooth] hcibindcis+0x881/0x9b0 [bluetooth] isoconnectcis+0x121/0x520 [bluetooth] isosockconnect+0x3f6/0x790 [bluetooth] sysconnect+0x109/0x130 x64sysconnect+0x40/0x50 dosyscall64+0x60/0x90 entrySYSCALL64afterhwframe+0x6e/0xd8

Freed by task 695: kasansavestack+0x33/0x60 kasansettrack+0x25/0x30 kasansavefreeinfo+0x2b/0x50 kasanslabfree+0x10a/0x180 kmemcachefree+0x14d/0x2e0 devicerelease+0x5d/0xf0 kobjectput+0xdf/0x270 hcidisconncompleteevt+0x274/0x3a0 [bluetooth] hcieventpacket+0x579/0x7e0 [bluetooth] hcirxwork+0x287/0xaa0 [bluetooth] processonework+0x526/0x9d0 workerthread+0x92/0x630 kthread+0x196/0x1e0 retfromfork+0x2c/0x50 ==================================================================

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

KVM: arm64: Tear down vGIC on failed vCPU creation

If kvmarchvcpucreate() fails to share the vCPU page with the hypervisor, we propagate the error back to the ioctl but leave the vGIC vCPU data initialised. Note only does this leak the corresponding memory when the vCPU is destroyed but it can also lead to use-after-free if the redistributor device handling tries to walk into the vCPU.

Add the missing cleanup to kvmarchvcpucreate(), ensuring that the vGIC vCPU structures are destroyed on error.

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

fbdev: Add bounds checking in bitputcs to fix vmalloc-out-of-bounds

Add bounds checking to prevent writes past framebuffer boundaries when rendering text near screen edges. Return early if the Y position is off-screen and clip image height to screen boundary. Break from the rendering loop if the X position is off-screen. When clipping image width to fit the screen, update the character count to match the clipped width to prevent buffer size mismatches.

Without the character count update, bitputcsaligned and bitputcsunaligned receive mismatched parameters where the buffer is allocated for the clipped width but cnt reflects the original larger count, causing out-of-bounds writes.

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

net: phylink: add lock for serializing concurrent pl->phydev writes with resolver

Currently phylinkresolve() protects itself against concurrent phylinkbringupphy() or phylinkdisconnectphy() calls which modify pl->phydev by relying on pl->statemutex.

The problem is that in phylinkresolve(), pl->statemutex is in a lock inversion state with pl->phydev->lock. So pl->phydev->lock needs to be acquired prior to pl->statemutex. But that requires dereferencing pl->phydev in the first place, and without pl->statemutex, that is racy.

Hence the reason for the extra lock. Currently it is redundant, but it will serve a functional purpose once mutexlock(&phy->lock) will be moved outside of the mutexlock(&pl->statemutex) section.

Another alternative considered would have been to let phylinkresolve() acquire the rtnlmutex, which is also held when phylinkbringupphy() and phylinkdisconnectphy() are called. But since phylinkdisconnectphy() runs under rtnllock(), it would deadlock with phylinkresolve() when calling flushwork(&pl->resolve). Additionally, it would have been undesirable because it would have unnecessarily blocked many other call paths as well in the entire kernel, so the smaller-scoped lock was preferred.

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

sctp: avoid NULL dereference when chunk data buffer is missing

chunk->skb pointer is dereferenced in the if-block where it's supposed to be NULL only.

chunk->skb can only be NULL if chunk->headskb is not. Check for fraglist instead and do it just before replacing chunk->skb. We're sure that otherwise chunk->skb is non-NULL because of outer if() condition.

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

cifs: fix oops during encryption

When running xfstests against Azure the following oops occurred on an arm64 system

Unable to handle kernel write to read-only memory at virtual address ffff0001221cf000 Mem abort info: ESR = 0x9600004f EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x0f: level 3 permission fault Data abort info: ISV = 0, ISS = 0x0000004f CM = 0, WnR = 1 swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000294f3000 [ffff0001221cf000] pgd=18000001ffff8003, p4d=18000001ffff8003, pud=18000001ff82e003, pmd=18000001ff71d003, pte=00600001221cf787 Internal error: Oops: 9600004f [#1] PREEMPT SMP ... pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) pc : memcpy+0x40/0x230 lr : scatterwalkcopychunks+0xe0/0x200 sp : ffff800014e92de0 x29: ffff800014e92de0 x28: ffff000114f9de80 x27: 0000000000000008 x26: 0000000000000008 x25: ffff800014e92e78 x24: 0000000000000008 x23: 0000000000000001 x22: 0000040000000000 x21: ffff000000000000 x20: 0000000000000001 x19: ffff0001037c4488 x18: 0000000000000014 x17: 235e1c0d6efa9661 x16: a435f9576b6edd6c x15: 0000000000000058 x14: 0000000000000001 x13: 0000000000000008 x12: ffff000114f2e590 x11: ffffffffffffffff x10: 0000040000000000 x9 : ffff8000105c3580 x8 : 2e9413b10000001a x7 : 534b4410fb86b005 x6 : 534b4410fb86b005 x5 : ffff0001221cf008 x4 : ffff0001037c4490 x3 : 0000000000000001 x2 : 0000000000000008 x1 : ffff0001037c4488 x0 : ffff0001221cf000 Call trace: memcpy+0x40/0x230 scatterwalkmapandcopy+0x98/0x100 cryptoccmencrypt+0x150/0x180 cryptoaeadencrypt+0x2c/0x40 cryptmessage+0x750/0x880 smb3inittransformrq+0x298/0x340 smbsendrqst.part.11+0xd8/0x180 smbsendrqst+0x3c/0x100 compoundsendrecv+0x534/0xbc0 smb2queryinfocompound+0x32c/0x440 smb2setea+0x438/0x4c0 cifsxattrset+0x5d4/0x7c0

This is because in scatterwalkcopychunks(), we attempted to write to a buffer (@sign) that was allocated in the stack (vmalloc area) by cryptmessage() and thus accessing its remaining 8 (x2) bytes ended up crossing a page boundary.

To simply fix it, we could just pass @sign kmalloc'd from cryptmessage() and then we're done. Luckily, we don't seem to pass any other vmalloc'd buffers in smbrqst::rqiov...

Instead, let's map the correct pages and offsets from vmalloc buffers as well in cifssgsetbuf() and then avoiding such oopses.

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

HID: multitouch: fix slab out-of-bounds access in mtreportfixup()

A malicious HID device can trigger a slab out-of-bounds during mtreportfixup() by passing in report descriptor smaller than 607 bytes. mtreportfixup() attempts to patch byte offset 607 of the descriptor with 0x25 by first checking if byte offset 607 is 0x15 however it lacks bounds checks to verify if the descriptor is big enough before conducting this check. Fix this bug by ensuring the descriptor size is at least 608 bytes before accessing it.

Below is the KASAN splat after the out of bounds access happens:

[ 13.671954] ================================================================== [ 13.672667] BUG: KASAN: slab-out-of-bounds in mtreportfixup+0x103/0x110 [ 13.673297] Read of size 1 at addr ffff888103df39df by task kworker/0:1/10 [ 13.673297] [ 13.673297] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0-00005-gec5d573d83f4-dirty #3 [ 13.673297] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/04 [ 13.673297] Call Trace: [ 13.673297] <TASK> [ 13.673297] dumpstacklvl+0x5f/0x80 [ 13.673297] printreport+0xd1/0x660 [ 13.673297] kasanreport+0xe5/0x120 [ 13.673297] asanreportload1noabort+0x18/0x20 [ 13.673297] mtreportfixup+0x103/0x110 [ 13.673297] hidopenreport+0x1ef/0x810 [ 13.673297] mtprobe+0x422/0x960 [ 13.673297] hiddeviceprobe+0x2e2/0x6f0 [ 13.673297] reallyprobe+0x1c6/0x6b0 [ 13.673297] driverprobedevice+0x24f/0x310 [ 13.673297] driverprobedevice+0x4e/0x220 [ 13.673297] deviceattachdriver+0x169/0x320 [ 13.673297] busforeachdrv+0x11d/0x1b0 [ 13.673297] deviceattach+0x1b8/0x3e0 [ 13.673297] deviceinitialprobe+0x12/0x20 [ 13.673297] busprobedevice+0x13d/0x180 [ 13.673297] deviceadd+0xe3a/0x1670 [ 13.673297] hidadddevice+0x31d/0xa40 [...]

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

cifs: Fix oops due to uninitialised variable

Fix smb3inittransformrq() to initialise buffer to NULL before calling netfsallocfolioqbuffer() as netfs assumes it can append to the buffer it is given. Setting it to NULL means it should start a fresh buffer, but the value is currently undefined.

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

inet: frags: flush pending skbs in fqdirpreexit()

We have been seeing occasional deadlocks on pernetopsrwsem since September in NIPA. The stuck task was usually modprobe (often loading a driver like ipvlan), trying to take the lock as a Writer. lockdep does not track readers for rwsems so the read wasn't obvious from the reports.

On closer inspection the Reader holding the lock was conntrack looping forever in nfconntrackcleanupnetlist(). Based on past experience with occasional NIPA crashes I looked thru the tests which run before the crash and noticed that the crash follows ipdefrag.sh. An immediate red flag. Scouring thru (de)fragmentation queues reveals skbs sitting around, holding conntrack references.

The problem is that since conntrack depends on nfdefragipv6, nfdefragipv6 will load first. Since nfdefragipv6 loads first its netns exit hooks run after conntrack's netns exit hook.

Flush all fragment queue SKBs during fqdirpreexit() to release conntrack references before conntrack cleanup runs. Also flush the queues in timer expiry handlers when they discover fqdir->dead is set, in case packet sneaks in while we're running the preexit flush.

The commit under Fixes is not exactly the culprit, but I think previously the timer firing would eventually unblock the spinning conntrack.

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

fs/xattr: missing fdput() in fremovexattr error path

In the Linux kernel, the fremovexattr() syscall calls fdget() to acquire a file reference but returns early without calling fdput() when strncpyfromuser() fails on the name argument. In multi-threaded processes where fdget() takes the slow path, this permanently leaks one file reference per call, pinning the struct file and associated kernel objects in memory. An unprivileged local user can exploit this to cause kernel memory exhaustion. The issue was inadvertently fixed by commit a71874379ec8 ("xattr: switch to CLASS(fd)").

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

macvlan: fix possible UAF in macvlanforwardsource()

Add RCU protection on (struct macvlansourceentry)->vlan.

Whenever macvlanhashdelsource() is called, we must clear entry->vlan pointer before RCU grace period starts.

This allows macvlanforwardsource() to skip over entries queued for freeing.

Note that macvlandev are already RCU protected, as they are embedded in a standard netdev (netdevpriv(ndev)).

https: //lore.kernel.org/netdev/695fb1e8.050a0220.1c677c.039f.GAE/T/#u

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

intelth: fix device leak on output open()

Make sure to drop the reference taken when looking up the th device during output device open() on errors and on close().

Note that a recent commit fixed the leak in a couple of open() error paths but not all of them, and the reference is still leaking on successful open().