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

drm/amdgpu: check if hubbub is NULL in debugfs/amdgpudmcapabilities

drm/amd/display: fix a Null pointer dereference vulnerability

drm/amdgpu: prevent immediate PASID reuse case

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

net: dsa: b53: do not enable EEE on bcm63xx

BCM63xx internal switches do not support EEE, but provide multiple RGMII ports where external PHYs may be connected. If one of these PHYs are EEE capable, we may try to enable EEE for the MACs, which then hangs the system on access of the (non-existent) EEE registers.

Fix this by checking if the switch actually supports EEE before attempting to configure it.

An issue was discovered in l2capsockrelease in net/bluetooth/l2capsock.c in the Linux kernel before 6.4.10. There is a use-after-free because the children of an sk are mishandled.

A remote denial of service vulnerability was found in the Linux kernel’s TIPC kernel module. The while loop in tipclinkxmit() hits an unknown state while attempting to parse SKBs, which are not in the queue. Sending two small UDP packets to a system with a UDP bearer results in the CPU utilization for the system to instantly spike to 100%, causing a denial of service condition.

A flaw in the Linux Kernel found. There are use-after-free vulnerabilities in drivers/media/rc/eneir.c of linux that allow attacker to crash linux kernel without any privilege by detaching rc device.

When the rc device is detaching, function eneremove() will be called. But the synchronizations in eneremove() are bad. The situations that may lead to race conditions are shown below.

Firstly, the rx receiver is disabled with enerxdisable() before rcunregisterdevice() in eneremove(), which means it can be enabled again if a process opens /dev/lirc0 between enerxdisable() and rcunregisterdevice().

(cleanup routine) | (open routine) eneremove() | enerxdisable(dev); | eneopen() | enerxenable(dev); //re-enable!

Secondly, the irqaction descriptor is freed by freeirq() before the rc device is unregistered, which means irqaction descriptor may be accessed again after it is deallocated.

(free routine) | (use routine) eneremove() | enerxenable() freeirq(dev->irq, ...); //FREE | enerxenablehw() | enewritereg(..., dev->irq << 1) //USE |

Thirdly, the timer can call enetxsample() that can write to the io ports, which means the io ports could be accessed again after they are deallocated by releaseregion().

(free routine) | (use routine) eneremove() | enetxsample() releaseregion(dev->hwio, ...); //FREE | enewritereg() | outb(..., dev->hwio + ENEIO) //USE

Fourthly, there is no function to cancel txsimtimer in eneremove(), the timer handler enetxirqsim() could race with eneremove(). As a result, the UAF bugs could happen, the process is shown below.

(free routine) | (use routine) | modtimer(&dev->txsimtimer, ..) eneremove() | (wait a time) kfree(dev) //FREE | enetxirqsim() | dev->hwlock //USE | enetxsample(dev) //USE

------------------------------------------

Reference: https://github.com/torvalds/linux/commit/29b0589a865b6f66d141d79b2dd1373e4e50fe17

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

xfrm: hold dev ref until after transportfinish NFHOOK

After async crypto completes, xfrminputresume() calls devput() immediately on re-entry before the skb reaches transportfinish. The skb->dev pointer is then used inside NFHOOK and its okfn, which can race with device teardown.

Remove the devput from the async resumption entry and instead drop the reference after the NFHOOK call in transportfinish, using a saved device pointer since NFHOOK may consume the skb. This covers NFDROP, NFQUEUE and NFSTOLEN paths that skip the okfn.

For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set.

A use-after-free vulnerability in the Linux kernel's afunix component can be exploited to achieve local privilege escalation.

The unixstreamsendpage() function tries to add data to the last skb in the peer's recv queue without locking the queue. Thus there is a race where unixstreamsendpage() could access an skb locklessly that is being released by garbage collection, resulting in use-after-free.

We recommend upgrading past commit 790c2f9d15b594350ae9bca7b236f2b1859de02c (or backported equivalents).

A flaw was found in the Linux kernel. This flaw allows an attacker to crash the Linux kernel by simulating amateur radio from the user space, resulting in a null-ptr-deref vulnerability and a use-after-free vulnerability.

drivers/usb/gadget/legacy/inode.c in the Linux kernel through 5.16.8 mishandles dev->buf release.

A flaw in the Linux Kernel found. A use-after-free vulnerability in the Linux kernel's net/sched: clsu32 component can be exploited to achieve local privilege escalation. If tcfchangeindev() fails, u32setparms() will immediately return an error after incrementing or decrementing the reference counter in tcfbindfilter(). If an attacker can control the reference counter and set it to zero, they can cause the reference to be freed, leading to a use-after-free vulnerability.

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=04c55383fa5689357bcdd2c8036725a55ed632bc

drm/amd/display: Increase blocksequence array size

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

bridge: brndsend: validate ND option lengths

brndsend() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload.

Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address.

bridge: brndsend: linearize skb before parsing ND options

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

net/sched: clsflow: fix NULL pointer dereference on shared blocks

flowchange() calls tcfblockq() and dereferences q->handle to derive a default baseclass. Shared blocks leave block->q NULL, causing a NULL deref when a flow filter without a fully qualified baseclass is created on a shared block.

Check tcfblockshared() before accessing block->q and return -EINVAL for shared blocks. This avoids the null-deref shown below:

======================================================================= KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:flowchange (net/sched/clsflow.c:508) Call Trace: tcnewtfilter (net/sched/clsapi.c:2432) rtnetlinkrcvmsg (net/core/rtnetlink.c:6980) [...] =======================================================================

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

net/sched: clsfw: fix NULL pointer dereference on shared blocks

The old-method path in fwclassify() calls tcfblockq() and dereferences q->handle. Shared blocks leave block->q NULL, causing a NULL deref when an empty clsfw filter is attached to a shared block and a packet with a nonzero major skb mark is classified.

Reject the configuration in fwchange() when the old method (no TCAOPTIONS) is used on a shared block, since fwclassify()'s old-method path needs block->q which is NULL for shared blocks.

The fixed null-ptr-deref calling stack: KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:fwclassify (net/sched/clsfw.c:81) Call Trace: tcfclassify (./include/net/tcwrapper.h:197 net/sched/clsapi.c:1764 net/sched/clsapi.c:1860) tcrun (net/core/dev.c:4401) devqueuexmit (net/core/dev.c:4535 net/core/dev.c:4790)

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

net: bridge: fix ndtbl NULL dereference when IPv6 is disabled

When booting with the 'ipv6.disable=1' parameter, the ndtbl is never initialized because inet6init() exits before ndiscinit() is called which initializes it. Then, if neighsuppress is enabled and an ICMPv6 Neighbor Discovery packet reaches the bridge, brdosuppressnd() will dereference ipv6stub->ndtbl which is NULL, passing it to neighlookup(). This causes a kernel NULL pointer dereference.

BUG: kernel NULL pointer dereference, address: 0000000000000268 Oops: 0000 [#1] PREEMPT SMP NOPTI [...] RIP: 0010:neighlookup+0x16/0xe0 [...] Call Trace: <IRQ> ? neighlookup+0x16/0xe0 brdosuppressnd+0x160/0x290 [bridge] brhandleframefinish+0x500/0x620 [bridge] brhandleframe+0x353/0x440 [bridge] netifreceiveskbcore.constprop.0+0x298/0x1110 netifreceiveskbonecore+0x3d/0xa0 processbacklog+0xa0/0x140 napipoll+0x2c/0x170 netrxaction+0x2c4/0x3a0 handlesoftirqs+0xd0/0x270 dosoftirq+0x3f/0x60

Fix this by replacing ISENABLED(IPV6) call with ipv6modenabled() in the callers. This is in essence disabling NS/NA suppression when IPv6 is disabled.

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

net/sched: actife: Fix metalist update behavior

Whenever an ife action replace changes the metalist, instead of replacing the old data on the metalist, the current ife code is appending the new metadata. Aside from being innapropriate behavior, this may lead to an unbounded addition of metadata to the metalist which might cause an out of bounds error when running the encode op:

[ 138.423369][ C1] ================================================================== [ 138.424317][ C1] BUG: KASAN: slab-out-of-bounds in ifetlvmetaencode (net/ife/ife.c:168) [ 138.424906][ C1] Write of size 4 at addr ffff8880077f4ffe by task ifeoutoutbou/255 [ 138.425778][ C1] CPU: 1 UID: 0 PID: 255 Comm: ifeoutoutbou Not tainted 7.0.0-rc1-00169-gfbdfa8da05b6 #624 PREEMPT(full) [ 138.425795][ C1] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 138.425800][ C1] Call Trace: [ 138.425804][ C1] <IRQ> [ 138.425808][ C1] dumpstacklvl (lib/dumpstack.c:122) [ 138.425828][ C1] printreport (mm/kasan/report.c:379 mm/kasan/report.c:482) [ 138.425839][ C1] ? srsoaliasreturnthunk (arch/x86/lib/retpoline.S:221) [ 138.425844][ C1] ? virtaddrvalid (./arch/x86/include/asm/preempt.h:95 (discriminator 1) ./include/linux/rcupdate.h:975 (discriminator 1) ./include/linux/mmzone.h:2207 (discriminator 1) arch/x86/mm/physaddr.c:54 (discriminator 1)) [ 138.425853][ C1] ? ifetlvmetaencode (net/ife/ife.c:168) [ 138.425859][ C1] kasanreport (mm/kasan/report.c:221 mm/kasan/report.c:597) [ 138.425868][ C1] ? ifetlvmetaencode (net/ife/ife.c:168) [ 138.425878][ C1] kasancheckrange (mm/kasan/generic.c:186 (discriminator 1) mm/kasan/generic.c:200 (discriminator 1)) [ 138.425884][ C1] asanmemset (mm/kasan/shadow.c:84 (discriminator 2)) [ 138.425889][ C1] ifetlvmetaencode (net/ife/ife.c:168) [ 138.425893][ C1] ? ifetlvmetaencode (net/ife/ife.c:171) [ 138.425898][ C1] ? srsoaliasreturnthunk (arch/x86/lib/retpoline.S:221) [ 138.425903][ C1] ifeencodemetau16 (net/sched/actife.c:57) [ 138.425910][ C1] ? pfxdorawspinlock (kernel/locking/spinlockdebug.c:114) [ 138.425916][ C1] ? asanmemcpy (mm/kasan/shadow.c:105 (discriminator 3)) [ 138.425921][ C1] ? pfxifeencodemetau16 (net/sched/actife.c:45) [ 138.425927][ C1] ? srsoaliasreturnthunk (arch/x86/lib/retpoline.S:221) [ 138.425931][ C1] tcfifeact (net/sched/actife.c:847 net/sched/actife.c:879)

To solve this issue, fix the replace behavior by adding the metalist to the ife rcu data structure.

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:

ipv6: Fix soft lockups in fib6selectpath under high next hop churn

Soft lockups have been observed on a cluster of Linux-based edge routers located in a highly dynamic environment. Using the bird service, these routers continuously update BGP-advertised routes due to frequently changing nexthop destinations, while also managing significant IPv6 traffic. The lockups occur during the traversal of the multipath circular linked-list in the fib6selectpath function, particularly while iterating through the siblings in the list. The issue typically arises when the nodes of the linked list are unexpectedly deleted concurrently on a different core—indicated by their 'next' and 'previous' elements pointing back to the node itself and their reference count dropping to zero. This results in an infinite loop, leading to a soft lockup that triggers a system panic via the watchdog timer.

Apply RCU primitives in the problematic code sections to resolve the issue. Where necessary, update the references to fib6siblings to annotate or use the RCU APIs.

Include a test script that reproduces the issue. The script periodically updates the routing table while generating a heavy load of outgoing IPv6 traffic through multiple iperf3 clients. It consistently induces infinite soft lockups within a couple of minutes.

Kernel log:

0 [ffffbd13003e8d30] machinekexec at ffffffff8ceaf3eb 1 [ffffbd13003e8d90] crashkexec at ffffffff8d0120e3 2 [ffffbd13003e8e58] panic at ffffffff8cef65d4 3 [ffffbd13003e8ed8] watchdogtimerfn at ffffffff8d05cb03 4 [ffffbd13003e8f08] hrtimerrunqueues at ffffffff8cfec62f 5 [ffffbd13003e8f70] hrtimerinterrupt at ffffffff8cfed756 6 [ffffbd13003e8fd0] sysvecapictimerinterrupt at ffffffff8cea01af 7 [ffffbd13003e8ff0] sysvecapictimerinterrupt at ffffffff8df1b83d -- <IRQ stack> -- 8 [ffffbd13003d3708] asmsysvecapictimerinterrupt at ffffffff8e000ecb [exception RIP: fib6selectpath+299] RIP: ffffffff8ddafe7b RSP: ffffbd13003d37b8 RFLAGS: 00000287 RAX: ffff975850b43600 RBX: ffff975850b40200 RCX: 0000000000000000 RDX: 000000003fffffff RSI: 0000000051d383e4 RDI: ffff975850b43618 RBP: ffffbd13003d3800 R8: 0000000000000000 R9: ffff975850b40200 R10: 0000000000000000 R11: 0000000000000000 R12: ffffbd13003d3830 R13: ffff975850b436a8 R14: ffff975850b43600 R15: 0000000000000007 ORIGRAX: ffffffffffffffff CS: 0010 SS: 0018 9 [ffffbd13003d3808] ip6polroute at ffffffff8ddb030c 10 [ffffbd13003d3888] ip6polrouteinput at ffffffff8ddb068c 11 [ffffbd13003d3898] fib6rulelookup at ffffffff8ddf02b5 12 [ffffbd13003d3928] ip6routeinput at ffffffff8ddb0f47 13 [ffffbd13003d3a18] ip6rcvfinishcore.constprop.0 at ffffffff8dd950d0 14 [ffffbd13003d3a30] ip6listrcvfinish.constprop.0 at ffffffff8dd96274 15 [ffffbd13003d3a98] ip6sublistrcv at ffffffff8dd96474 16 [ffffbd13003d3af8] ipv6listrcv at ffffffff8dd96615 17 [ffffbd13003d3b60] netifreceiveskblistcore at ffffffff8dc16fec 18 [ffffbd13003d3be0] netifreceiveskblistinternal at ffffffff8dc176b3 19 [ffffbd13003d3c50] napigroreceive at ffffffff8dc565b9 20 [ffffbd13003d3c80] icereceiveskb at ffffffffc087e4f5 [ice] 21 [ffffbd13003d3c90] icecleanrxirq at ffffffffc0881b80 [ice] 22 [ffffbd13003d3d20] icenapipoll at ffffffffc088232f [ice] 23 [ffffbd13003d3d80] napipoll at ffffffff8dc18000 24 [ffffbd13003d3db8] netrxaction at ffffffff8dc18581 25 [ffffbd13003d3e40] dosoftirq at ffffffff8df352e9 26 [ffffbd13003d3eb0] runksoftirqd at ffffffff8ceffe47 27 [ffffbd13003d3ec0] smpbootthreadfn at ffffffff8cf36a30 28 [ffffbd13003d3ee8] kthread at ffffffff8cf2b39f 29 [ffffbd13003d3f28] retfromfork at ffffffff8ce5fa64 30 [ffffbd13003d3f50] retfromforkasm at ffffffff8ce03cbb

drm/amd/display: Do not set DRR on pipe Commit

drm/amd/display: Fix out-of-bound accesses

A heap buffer overflow flaw was found in IPsec ESP transformation code in net/ipv4/esp4.c and net/ipv6/esp6.c. This flaw allows a local attacker with a normal user privilege to overwrite kernel heap objects and may cause a local privilege escalation threat.

Last updated 25 April 2025

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

KVM: SVM: Don't BUG if userspace injects an interrupt with GIF=0

Don't BUG/WARN on interrupt injection due to GIF being cleared, since it's trivial for userspace to force the situation via KVMSETVCPUEVENTS (even if having at least a WARN there would be correct for KVM internally generated injections).

kernel BUG at arch/x86/kvm/svm/svm.c:3386! invalid opcode: 0000 [#1] SMP CPU: 15 PID: 926 Comm: smmtest Not tainted 5.17.0-rc3+ #264 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:svminjectirq+0xab/0xb0 [kvmamd] Code: <0f> 0b 0f 1f 00 0f 1f 44 00 00 80 3d ac b3 01 00 00 55 48 89 f5 53 RSP: 0018:ffffc90000b37d88 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88810a234ac0 RCX: 0000000000000006 RDX: 0000000000000000 RSI: ffffc90000b37df7 RDI: ffff88810a234ac0 RBP: ffffc90000b37df7 R08: ffff88810a1fa410 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888109571000 R14: ffff88810a234ac0 R15: 0000000000000000 FS: 0000000001821380(0000) GS:ffff88846fdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f74fc550008 CR3: 000000010a6fe000 CR4: 0000000000350ea0 Call Trace: <TASK> injectpendingevent+0x2f7/0x4c0 [kvm] kvmarchvcpuioctlrun+0x791/0x17a0 [kvm] kvmvcpuioctl+0x26d/0x650 [kvm] x64sysioctl+0x82/0xb0 dosyscall64+0x3b/0xc0 entrySYSCALL64afterhwframe+0x44/0xae </TASK>

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

wifi: mwifiex: Fix OOB and integer underflow when rx packets

Make sure mwifiexprocessmgmtpacket, mwifiexprocessstarxpacket and mwifiexprocessuaprxpacket, mwifiexuapqueuebridgedpkt and mwifiexprocessrxpacket not out-of-bounds access the skb->data buffer.

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

Bluetooth: L2CAP: fix "bad unlock balance" in l2capdisconnectrsp

conn->chanlock isn't acquired before l2capgetchanbyscid, if l2capgetchanbyscid returns NULL, then 'bad unlock balance' is triggered.

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

Bluetooth: L2CAP: Fix use-after-free

Fix potential use-after-free in l2caplecommandrej.