Bluetooth: hcisync: reject oversized Broadcast Announcement prepend
In the Linux kernel, the following vulnerability has been resolved:
xfrm: state: initialize stateptrs earlier in xfrmstatefind
In case of preemption, xfrmstatelookat will find a different pcpuid and look up states for that other CPU. If we matched a state for CPU2 in the statecache while the lookup started on CPU1, we will jump to "found", but the "best" state that we got will be ignored and we will enter the "acquire" block. This block uses stateptrs, which isn't initialized at this point.
Let's initialize stateptrs just after taking rcureadlock. This will also prevent a possible misuse in the future, if someone adjusts this function.
In the Linux kernel, the following vulnerability has been resolved:
arm64/entry: Mask DAIF in cpuswitchto(), callonirqstack()
cpuswitchto() and callonirqstack() manipulate SP to change to different stacks along with the Shadow Call Stack if it is enabled. Those two stack changes cannot be done atomically and both functions can be interrupted by SErrors or Debug Exceptions which, though unlikely, is very much broken : if interrupted, we can end up with mismatched stacks and Shadow Call Stack leading to clobbered stacks.
In cpuswitchto(), it can happen when SPEL0 points to the new task, but x18 stills points to the old task's SCS. When the interrupt handler tries to save the task's SCS pointer, it will save the old task SCS pointer (x18) into the new task struct (pointed to by SPEL0), clobbering it.
In callonirqstack(), it can happen when switching from the task stack to the IRQ stack and when switching back. In both cases, we can be interrupted when the SCS pointer points to the IRQ SCS, but SP points to the task stack. The nested interrupt handler pushes its return addresses on the IRQ SCS. It then detects that SP points to the task stack, calls callonirqstack() and clobbers the task SCS pointer with the IRQ SCS pointer, which it will also use !
This leads to tasks returning to addresses on the wrong SCS, or even on the IRQ SCS, triggering kernel panics via CONFIGVMAPSTACK or FPAC if enabled.
This is possible on a default config, but unlikely. However, when enabling CONFIGARM64PSEUDONMI, DAIF is unmasked and instead the GIC is responsible for filtering what interrupts the CPU should receive based on priority. Given the goal of emulating NMIs, pseudo-NMIs can be received by the CPU even in cpuswitchto() and callonirqstack(), possibly very frequently depending on the system configuration and workload, leading to unpredictable kernel panics.
Completely mask DAIF in cpuswitchto() and restore it when returning. Do the same in callonirqstack(), but restore and mask around the branch. Mask DAIF even if CONFIGSHADOWCALLSTACK is not enabled for consistency of behaviour between all configurations.
Introduce and use an assembly macro for saving and masking DAIF, as the existing one saves but only masks IF.
In the Linux kernel, the following vulnerability has been resolved:
regulator: core: fix NULL dereference on unbind due to stale coupling data
Failing to reset couplingdesc.ncoupled after freeing coupledrdevs can lead to NULL pointer dereference when regulators are accessed post-unbind.
This can happen during runtime PM or other regulator operations that rely on coupling metadata.
For example, on ridesx4, unbinding the 'reg-dummy' platform device triggers a panic in regulatorlockrecursive() due to stale coupling state.
Ensure ncoupled is set to 0 to prevent access to invalid pointers.
In the Linux kernel, the following vulnerability has been resolved:
iio: fix potential out-of-bound write
The buffer is set to 20 characters. If a caller write more characters, count is truncated to the max available space in "simplewritetobuffer". To protect from OoB access, check that the input size fit into buffer and add a zero terminator after copy to the end of the copied data.
In the Linux kernel, the following vulnerability has been resolved:
net: appletalk: Fix use-after-free in AARP proxy probe
The AARP proxyâprobe routine (aarpproxyprobenetwork) sends a probe, releases the aarplock, sleeps, then re-acquires the lock. During that window an expire timer thread (aarpexpiretimer) can remove and kfree() the same entry, leading to a use-after-free.
race condition:
cpu 0 | cpu 1 atalksendmsg() | atifproxyprobedevice() aarpsendddp() | aarpproxyprobenetwork() modtimer() | lock(aarplock) // LOCK!! timeout around 200ms | alloc(aarpentry) and then call | proxies[hash] = aarpentry aarpexpiretimeout() | aarpsendprobe() | unlock(aarplock) // UNLOCK!! lock(aarplock) // LOCK!! | msleep(100); aarpexpiretimer(&proxies[ct]) | free(aarpentry) | unlock(aarplock) // UNLOCK!! | | lock(aarplock) // LOCK!! | UAF aarpentry !!
================================================================== BUG: KASAN: slab-use-after-free in aarpproxyprobenetwork+0x560/0x630 net/appletalk/aarp.c:493 Read of size 4 at addr ffff8880123aa360 by task repro/13278
CPU: 3 UID: 0 PID: 13278 Comm: repro Not tainted 6.15.2 #3 PREEMPT(full) Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x116/0x1b0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:408 [inline] printreport+0xc1/0x630 mm/kasan/report.c:521 kasanreport+0xca/0x100 mm/kasan/report.c:634 aarpproxyprobenetwork+0x560/0x630 net/appletalk/aarp.c:493 atifproxyprobedevice net/appletalk/ddp.c:332 [inline] atifioctl+0xb58/0x16c0 net/appletalk/ddp.c:857 atalkioctl+0x198/0x2f0 net/appletalk/ddp.c:1818 sockdoioctl+0xdc/0x260 net/socket.c:1190 sockioctl+0x239/0x6a0 net/socket.c:1311 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:906 [inline] sesysioctl fs/ioctl.c:892 [inline] x64sysioctl+0x194/0x200 fs/ioctl.c:892 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xcb/0x250 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f </TASK>
Allocated: aarpalloc net/appletalk/aarp.c:382 [inline] aarpproxyprobenetwork+0xd8/0x630 net/appletalk/aarp.c:468 atifproxyprobedevice net/appletalk/ddp.c:332 [inline] atifioctl+0xb58/0x16c0 net/appletalk/ddp.c:857 atalkioctl+0x198/0x2f0 net/appletalk/ddp.c:1818
Freed: kfree+0x148/0x4d0 mm/slub.c:4841 aarpexpire net/appletalk/aarp.c:90 [inline] aarpexpiretimer net/appletalk/aarp.c:261 [inline] aarpexpiretimeout+0x480/0x6e0 net/appletalk/aarp.c:317
The buggy address belongs to the object at ffff8880123aa300 which belongs to the cache kmalloc-192 of size 192 The buggy address is located 96 bytes inside of freed 192-byte region [ffff8880123aa300, ffff8880123aa3c0)
Memory state around the buggy address: ffff8880123aa200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8880123aa280: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc ffff8880123aa300: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880123aa380: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ffff8880123aa400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ==================================================================
can: netlink: canchangelink(): fix NULL pointer deref of struct canpriv::dosetmode
In the Linux kernel, the following vulnerability has been resolved:
ASoC: mediatek: mt8365-dai-i2s: pass correct size to mt8365daisetpriv
Given mt8365daisetpriv allocate privsize space to copy privdata which means we should pass mt8365i2spriv[i] or "struct mtkafei2spriv" instead of afepriv which has the size of "struct mt8365afeprivate".
Otherwise the KASAN complains about.
[ 59.389765] BUG: KASAN: global-out-of-bounds in mt8365daisetpriv+0xc8/0x168 [sndsocmt8365pcm] ... [ 59.394789] Call trace: [ 59.395167] dumpbacktrace+0xa0/0x128 [ 59.395733] showstack+0x20/0x38 [ 59.396238] dumpstacklvl+0xe8/0x148 [ 59.396806] printreport+0x37c/0x5e0 [ 59.397358] kasanreport+0xac/0xf8 [ 59.397885] kasancheckrange+0xe8/0x190 [ 59.398485] asanmemcpy+0x3c/0x98 [ 59.399022] mt8365daisetpriv+0xc8/0x168 [sndsocmt8365pcm] [ 59.399928] mt8365daii2sregister+0x1e8/0x2b0 [sndsocmt8365pcm] [ 59.400893] mt8365afepcmdevprobe+0x4d0/0xdf0 [sndsocmt8365pcm] [ 59.401873] platformprobe+0xcc/0x228 [ 59.402442] reallyprobe+0x340/0x9e8 [ 59.402992] driverprobedevice+0x16c/0x3f8 [ 59.403638] driverprobedevice+0x64/0x1d8 [ 59.404256] driverattach+0x1dc/0x4c8 [ 59.404840] busforeachdev+0x100/0x190 [ 59.405442] driverattach+0x44/0x68 [ 59.405980] busadddriver+0x23c/0x500 [ 59.406550] driverregister+0xf8/0x3d0 [ 59.407122] platformdriverregister+0x68/0x98 [ 59.407810] mt8365afepcmdriverinit+0x2c/0xff8 [sndsocmt8365pcm]
In the Linux kernel, the following vulnerability has been resolved:
platform/x86: alienware-wmi-wmax: Fix dmisystemid array
Add missing empty member to awccdmitable.
In the Linux kernel, the following vulnerability has been resolved:
ipv6: mcast: Delay put pmc->idev in mlddeldelrec()
pmc->idev is still used in ip6mcclearsrc(), so as mldcleardelrec() does, the reference should be put after ip6mcclearsrc() return.
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (corsair-cpro) Validate the size of the received input buffer
Add bufferrecvsize to store the size of the received bytes. Validate bufferrecvsize in sendusbcmd().
In the Linux kernel, the following vulnerability has been resolved:
iio: adc: axp20xadc: Add missing sentinel to AXP717 ADC channel maps
The AXP717 ADC channel maps is missing a sentinel entry at the end. This causes a KASAN warning.
Add the missing sentinel entry.
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: ti: am65-cpsw-nuss: Fix skb size by accounting for skbsharedinfo
While transitioning from netdevallocipalign() to buildskb(), memory for the "skbsharedinfo" member of an "skb" was not allocated. Fix this by allocating "PAGESIZE" as the skb length, accounting for the packet length, headroom and tailroom, thereby including the required memory space for skbsharedinfo.
In the Linux kernel, the following vulnerability has been resolved:
net: appletalk: Fix device refcount leak in atrtrcreate()
When updating an existing route entry in atrtrcreate(), the old device reference was not being released before assigning the new device, leading to a device refcount leak. Fix this by calling devput() to release the old device reference before holding the new one.
In the Linux kernel, the following vulnerability has been resolved:
tracing: Add downwrite(traceeventsem) when adding trace event
When a module is loaded, it adds trace events defined by the module. It may also need to modify the modules trace printk formats to replace enum names with their values.
If two modules are loaded at the same time, the adding of the event to the ftraceevents list can corrupt the walking of the list in the code that is modifying the printk format strings and crash the kernel.
The addition of the event should take the traceeventsem for write while it adds the new event.
Also add a lockdepassertheld() on that semaphore in traceaddeventdirs() as it iterates the list.
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: nbpfaxi: Fix memory corruption in probe()
The nbpf->chan[] array is allocated earlier in the nbpfprobe() function and it has "numchannels" elements. These three loops iterate one element farther than they should and corrupt memory.
The changes to the second loop are more involved. In this case, we're copying data from the irqbuf[] array into the nbpf->chan[] array. If the data in irqbuf[i] is the error IRQ then we skip it, so the iterators are not in sync. I added a check to ensure that we don't go beyond the end of the irqbuf[] array. I'm pretty sure this can't happen, but it seemed harmless to add a check.
On the other hand, after the loop has ended there is a check to ensure that the "chan" iterator is where we expect it to be. In the original code we went one element beyond the end of the array so the iterator wasn't in the correct place and it would always return -EINVAL. However, now it will always be in the correct place. I deleted the check since we know the result.
In the Linux kernel, the following vulnerability has been resolved:
net: airoha: fix potential use-after-free in airohanpuget()
np->name was being used after calling ofnodeput(np), which releases the node and can lead to a use-after-free bug. Previously, ofnodeput(np) was called unconditionally after offinddevicebynode(np), which could result in a use-after-free if pdev is NULL.
This patch moves ofnodeput(np) after the error check to ensure the node is only released after both the error and success cases are handled appropriately, preventing potential resource issues.
In the Linux kernel, the following vulnerability has been resolved:
phy: tegra: xusb: Fix unbalanced regulator disable in UTMI PHY mode
When transitioning from USBROLEDEVICE to USBROLENONE, the code assumed that the regulator should be disabled. However, if the regulator is marked as always-on, regulatorisenabled() continues to return true, leading to an incorrect attempt to disable a regulator which is not enabled.
This can result in warnings such as:
[ 250.155624] WARNING: CPU: 1 PID: 7326 at drivers/regulator/core.c:3004 regulatordisable+0xe4/0x1a0 [ 250.155652] unbalanced disables for VINSYS5V0
To fix this, we move the regulator control logic into tegra186xusbpadctlidoverride() function since it's directly related to the ID override state. The regulator is now only disabled when the role transitions from USBROLEHOST to USBROLENONE, by checking the VBUSID register. This ensures that regulator enable/disable operations are properly balanced and only occur when actually transitioning to/from host mode.
In the Linux kernel, the following vulnerability has been resolved:
net: libwx: properly reset Rx ring descriptor
When device reset is triggered by feature changes such as toggling Rx VLAN offload, wx->doreset() is called to reinitialize Rx rings. The hardware descriptor ring may retain stale values from previous sessions. And only set the length to 0 in rxdesc[0] would result in building malformed SKBs. Fix it to ensure a clean slate after device reset.
[ 549.186435] [ C16] ------------[ cut here ]------------ [ 549.186457] [ C16] kernel BUG at net/core/skbuff.c:2814! [ 549.186468] [ C16] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 549.186472] [ C16] CPU: 16 UID: 0 PID: 0 Comm: swapper/16 Kdump: loaded Not tainted 6.16.0-rc4+ #23 PREEMPT(voluntary) [ 549.186476] [ C16] Hardware name: Micro-Star International Co., Ltd. MS-7E16/X670E GAMING PLUS WIFI (MS-7E16), BIOS 1.90 12/31/2024 [ 549.186478] [ C16] RIP: 0010:pskbpulltail+0x3ff/0x510 [ 549.186484] [ C16] Code: 06 f0 ff 4f 34 74 7b 4d 8b 8c 24 c8 00 00 00 45 8b 84 24 c0 00 00 00 e9 c8 fd ff ff 48 c7 44 24 08 00 00 00 00 e9 5e fe ff ff <0f> 0b 31 c0 e9 23 90 5b ff 41 f7 c6 ff 0f 00 00 75 bf 49 8b 06 a8 [ 549.186487] [ C16] RSP: 0018:ffffb391c0640d70 EFLAGS: 00010282 [ 549.186490] [ C16] RAX: 00000000fffffff2 RBX: ffff8fe7e4d40200 RCX: 00000000fffffff2 [ 549.186492] [ C16] RDX: ffff8fe7c3a4bf8e RSI: 0000000000000180 RDI: ffff8fe7c3a4bf40 [ 549.186494] [ C16] RBP: ffffb391c0640da8 R08: ffff8fe7c3a4c0c0 R09: 000000000000000e [ 549.186496] [ C16] R10: ffffb391c0640d88 R11: 000000000000000e R12: ffff8fe7e4d40200 [ 549.186497] [ C16] R13: 00000000fffffff2 R14: ffff8fe7fa01a000 R15: 00000000fffffff2 [ 549.186499] [ C16] FS: 0000000000000000(0000) GS:ffff8fef5ae40000(0000) knlGS:0000000000000000 [ 549.186502] [ C16] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 549.186503] [ C16] CR2: 00007f77d81d6000 CR3: 000000051a032000 CR4: 0000000000750ef0 [ 549.186505] [ C16] PKRU: 55555554 [ 549.186507] [ C16] Call Trace: [ 549.186510] [ C16] <IRQ> [ 549.186513] [ C16] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 549.186517] [ C16] skbpad+0xc7/0xf0 [ 549.186523] [ C16] wxcleanrxirq+0x355/0x3b0 [libwx] [ 549.186533] [ C16] wxpoll+0x92/0x120 [libwx] [ 549.186540] [ C16] napipoll+0x28/0x190 [ 549.186544] [ C16] netrxaction+0x301/0x3f0 [ 549.186548] [ C16] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 549.186551] [ C16] ? rawspinlockirqsave+0x1e/0x50 [ 549.186554] [ C16] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 549.186557] [ C16] ? wakeupnohzcpu+0x35/0x160 [ 549.186559] [ C16] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 549.186563] [ C16] handlesoftirqs+0xf9/0x2c0 [ 549.186568] [ C16] irqexitrcu+0xc7/0x130 [ 549.186572] [ C16] commoninterrupt+0xb8/0xd0 [ 549.186576] [ C16] </IRQ> [ 549.186577] [ C16] <TASK> [ 549.186579] [ C16] asmcommoninterrupt+0x22/0x40 [ 549.186582] [ C16] RIP: 0010:cpuidleenterstate+0xc2/0x420 [ 549.186585] [ C16] Code: 00 00 e8 11 0e 5e ff e8 ac f0 ff ff 49 89 c5 0f 1f 44 00 00 31 ff e8 0d ed 5c ff 45 84 ff 0f 85 40 02 00 00 fb 0f 1f 44 00 00 <45> 85 f6 0f 88 84 01 00 00 49 63 d6 48 8d 04 52 48 8d 04 82 49 8d [ 549.186587] [ C16] RSP: 0018:ffffb391c0277e78 EFLAGS: 00000246 [ 549.186590] [ C16] RAX: ffff8fef5ae40000 RBX: 0000000000000003 RCX: 0000000000000000 [ 549.186591] [ C16] RDX: 0000007fde0faac5 RSI: ffffffff826e53f6 RDI: ffffffff826fa9b3 [ 549.186593] [ C16] RBP: ffff8fe7c3a20800 R08: 0000000000000002 R09: 0000000000000000 [ 549.186595] [ C16] R10: 0000000000000000 R11: 000000000000ffff R12: ffffffff82ed7a40 [ 549.186596] [ C16] R13: 0000007fde0faac5 R14: 0000000000000003 R15: 0000000000000000 [ 549.186601] [ C16] ? cpuidleenterstate+0xb3/0x420 [ 549.186605] [ C16] cpuidleen ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
comedi: pcl812: Fix bit shift out of bounds
When checking for a supported IRQ number, the following test is used:
if ((1 << it->options[1]) & board->irqbits) {
However, it->options[i] is an unchecked int value from userspace, so the shift amount could be negative or out of bounds. Fix the test by requiring it->options[1] to be within bounds before proceeding with the original test. Valid it->options[1] values that select the IRQ will be in the range [1,15]. The value 0 explicitly disables the use of interrupts.
comedi: aioiiro16: Fix bit shift out of bounds
bpf: Reject %p% format string in bprintf-like helpers
In the Linux kernel, the following vulnerability has been resolved:
ice: add NULL check in eswitch lag check
The function icelagisswitchdevrunning() is being called from outside of the LAG event handler code. This results in the lag->uppernetdev being NULL sometimes. To avoid a NULL-pointer dereference, there needs to be a check before it is dereferenced.
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix irq-disabled in localbhenable()
The rxrpcassessMTUsize() function calls down into the IP layer to find out the MTU size for a route. When accepting an incoming call, this is called from rxrpcnewincomingcall() which holds interrupts disabled across the code that calls down to it. Unfortunately, the IP layer uses localbhenable() which, config dependent, throws a warning if IRQs are enabled:
WARNING: CPU: 1 PID: 5544 at kernel/softirq.c:387 localbhenableip+0x43/0xd0 ... RIP: 0010:localbhenableip+0x43/0xd0 ... Call Trace: <TASK> rtcacheroute+0x7e/0xa0 rtsetnexthop.isra.0+0x3b3/0x3f0 mkrouteoutput+0x43a/0x460 iprouteoutputkeyhash+0xf7/0x140 iprouteoutputflow+0x1b/0x90 rxrpcassessMTUsize.isra.0+0x2a0/0x590 rxrpcnewincomingpeer+0x46/0x120 rxrpcallocincomingcall+0x1b1/0x400 rxrpcnewincomingcall+0x1da/0x5e0 rxrpcinputpacket+0x827/0x900 rxrpciothread+0x403/0xb60 kthread+0x2f7/0x310 retfromfork+0x2a/0x230 retfromforkasm+0x1a/0x30 ... hardirqs last enabled at (23): rawspinunlockirq+0x24/0x50 hardirqs last disabled at (24): rawreadlockirq+0x17/0x70 softirqs last enabled at (0): copyprocess+0xc61/0x2730 softirqs last disabled at (25): rtadduncachedlist+0x3c/0x90
Fix this by moving the call to rxrpcassessMTUsize() out of rxrpcinitpeer() and further up the stack where it can be done without interrupts disabled.
It shouldn't be a problem for rxrpcnewincomingcall() to do it after the locks are dropped as pmtud is going to be performed by the I/O thread - and we're in the I/O thread at this point.
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix recv-recv race of completed call
If a call receives an event (such as incoming data), the call gets placed on the socket's queue and a thread in recvmsg can be awakened to go and process it. Once the thread has picked up the call off of the queue, further events will cause it to be requeued, and once the socket lock is dropped (recvmsg uses call->usermutex to allow the socket to be used in parallel), a second thread can come in and its recvmsg can pop the call off the socket queue again.
In such a case, the first thread will be receiving stuff from the call and the second thread will be blocked on call->usermutex. The first thread can, at this point, process both the event that it picked call for and the event that the second thread picked the call for and may see the call terminate - in which case the call will be "released", decoupling the call from the user call ID assigned to it (RXRPCUSERCALLID in the control message).
The first thread will return okay, but then the second thread will wake up holding the usermutex and, if it sees that the call has been released by the first thread, it will BUG thusly:
kernel BUG at net/rxrpc/recvmsg.c:474!
Fix this by just dequeuing the call and ignoring it if it is seen to be already released. We can't tell userspace about it anyway as the user call ID has become stale.
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix the smbdresponse slab to allow usercopy
The handling of received data in the smbdirect client code involves using copytoiter() to copy data from the smbdreponse struct's packet trailer to a folioq buffer provided by netfslib that encapsulates a chunk of pagecache.
If, however, CONFIGHARDENEDUSERCOPY=y, this will result in the checks then performed in copytoiter() oopsing with something like the following:
CIFS: Attempting to mount //172.31.9.1/test CIFS: VFS: RDMA transport established usercopy: Kernel memory exposure attempt detected from SLUB object 'smbdresponse0000000091e24ea1' (offset 81, size 63)! ------------[ cut here ]------------ kernel BUG at mm/usercopy.c:102! ... RIP: 0010:usercopyabort+0x6c/0x80 ... Call Trace: <TASK> checkheapobject+0xe3/0x120 checkobjectsize+0x4dc/0x6d0 smbdrecv+0x77f/0xfe0 [cifs] cifsreadvfromsocket+0x276/0x8f0 [cifs] cifsreadfromsocket+0xcd/0x120 [cifs] cifsdemultiplexthread+0x7e9/0x2d50 [cifs] kthread+0x396/0x830 retfromfork+0x2b8/0x3b0 retfromforkasm+0x1a/0x30
The problem is that the smbdresponse slab's packet field isn't marked as being permitted for usercopy.
Fix this by passing parameters to kmemslabcreate() to indicate that copytoiter() is permitted from the packet region of the smbdresponse slab objects, less the header space.
In the Linux kernel, the following vulnerability has been resolved:
drm/imagination: Fix kernel crash when hard resetting the GPU
The GPU hard reset sequence calls pmruntimeforcesuspend() and pmruntimeforceresume(), which according to their documentation should only be used during system-wide PM transitions to sleep states.
The main issue though is that depending on some internal runtime PM state as seen by pmruntimeforcesuspend() (whether the usage count is <= 1), pmruntimeforceresume() might not resume the device unless needed. If that happens, the runtime PM resume callback pvrpowerdeviceresume() is not called, the GPU clocks are not re-enabled, and the kernel crashes on the next attempt to access GPU registers as part of the power-on sequence.
Replace calls to pmruntimeforcesuspend() and pmruntimeforceresume() with direct calls to the driver's runtime PM callbacks, pvrpowerdevicesuspend() and pvrpowerdeviceresume(), to ensure clocks are re-enabled and avoid the kernel crash.
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix oops due to non-existence of prealloc backlog struct
If an AFRXRPC service socket is opened and bound, but calls are preallocated, then rxrpcallocincomingcall() will oops because the rxrpcbacklog struct doesn't get allocated until the first preallocation is made.
Fix this by returning NULL from rxrpcallocincomingcall() if there is no backlog struct. This will cause the incoming call to be aborted.
In the Linux kernel, the following vulnerability has been resolved:
wifi: prevent A-MSDU attacks in mesh networks
This patch is a mitigation to prevent the A-MSDU spoofing vulnerability for mesh networks. The initial update to the IEEE 802.11 standard, in response to the FragAttacks, missed this case (CVE-2025-27558). It can be considered a variant of CVE-2020-24588 but for mesh networks.
This patch tries to detect if a standard MSDU was turned into an A-MSDU by an adversary. This is done by parsing a received A-MSDU as a standard MSDU, calculating the length of the Mesh Control header, and seeing if the 6 bytes after this header equal the start of an rfc1042 header. If equal, this is a strong indication of an ongoing attack attempt.
This defense was tested with mac80211hwsim against a mesh network that uses an empty Mesh Address Extension field, i.e., when four addresses are used, and when using a 12-byte Mesh Address Extension field, i.e., when six addresses are used. Functionality of normal MSDUs and A-MSDUs was also tested, and confirmed working, when using both an empty and 12-byte Mesh Address Extension field.
It was also tested with mac80211hwsim that A-MSDU attacks in non-mesh networks keep being detected and prevented.
Note that the vulnerability being patched, and the defense being implemented, was also discussed in the following paper and in the following IEEE 802.11 presentation:
https://papers.mathyvanhoef.com/wisec2025.pdf https://mentor.ieee.org/802.11/dcn/25/11-25-0949-00-000m-a-msdu-mesh-spoof-protection.docx
In the Linux kernel, the following vulnerability has been resolved:
drm/xe/pf: Clear all LMTT pages on alloc
Our LMEM buffer objects are not cleared by default on alloc and during VF provisioning we only setup LMTT PTEs for the actually provisioned LMEM range. But beyond that valid range we might leave some stale data that could either point to some other VFs allocations or even to the PF pages.
Explicitly clear all new LMTT page to avoid the risk that a malicious VF would try to exploit that gap.
While around add asserts to catch any undesired PTE overwrites and low-level debug traces to track LMTT PT life-cycle.
(cherry picked from commit 3fae6918a3e27cce20ded2551f863fb05d4bef8d)