In the Linux kernel, the following vulnerability has been resolved:
mptcp: make fallback action and fallback decision atomic
Syzkaller reported the following splat:
WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcpdofallback net/mptcp/protocol.h:1223 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcpdofallback net/mptcp/protocol.h:1244 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 checkfullyestablished net/mptcp/options.c:982 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcpincomingoptions+0x21a8/0x2510 net/mptcp/options.c:1153 Modules linked in: CPU: 1 UID: 0 PID: 7704 Comm: syz.3.1419 Not tainted 6.16.0-rc3-gbd5ce2324dba #20 PREEMPT(voluntary) Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:mptcpdofallback net/mptcp/protocol.h:1223 [inline] RIP: 0010:mptcpdofallback net/mptcp/protocol.h:1244 [inline] RIP: 0010:checkfullyestablished net/mptcp/options.c:982 [inline] RIP: 0010:mptcpincomingoptions+0x21a8/0x2510 net/mptcp/options.c:1153 Code: 24 18 e8 bb 2a 00 fd e9 1b df ff ff e8 b1 21 0f 00 e8 ec 5f c4 fc 44 0f b7 ac 24 b0 00 00 00 e9 54 f1 ff ff e8 d9 5f c4 fc 90 <0f> 0b 90 e9 b8 f4 ff ff e8 8b 2a 00 fd e9 8d e6 ff ff e8 81 2a 00 RSP: 0018:ffff8880a3f08448 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8880180a8000 RCX: ffffffff84afcf45 RDX: ffff888090223700 RSI: ffffffff84afdaa7 RDI: 0000000000000001 RBP: ffff888017955780 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff8880180a8910 R14: ffff8880a3e9d058 R15: 0000000000000000 FS: 00005555791b8500(0000) GS:ffff88811c495000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000110c2800b7 CR3: 0000000058e44000 CR4: 0000000000350ef0 Call Trace: <IRQ> tcpreset+0x26f/0x2b0 net/ipv4/tcpinput.c:4432 tcpvalidateincoming+0x1057/0x1b60 net/ipv4/tcpinput.c:5975 tcprcvestablished+0x5b5/0x21f0 net/ipv4/tcpinput.c:6166 tcpv4dorcv+0x5dc/0xa70 net/ipv4/tcpipv4.c:1925 tcpv4rcv+0x3473/0x44a0 net/ipv4/tcpipv4.c:2363 ipprotocoldeliverrcu+0xba/0x480 net/ipv4/ipinput.c:205 iplocaldeliverfinish+0x2f1/0x500 net/ipv4/ipinput.c:233 NFHOOK include/linux/netfilter.h:317 [inline] NFHOOK include/linux/netfilter.h:311 [inline] iplocaldeliver+0x1be/0x560 net/ipv4/ipinput.c:254 dstinput include/net/dst.h:469 [inline] iprcvfinish net/ipv4/ipinput.c:447 [inline] NFHOOK include/linux/netfilter.h:317 [inline] NFHOOK include/linux/netfilter.h:311 [inline] iprcv+0x514/0x810 net/ipv4/ipinput.c:567 netifreceiveskbonecore+0x197/0x1e0 net/core/dev.c:5975 netifreceiveskb+0x1f/0x120 net/core/dev.c:6088 processbacklog+0x301/0x1360 net/core/dev.c:6440 napipoll.constprop.0+0xba/0x550 net/core/dev.c:7453 napipoll net/core/dev.c:7517 [inline] netrxaction+0xb44/0x1010 net/core/dev.c:7644 handlesoftirqs+0x1d0/0x770 kernel/softirq.c:579 dosoftirq+0x3f/0x90 kernel/softirq.c:480 </IRQ> <TASK> localbhenableip+0xed/0x110 kernel/softirq.c:407 localbhenable include/linux/bottomhalf.h:33 [inline] inetcsklistenstop+0x2c5/0x1070 net/ipv4/inetconnectionsock.c:1524 mptcpchecklistenstop.part.0+0x1cc/0x220 net/mptcp/protocol.c:2985 mptcpchecklistenstop net/mptcp/mib.h:118 [inline] mptcpclose+0x9b9/0xbd0 net/mptcp/protocol.c:3000 mptcpclose+0x2f/0x140 net/mptcp/protocol.c:3066 inetrelease+0xed/0x200 net/ipv4/afinet.c:435 inet6release+0x4f/0x70 net/ipv6/afinet6.c:487 sockrelease+0xb3/0x270 net/socket.c:649 sockclose+0x1c/0x30 net/socket.c:1439 fput+0x402/0xb70 fs/filetable.c:465 taskworkrun+0x150/0x240 kernel/taskwork.c:227 resumeusermodework include/linux/resumeusermode.h:50 [inline] exittousermodeloop+0xd4 ---truncated---
iio: accel: fxls8962af: Fix use after free in fxls8962affifoflush
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.
atm: clip: Fix infinite recursive call of clippush().
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.
drm/gem: Acquire references on GEM handles for framebuffers
Bluetooth: hcicore: Fix use-after-free in vhciflush()
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:
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:
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:
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:
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:
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---
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:
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:
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)
In the Linux kernel, the following vulnerability has been resolved:
x86/sev: Use TSCFACTOR for Secure TSC frequency calculation
When using Secure TSC, the GUESTTSCFREQ MSR reports a frequency based on the nominal P0 frequency, which deviates slightly (typically ~0.2%) from the actual mean TSC frequency due to clocking parameters.
Over extended VM uptime, this discrepancy accumulates, causing clock skew between the hypervisor and a SEV-SNP VM, leading to early timer interrupts as perceived by the guest.
The guest kernel relies on the reported nominal frequency for TSC-based timekeeping, while the actual frequency set during SNPLAUNCHSTART may differ. This mismatch results in inaccurate time calculations, causing the guest to perceive hrtimers as firing earlier than expected.
Utilize the TSCFACTOR from the SEV firmware's secrets page (see "Secrets Page Format" in the SNP Firmware ABI Specification) to calculate the mean TSC frequency, ensuring accurate timekeeping and mitigating clock skew in SEV-SNP VMs.
Use earlyioremapencrypted() to map the secrets page as ioremapencrypted() uses kmalloc() which is not available during early TSC initialization and causes a panic.
[ bp: Drop the silly dummy var: https://lore.kernel.org/r/20250630192726.GBaGLlHl84xIopx4Pt@fatcrate.local ]
In the Linux kernel, the following vulnerability has been resolved:
wifi: mwifiex: discard erroneous disassoc frames on STA interface
When operating in concurrent STA/AP mode with host MLME enabled, the firmware incorrectly sends disassociation frames to the STA interface when clients disconnect from the AP interface. This causes kernel warnings as the STA interface processes disconnect events that don't apply to it:
[ 1303.240540] WARNING: CPU: 0 PID: 513 at net/wireless/mlme.c:141 cfg80211processdisassoc+0x78/0xec [cfg80211] [ 1303.250861] Modules linked in: 8021q garp stp mrp llc rfcomm bnep btnxpuart nlsiso88591 nlscp437 onboardus [ 1303.327651] CPU: 0 UID: 0 PID: 513 Comm: kworker/u9:2 Not tainted 6.16.0-rc1+ #3 PREEMPT [ 1303.335937] Hardware name: Toradex Verdin AM62 WB on Verdin Development Board (DT) [ 1303.343588] Workqueue: MWIFIEXRXWORKQUEUE mwifiexrxworkqueue [mwifiex] [ 1303.350856] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1303.357904] pc : cfg80211processdisassoc+0x78/0xec [cfg80211] [ 1303.364065] lr : cfg80211processdisassoc+0x70/0xec [cfg80211] [ 1303.370221] sp : ffff800083053be0 [ 1303.373590] x29: ffff800083053be0 x28: 0000000000000000 x27: 0000000000000000 [ 1303.380855] x26: 0000000000000000 x25: 00000000ffffffff x24: ffff000002c5b8ae [ 1303.388120] x23: ffff000002c5b884 x22: 0000000000000001 x21: 0000000000000008 [ 1303.395382] x20: ffff000002c5b8ae x19: ffff0000064dd408 x18: 0000000000000006 [ 1303.402646] x17: 3a36333a61623a30 x16: 32206d6f72662063 x15: ffff800080bfe048 [ 1303.409910] x14: ffff000003625300 x13: 0000000000000001 x12: 0000000000000000 [ 1303.417173] x11: 0000000000000002 x10: ffff000003958600 x9 : ffff000003625300 [ 1303.424434] x8 : ffff00003fd9ef40 x7 : ffff0000039fc280 x6 : 0000000000000002 [ 1303.431695] x5 : ffff0000038976d4 x4 : 0000000000000000 x3 : 0000000000003186 [ 1303.438956] x2 : 000000004836ba20 x1 : 0000000000006986 x0 : 00000000d00479de [ 1303.446221] Call trace: [ 1303.448722] cfg80211processdisassoc+0x78/0xec [cfg80211] (P) [ 1303.454894] cfg80211rxmlmemgmt+0x64/0xf8 [cfg80211] [ 1303.460362] mwifiexprocessmgmtpacket+0x1ec/0x460 [mwifiex] [ 1303.466380] mwifiexprocessstarxpacket+0x1bc/0x2a0 [mwifiex] [ 1303.472573] mwifiexhandlerxpacket+0xb4/0x13c [mwifiex] [ 1303.478243] mwifiexrxworkqueue+0x158/0x198 [mwifiex] [ 1303.483734] processonework+0x14c/0x28c [ 1303.487845] workerthread+0x2cc/0x3d4 [ 1303.491680] kthread+0x12c/0x208 [ 1303.495014] retfromfork+0x10/0x20
Add validation in the STA receive path to verify that disassoc/deauth frames originate from the connected AP. Frames that fail this check are discarded early, preventing them from reaching the MLME layer and triggering WARNON().
This filtering logic is similar with that used in the ieee80211rxmgmtdisassoc() function in mac80211, which drops disassoc frames that don't match the current BSSID (!etheraddrequal(mgmt->bssid, sdata->vif.cfg.apaddr)), ensuring only relevant frames are processed.
Tested on: - 8997 with FW 16.68.1.p197
In the Linux kernel, the following vulnerability has been resolved:
xfrm: interface: fix use-after-free after changing collectmd xfrm interface
collectmd property on xfrm interfaces can only be set on device creation, thus xfrmichangelink() should fail when called on such interfaces.
The check to enforce this was done only in the case where the xi was returned from xfrmilocate() which doesn't look for the collectmd interface, and thus the validation was never reached.
Calling changelink would thus errornously place the special interface xi in the xfrminet->xfrmi hash, but since it also exists in the xfrminet->collectmdxfrmi pointer it would lead to a double free when the net namespace was taken down [1].
Change the check to use the xi from netdevpriv which is available earlier in the function to prevent changes in xfrm collectmd interfaces.
[1] resulting oops: [ 8.516540] kernel BUG at net/core/dev.c:12029! [ 8.516552] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 8.516559] CPU: 0 UID: 0 PID: 12 Comm: kworker/u80:0 Not tainted 6.15.0-virtme #5 PREEMPT(voluntary) [ 8.516565] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 8.516569] Workqueue: netns cleanupnet [ 8.516579] RIP: 0010:unregisternetdevicemanynotify+0x101/0xab0 [ 8.516590] Code: 90 0f 0b 90 48 8b b0 78 01 00 00 48 8b 90 80 01 00 00 48 89 56 08 48 89 32 4c 89 80 78 01 00 00 48 89 b8 80 01 00 00 eb ac 90 <0f> 0b 48 8b 45 00 4c 8d a0 88 fe ff ff 48 39 c5 74 5c 41 80 bc 24 [ 8.516593] RSP: 0018:ffffa93b8006bd30 EFLAGS: 00010206 [ 8.516598] RAX: ffff98fe4226e000 RBX: ffffa93b8006bd58 RCX: ffffa93b8006bc60 [ 8.516601] RDX: 0000000000000004 RSI: 0000000000000000 RDI: dead000000000122 [ 8.516603] RBP: ffffa93b8006bdd8 R08: dead000000000100 R09: ffff98fe4133c100 [ 8.516605] R10: 0000000000000000 R11: 00000000000003d2 R12: ffffa93b8006be00 [ 8.516608] R13: ffffffff96c1a510 R14: ffffffff96c1a510 R15: ffffa93b8006be00 [ 8.516615] FS: 0000000000000000(0000) GS:ffff98fee73b7000(0000) knlGS:0000000000000000 [ 8.516619] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8.516622] CR2: 00007fcd2abd0700 CR3: 000000003aa40000 CR4: 0000000000752ef0 [ 8.516625] PKRU: 55555554 [ 8.516627] Call Trace: [ 8.516632] <TASK> [ 8.516635] ? rtnlislocked+0x15/0x20 [ 8.516641] ? unregisternetdevicequeue+0x29/0xf0 [ 8.516650] opsundolist+0x1f2/0x220 [ 8.516659] cleanupnet+0x1ad/0x2e0 [ 8.516664] processonework+0x160/0x380 [ 8.516673] workerthread+0x2aa/0x3c0 [ 8.516679] ? pfxworkerthread+0x10/0x10 [ 8.516686] kthread+0xfb/0x200 [ 8.516690] ? pfxkthread+0x10/0x10 [ 8.516693] ? pfxkthread+0x10/0x10 [ 8.516697] retfromfork+0x82/0xf0 [ 8.516705] ? pfxkthread+0x10/0x10 [ 8.516709] retfromforkasm+0x1a/0x30 [ 8.516718] </TASK>
HID: core: ensure the allocated report buffer can contain the reserved report ID