Look up another CVE · open CVE-2026-53248 in the interactive tracker
CVE-2026-53248
net: airoha: Fix use-after-free in metadata dst teardown
Published 2026-06-25 (4 months ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-53248 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.0.13-1 | Update the kernel and reboot. Fixed in 7.0.13-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.13-1 | Update the kernel and reboot. Fixed in 7.0.13-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
airoha_metadata_dst_free() runs metadata_dst_free() which frees the metadata_dst with kfree() immediately, bypassing the RCU grace period. In the RX path, skb_dst_set_noref() sets a non-refcounted pointer from the skb to the metadata_dst. This function requires RCU read-side protection and the dst must remain valid until all RCU readers complete. Since metadata_dst_free() calls kfree() directly, an use-after-free can occur if any skb still holds a noref pointer to the dst when the driver tears it down. Replace metadata_dst_free() with dst_release() which properly goes through the refcount path: when the refcount drops to zero, it schedules the actual free via call_rcu_hurry(), ensuring all RCU readers have completed before the memory is freed.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/net/ethernet/airoha/airoha_eth.c
- What this is
- AIROHA ETHERNET DRIVERMAINTAINERS section matched on drivers/net/ethernet/airoha/ · linux-arm-kernel@lists.infradead.org · Maintained
Check it on the machine
grep -wE 'CONFIG_ETHERNET|CONFIG_NET_AIROHA|CONFIG_NET_VENDOR_AIROHA' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian does not build this code in 3 releases. The build rule could not be established for 1 release, so nothing is claimed about those.
- bookworm?
- trixie, forky, sidn
- ?
- not established - no Makefile entry for the affected file
- n
- not enabled on any flavour - this release does not build the code
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
- Build switches
- CONFIG_ETHERNET, CONFIG_NET_AIROHA, CONFIG_NET_VENDOR_AIROHA
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-06-25 (4 months ago)source
- CVSS
- 8.8 high
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.35%, higher than 27.4% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/net
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.15 | 6.18.36 | 6f829e2c17a5 |
| 6.15 | 7.0.13 | 4b5a574e033e |
| 6.15 | 7.1 | b38cae85d1c4 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:NAttack vector, network
- An unauthenticated network peer can feed packets into the Airoha Ethernet RX path, where `skb_dst_set_noref()` attaches the metadata_dst used by DSA. In router/embedded deployments this RX path can be exposed on network-facing Ethernet ports.
- AC:LAttack complexity, low
- The bug is a straightforward lifetime violation: attacker-supplied traffic can keep SKBs carrying the noref dst while teardown frees the object without an RCU grace period. Per the UAF guidance, no special hard-to-control condition is required beyond arranging traffic around teardown.
- PR:NPrivileges required, none
- The attacker does not need local credentials to supply the RX packets that hold the stale metadata pointer. The privileged driver teardown is treated as victim/system interaction rather than attacker-held privileges.
- UI:RUser interaction, required
- Exploitation requires the device/driver to be torn down, such as by platform-driver unbind or module unload, while attacker-fed SKBs still reference the metadata_dst. That teardown is not triggered by normal packets alone.
- S:UScope, unchanged
- The vulnerability corrupts kernel networking state within the same kernel security authority. It does not cross a VM, IOMMU, or separate security-scope boundary.
- C:HConfidentiality impact, high
- This is a kernel use-after-free of a heap-allocated metadata_dst reachable from packet processing. Following the UAF scoring rule, freed-object reuse can enable kernel memory disclosure.
- I:HIntegrity impact, high
- Kernel UAFs can be leveraged through heap reuse and spraying into broader memory corruption or control-flow manipulation. The fix changes lifetime management to RCU-delayed `dst_release()`, confirming the stale pointer risk.
- A:HAvailability impact, high
- A stale dst pointer can be dereferenced during DSA receive processing after the object was freed. This can cause kernel oops/panic or network stack failure.