In the Linux kernel, the following vulnerability has been resolved:
erspan: Initialize optionslen before referencing options.
The struct iptunnelinfo has a flexible array member named options that is protected by a countedby(optionslen) attribute.
The compiler will use this information to enforce runtime bounds checking deployed by FORTIFYSOURCE string helpers.
As laid out in the GCC documentation, the counter must be initialized before the first reference to the flexible array member.
After scanning through the files that use struct iptunnelinfo and also refer to options or optionslen, it appears the normal case is to use the iptunnelinfooptsset() helper.
Said helper would initialize optionslen properly before copying data into options, however in the GRE ERSPAN code a partial update is done, preventing the use of the helper function.
Before this change the handling of ERSPAN traffic in GRE tunnels would cause a kernel panic when the kernel is compiled with GCC 15+ and having FORTIFYSOURCE configured:
memcpy: detected buffer overflow: 4 byte write of buffer size 0
Call Trace: <IRQ> fortifypanic+0xd/0xf erspanrcv.cold+0x68/0x83 ? iprouteinputslow+0x816/0x9d0 grercv+0x1b2/0x1c0 grercv+0x8e/0x100 ? rawv4input+0x2a0/0x2b0 ipprotocoldeliverrcu+0x1ea/0x210 iplocaldeliverfinish+0x86/0x110 iplocaldeliver+0x65/0x110 ? iprcvfinishcore+0xd6/0x360 iprcv+0x186/0x1a0
Reported-at: https://launchpad.net/bugs/2129580
In the Linux kernel, the following vulnerability has been resolved:
Input: lkkbd - disable pending work before freeing device
lkkbdinterrupt() schedules lk->tq via schedulework(), and the work handler lkkbdreinit() dereferences the lkkbd structure and its serio/inputdev fields.
lkkbddisconnect() and error paths in lkkbdconnect() free the lkkbd structure without preventing the reinit work from being queued again until serioclose() returns. This can allow the work handler to run after the structure has been freed, leading to a potential use-after-free.
Use disableworksync() instead of cancelworksync() to ensure the reinit work cannot be re-queued, and call it both in lkkbddisconnect() and in lkkbdconnect() error paths after serioopen().
In the Linux kernel, the following vulnerability has been resolved:
nvmet-tcp: add bounds checks in nvmettcpbuildpduiovec
nvmettcpbuildpduiovec() could walk past cmd->req.sg when a PDU length or offset exceeds sgcnt and then use bogus sg->length/offset values, leading to copytoiter() GPF/KASAN. Guard sgidx, remaining entries, and sg->length/offset before building the bvec.
In bindertransaction of binder.c, there is a possible use-after-free due to a race condition. This could lead to local denial of service with no additional execution privileges needed. User interaction is not needed for exploitation.
In the Linux kernel, the following vulnerability has been resolved:
gpio: omap: do not register driver in probe()
Commit 11a78b794496 ("ARM: OMAP: MPUIO wake updates") registers the omapmpuiodriver from omapmpuioinit(), which is called from omapgpioprobe().
However, it neither makes sense to register drivers from probe() callbacks of other drivers, nor does the driver core allow registering drivers with a device lock already being held.
The latter was revealed by commit dc23806a7c47 ("driver core: enforce devicelock for drivermatchdevice()") leading to a potential deadlock condition described in [1].
Additionally, the omapmpuiodriver is never unregistered from the driver core, even if the module is unloaded.
Hence, register the omapmpuiodriver from the module initcall and unregister it in moduleexit().
In the Linux kernel, the following vulnerability has been resolved:
crypto: authencesn - reject too-short AAD (assoclen<8) to match ESP/ESN spec
authencesn assumes an ESP/ESN-formatted AAD. When assoclen is shorter than the minimum expected length, cryptoauthencesndecrypt() can advance past the end of the destination scatterlist and trigger a NULL pointer dereference in scatterwalkmapandcopy(), leading to a kernel panic (DoS).
Add a minimum AAD length check to fail fast on invalid inputs.
In the Linux kernel, the following vulnerability has been resolved:
gue: Fix skb memleak with inner IP protocol 0.
syzbot reported skb memleak below. [0]
The repro generated a GUE packet with its inner protocol 0.
gueudprecv() returns -guehdr->protoctype for "resubmit" in ipprotocoldeliverrcu(), but this only works with non-zero protocol number.
Let's drop such packets.
Note that 0 is a valid number (IPv6 Hop-by-Hop Option).
I think it is not practical to encap HOPOPT in GUE, so once someone starts to complain, we could pass down a resubmit flag pointer to distinguish two zeros from the upper layer:
no error resubmit HOPOPT
[0] BUG: memory leak unreferenced object 0xffff888109695a00 (size 240): comm "syz.0.17", pid 6088, jiffies 4294943096 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 40 c2 10 81 88 ff ff 00 00 00 00 00 00 00 00 .@.............. backtrace (crc a84b336f): kmemleakallocrecursive include/linux/kmemleak.h:44 [inline] slabpostallochook mm/slub.c:4958 [inline] slaballocnode mm/slub.c:5263 [inline] kmemcacheallocnoprof+0x3b4/0x590 mm/slub.c:5270 buildskb+0x23/0x60 net/core/skbuff.c:474 buildskb+0x20/0x190 net/core/skbuff.c:490 tunbuildskb drivers/net/tun.c:1541 [inline] tunbuildskb+0x4a1/0xa40 drivers/net/tun.c:1636 tungetuser+0xc12/0x2030 drivers/net/tun.c:1770 tunchrwriteiter+0x71/0x120 drivers/net/tun.c:1999 newsyncwrite fs/readwrite.c:593 [inline] vfswrite+0x45d/0x710 fs/readwrite.c:686 ksyswrite+0xa7/0x170 fs/readwrite.c:738 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xa4/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f
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.
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:
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:
net: fix memory leak in skbsegmentlist for GRO packets
When skbsegmentlist() is called during packet forwarding, it handles packets that were aggregated by the GRO engine.
Historically, the segmentation logic in skbsegmentlist assumes that individual segments are split from a parent SKB and may need to carry their own socket memory accounting. Accordingly, the code transfers truesize from the parent to the newly created segments.
Prior to commit ed4cccef64c1 ("gro: fix ownership transfer"), this truesize subtraction in skbsegmentlist() was valid because fragments still carry a reference to the original socket.
However, commit ed4cccef64c1 ("gro: fix ownership transfer") changed this behavior by ensuring that fraglist entries are explicitly orphaned (skb->sk = NULL) to prevent illegal orphaning later in the stack. This change meant that the entire socket memory charge remained with the head SKB, but the corresponding accounting logic in skbsegmentlist() was never updated.
As a result, the current code unconditionally adds each fragment's truesize to deltatruesize and subtracts it from the parent SKB. Since the fragments are no longer charged to the socket, this subtraction results in an effective under-count of memory when the head is freed. This causes skwmemalloc to remain non-zero, preventing socket destruction and leading to a persistent memory leak.
The leak can be observed via KMEMLEAK when tearing down the networking environment:
unreferenced object 0xffff8881e6eb9100 (size 2048): comm "ping", pid 6720, jiffies 4295492526 backtrace: kmemcacheallocnoprof+0x5c6/0x800 skprotalloc+0x5b/0x220 skalloc+0x35/0xa00 inet6create.part.0+0x303/0x10d0 sockcreate+0x248/0x640 syssocket+0x11b/0x1d0
Since skbsegmentlist() is exclusively used for SKBGSOFRAGLIST packets constructed by GRO, the truesize adjustment is removed.
The call to skbreleaseheadstate() must be preserved. As documented in commit cf673ed0e057 ("net: fix fraglist segmentation reference count leak"), it is still required to correctly drop references to SKB extensions that may be overwritten during copyskbheader().
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftables: fix inverted genmask check in nftmapcatchallactivate()
nftmapcatchallactivate() has an inverted element activity check compared to its non-catchall counterpart nftmapelemactivate() and compared to what is logically required.
nftmapcatchallactivate() is called from the abort path to re-activate catchall map elements that were deactivated during a failed transaction. It should skip elements that are already active (they don't need re-activation) and process elements that are inactive (they need to be restored). Instead, the current code does the opposite: it skips inactive elements and processes active ones.
Compare the non-catchall activate callback, which is correct:
nftmapelemactivate(): if (nftsetelemactive(ext, iter->genmask)) return 0; / skip active, process inactive /
With the buggy catchall version:
nftmapcatchallactivate(): if (!nftsetelemactive(ext, genmask)) continue; / skip inactive, process active /
The consequence is that when a DELSET operation is aborted, nftsetelemdataactivate() is never called for the catchall element. For NFTGOTO verdict elements, this means nftdatahold() is never called to restore the chain->use reference count. Each abort cycle permanently decrements chain->use. Once chain->use reaches zero, DELCHAIN succeeds and frees the chain while catchall verdict elements still reference it, resulting in a use-after-free.
This is exploitable for local privilege escalation from an unprivileged user via user namespaces + nftables on distributions that enable CONFIGUSERNS and CONFIGNFTABLES.
Fix by removing the negation so the check matches nftmapelemactivate(): skip active elements, process inactive ones.
dmaengine: idxd: fix device leaks on compat bind and unbind
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:
ipv4: Fix reference count leak when using error routes with nexthop objects
When a nexthop object is deleted, it is marked as dead and then fibtableflush() is called to flush all the routes that are using the dead nexthop.
The current logic in fibtableflush() is to only flush error routes (e.g., blackhole) when it is called as part of network namespace dismantle (i.e., with flushall=true). Therefore, error routes are not flushed when their nexthop object is deleted:
# ip link add name dummy1 up type dummy # ip nexthop add id 1 dev dummy1 # ip route add 198.51.100.1/32 nhid 1 # ip route add blackhole 198.51.100.2/32 nhid 1 # ip nexthop del id 1 # ip route show blackhole 198.51.100.2 nhid 1 dev dummy1
As such, they keep holding a reference on the nexthop object which in turn holds a reference on the nexthop device, resulting in a reference count leak:
# ip link del dev dummy1 [ 70.516258] unregisternetdevice: waiting for dummy1 to become free. Usage count = 2
Fix by flushing error routes when their nexthop is marked as dead.
IPv6 does not suffer from this problem.
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timer
When advancing the target expiration for the guest's APIC timer in periodic mode, set the expiration to "now" if the target expiration is in the past (similar to what is done in updatetargetexpiration()). Blindly adding the period to the previous target expiration can result in KVM generating a practically unbounded number of hrtimer IRQs due to programming an expired timer over and over. In extreme scenarios, e.g. if userspace pauses/suspends a VM for an extended duration, this can even cause hard lockups in the host.
Currently, the bug only affects Intel CPUs when using the hypervisor timer (HV timer), a.k.a. the VMX preemption timer. Unlike the software timer, a.k.a. hrtimer, which KVM keeps running even on exits to userspace, the HV timer only runs while the guest is active. As a result, if the vCPU does not run for an extended duration, there will be a huge gap between the target expiration and the current time the vCPU resumes running. Because the target expiration is incremented by only one period on each timer expiration, this leads to a series of timer expirations occurring rapidly after the vCPU/VM resumes.
More critically, when the vCPU first triggers a periodic HV timer expiration after resuming, advancing the expiration by only one period will result in a target expiration in the past. As a result, the delta may be calculated as a negative value. When the delta is converted into an absolute value (tscdeadline is an unsigned u64), the resulting value can overflow what the HV timer is capable of programming. I.e. the large value will exceed the VMX Preemption Timer's maximum bit width of cpupreemptiontimermulti + 32, and thus cause KVM to switch from the HV timer to the software timer (hrtimers).
After switching to the software timer, periodic timer expiration callbacks may be executed consecutively within a single clock interrupt handler, because hrtimers honors KVM's request for an expiration in the past and immediately re-invokes KVM's callback after reprogramming. And because the interrupt handler runs with IRQs disabled, restarting KVM's hrtimer over and over until the target expiration is advanced to "now" can result in a hard lockup.
E.g. the following hard lockup was triggered in the host when running a Windows VM (only relevant because it used the APIC timer in periodic mode) after resuming the VM from a long suspend (in the host).
NMI watchdog: Watchdog detected hard LOCKUP on cpu 45 ... RIP: 0010:advanceperiodictargetexpiration+0x4d/0x80 [kvm] ... RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046 RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500 RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0 R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0 R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8 FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0 PKRU: 55555554 Call Trace: <IRQ> apictimerfn+0x31/0x50 [kvm] hrtimerrunqueues+0x100/0x280 hrtimerinterrupt+0x100/0x210 ? ttwudowakeup+0x19/0x160 smpapictimerinterrupt+0x6a/0x130 apictimerinterrupt+0xf/0x20 </IRQ>
Moreover, if the suspend duration of the virtual machine is not long enough to trigger a hard lockup in this scenario, since commit 98c25ead5eda ("KVM: VMX: Move preemption timer <=> hrtimer dance to common x86"), KVM will continue using the software timer until the guest reprograms the APIC timer in some way. Since the periodic timer does not require frequent APIC timer register programming, the guest may continue to use the software timer in ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix reference count leak in bpfprogtestrunxdp()
syzbot is reporting
unregisternetdevice: waiting for sit0 to become free. Usage count = 2
problem. A debug printk() patch found that a refcount is obtained at xdpconvertmdtobuff() from bpfprogtestrunxdp().
According to commit ec94670fcb3b ("bpf: Support specifying ingress via xdpmd context in BPFPROGTESTRUN"), the refcount obtained by xdpconvertmdtobuff() will be released by xdpconvertbufftomd().
Therefore, we can consider that the error handling path introduced by commit 1c1949982524 ("bpf: introduce frags support to bpfprogtestrunxdp()") forgot to call xdpconvertbufftomd().
In the Linux kernel, the following vulnerability has been resolved:
net: rose: fix invalid array index in rosekillbydevice()
rosekillbydevice() collects sockets into a local array[] and then iterates over them to disconnect sockets bound to a device being brought down.
The loop mistakenly indexes array[cnt] instead of array[i]. For cnt < ARRAYSIZE(array), this reads an uninitialized entry; for cnt == ARRAYSIZE(array), it is an out-of-bounds read. Either case can lead to an invalid socket pointer dereference and also leaks references taken via sockhold().
Fix the index to use i.
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: bcm-sba-raid: fix device leak on probe
Make sure to drop the reference taken when looking up the mailbox device during probe on probe failures and on driver unbind.
In the Linux kernel, the following vulnerability has been resolved:
scsi: aic94xx: fix use-after-free in device removal path
The asdpciremove() function fails to synchronize with pending tasklets before freeing the asdha structure, leading to a potential use-after-free vulnerability.
When a device removal is triggered (via hot-unplug or module unload), race condition can occur.
The fix adds taskletkill() before freeing the asdha structure, ensuring all scheduled tasklets complete before cleanup proceeds.
In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: fix the crash issue for zero copy XDPTX action
There is a crash issue when running zero copy XDPTX action, the crash log is shown below.
[ 216.122464] Unable to handle kernel paging request at virtual address fffeffff80000000 [ 216.187524] Internal error: Oops: 0000000096000144 [#1] SMP [ 216.301694] Call trace: [ 216.304130] dcachecleanpoc+0x20/0x38 (P) [ 216.308308] dmasyncsinglefordevice+0x1bc/0x1e0 [ 216.313351] stmmacxdpxmitxdpf+0x354/0x400 [ 216.317701] stmmacxdprunprog+0x164/0x368 [ 216.322139] stmmacnapipollrxtx+0xba8/0xf00 [ 216.326576] napipoll+0x40/0x218 [ 216.408054] Kernel panic - not syncing: Oops: Fatal exception in interrupt
For XDPTX action, the xdpbuff is converted to xdpframe by xdpconvertbufftoframe(). The memory type of the resulting xdpframe depends on the memory type of the xdpbuff. For page pool based xdpbuff it produces xdpframe with memory type MEMTYPEPAGEPOOL. For zero copy XSK pool based xdpbuff it produces xdpframe with memory type MEMTYPEPAGEORDER0. However, stmmacxdpxmitback() does not check the memory type and always uses the page pool type, this leads to invalid mappings and causes the crash. Therefore, check the xdpbuff memory type in stmmacxdpxmitback() to fix this issue.
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:
viawdt: fix critical boot hang due to unnamed resource allocation
The VIA watchdog driver uses allocateresource() to reserve a MMIO region for the watchdog control register. However, the allocated resource was not given a name, which causes the kernel resource tree to contain an entry marked as "<BAD>" under /proc/iomem on x86 platforms.
During boot, this unnamed resource can lead to a critical hang because subsequent resource lookups and conflict checks fail to handle the invalid entry properly.
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: qcom: gpi: Fix memory leak in gpiperipheralconfig()
Fix a memory leak in gpiperipheralconfig() where the original memory pointed to by gchan->config could be lost if krealloc() fails.
The issue occurs when: 1. gchan->config points to previously allocated memory 2. krealloc() fails and returns NULL 3. The function directly assigns NULL to gchan->config, losing the reference to the original memory 4. The original memory becomes unreachable and cannot be freed
Fix this by using a temporary variable to hold the krealloc() result and only updating gchan->config when the allocation succeeds.
Found via static analysis and code review.
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: add VLAN id validation before using
Currently, the VLAN id may be used without validation when receive a VLAN configuration mailbox from VF. The length of vlandelfailbmap is BITSTOLONGS(VLANNVID). It may cause out-of-bounds memory access once the VLAN id is bigger than or equal to VLANNVID.
Therefore, VLAN id needs to be checked to ensure it is within the range of VLANNVID.
In the Linux kernel, the following vulnerability has been resolved:
ipv4: ipgre: make ipgreheader() robust
Analog to commit db5b4e39c4e6 ("ip6gre: make ip6greheader() robust")
Over the years, syzbot found many ways to crash the kernel in ipgreheader() [1].
This involves team or bonding drivers ability to dynamically change their dev->neededheadroom and/or dev->hardheaderlen
In this particular crash mldnewpack() allocated an skb with a too small reserve/headroom, and by the time mldsendpack() was called, syzbot managed to attach an ipgre device.
[1] skbuff: skbunderpanic: text:ffffffff89ea3cb7 len:2030915468 put:2030915372 head:ffff888058b43000 data:ffff887fdfa6e194 tail:0x120 end:0x6c0 dev:team0 kernel BUG at net/core/skbuff.c:213 ! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 1322 Comm: kworker/1:9 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Workqueue: mld mldifcwork RIP: 0010:skbpanic+0x157/0x160 net/core/skbuff.c:213 Call Trace: <TASK> skbunderpanic net/core/skbuff.c:223 [inline] skbpush+0xc3/0xe0 net/core/skbuff.c:2641 ipgreheader+0x67/0x290 net/ipv4/ipgre.c:897 devhardheader include/linux/netdevice.h:3436 [inline] neighconnectedoutput+0x286/0x460 net/core/neighbour.c:1618 NFHOOKCOND include/linux/netfilter.h:307 [inline] ip6output+0x340/0x550 net/ipv6/ip6output.c:247 NFHOOK+0x9e/0x380 include/linux/netfilter.h:318 mldsendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mldsendcr net/ipv6/mcast.c:2154 [inline] mldifcwork+0x83e/0xd60 net/ipv6/mcast.c:2693 processonework kernel/workqueue.c:3257 [inline] processscheduledworks+0xad1/0x1770 kernel/workqueue.c:3340 workerthread+0x8a0/0xda0 kernel/workqueue.c:3421 kthread+0x711/0x8a0 kernel/kthread.c:463 retfromfork+0x510/0xa50 arch/x86/kernel/process.c:158 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:246
In the Linux kernel, the following vulnerability has been resolved:
libceph: return the handler error from monhandleauthdone()
Currently any error from cephauthhandlereplydone() is propagated via finishauth() but isn't returned from monhandleauthdone(). This results in higher layers learning that (despite the monitor considering us to be successfully authenticated) something went wrong in the authentication phase and reacting accordingly, but msgr2 still trying to proceed with establishing the session in the background. In the case of secure mode this can trigger a WARN in setupcrypto() and later lead to a NULL pointer dereference inside of prepareauthsignature().
In the Linux kernel, the following vulnerability has been resolved:
be2net: Fix NULL pointer dereference in becmdgetmacfromlist
When the parameter pmacidvalid argument of becmdgetmacfromlist() is set to false, the driver may request the PMACID from the firmware of the network card, and this function will store that PMACID at the provided address pmacid. This is the contract of this function.
However, there is a location within the driver where both pmacidvalid == false and pmacid == NULL are being passed. This could result in dereferencing a NULL pointer.
To resolve this issue, it is necessary to pass the address of a stub variable to the function.
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: mmppdma: Fix race condition in mmppdmaresidue()
Add proper locking in mmppdmaresidue() to prevent use-after-free when accessing descriptor list and descriptor contents.
The race occurs when multiple threads call txstatus() while the tasklet on another CPU is freeing completed descriptors:
CPU 0 CPU 1 ----- ----- mmppdmatxstatus() mmppdmaresidue() -> NO LOCK held listforeachentry(sw, ..) DMA interrupt dmadotasklet() -> spinlock(&desclock) listmove(sw->node, ...) spinunlock(&desclock) | dmapoolfree(sw) <- FREED! -> access sw->desc <- UAF!
This issue can be reproduced when running dmatest on the same channel with multiple threads (threadsperchan > 1).
Fix by protecting the chainrunning list iteration and descriptor access with the chan->desclock spinlock.
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Fix use-after-free in inet6addrdel().
syzbot reported use-after-free of inet6ifaddr in inet6addrdel(). [0]
The cited commit accidentally moved ipv6deladdr() for mngtmpaddr before reading its ifp->flags for temporary addresses in inet6addrdel().
Let's move ipv6deladdr() down to fix the UAF.
[0]: BUG: KASAN: slab-use-after-free in inet6addrdel.constprop.0+0x67a/0x6b0 net/ipv6/addrconf.c:3117 Read of size 4 at addr ffff88807b89c86c by task syz.3.1618/9593
CPU: 0 UID: 0 PID: 9593 Comm: syz.3.1618 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xcd/0x630 mm/kasan/report.c:482 kasanreport+0xe0/0x110 mm/kasan/report.c:595 inet6addrdel.constprop.0+0x67a/0x6b0 net/ipv6/addrconf.c:3117 addrconfdelifaddr+0x11e/0x190 net/ipv6/addrconf.c:3181 inet6ioctl+0x1e5/0x2b0 net/ipv6/afinet6.c:582 sockdoioctl+0x118/0x280 net/socket.c:1254 sockioctl+0x227/0x6b0 net/socket.c:1375 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:597 [inline] sesysioctl fs/ioctl.c:583 [inline] x64sysioctl+0x18e/0x210 fs/ioctl.c:583 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xcd/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f164cf8f749 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f164de64038 EFLAGS: 00000246 ORIGRAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f164d1e5fa0 RCX: 00007f164cf8f749 RDX: 0000200000000000 RSI: 0000000000008936 RDI: 0000000000000003 RBP: 00007f164d013f91 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f164d1e6038 R14: 00007f164d1e5fa0 R15: 00007ffde15c8288 </TASK>
Allocated by task 9593: kasansavestack+0x33/0x60 mm/kasan/common.c:56 kasansavetrack+0x14/0x30 mm/kasan/common.c:77 poisonkmallocredzone mm/kasan/common.c:397 [inline] kasankmalloc+0xaa/0xb0 mm/kasan/common.c:414 kmallocnoprof include/linux/slab.h:957 [inline] kzallocnoprof include/linux/slab.h:1094 [inline] ipv6addaddr+0x4e3/0x2010 net/ipv6/addrconf.c:1120 inet6addradd+0x256/0x9b0 net/ipv6/addrconf.c:3050 addrconfaddifaddr+0x1fc/0x450 net/ipv6/addrconf.c:3160 inet6ioctl+0x103/0x2b0 net/ipv6/afinet6.c:580 sockdoioctl+0x118/0x280 net/socket.c:1254 sockioctl+0x227/0x6b0 net/socket.c:1375 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:597 [inline] sesysioctl fs/ioctl.c:583 [inline] x64sysioctl+0x18e/0x210 fs/ioctl.c:583 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xcd/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f
Freed by task 6099: kasansavestack+0x33/0x60 mm/kasan/common.c:56 kasansavetrack+0x14/0x30 mm/kasan/common.c:77 kasansavefreeinfo+0x3b/0x60 mm/kasan/generic.c:584 poisonslabobject mm/kasan/common.c:252 [inline] kasanslabfree+0x5f/0x80 mm/kasan/common.c:284 kasanslabfree include/linux/kasan.h:234 [inline] slabfreehook mm/slub.c:2540 [inline] slabfreefreelisthook mm/slub.c:2569 [inline] slabfreebulk mm/slub.c:6696 [inline] kmemcachefreebulk mm/slub.c:7383 [inline] kmemcachefreebulk+0x2bf/0x680 mm/slub.c:7362 kfreebulk include/linux/slab.h:830 [inline] kvfreercubulk+0x1b7/0x1e0 mm/slabcommon.c:1523 kvfreercudrainready mm/slabcommon.c:1728 [inline] kfreercumonitor+0x1d0/0x2f0 mm/slabcommon.c:1801 processonework+0x9ba/0x1b20 kernel/workqueue.c:3257 processscheduledworks kernel/workqu ---truncated---