CVE-2026-53134
Linux kernel: information disclosure
- Risk score
- 48/100
- CVSS
- 5.5 v3.1
- Exploit chance (30 days)
- 0.1%
- Published
- 25 Jun 2026
Open in the live forecast Today's forecast
What to know
- What it is
- In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: fix stale stack leak via the OIFNAME register For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval()…
- Affected
- Linux kernel
- Fix
- Apply the vendor's security update; see the linked advisory.
- Exploitation
- No known exploitation
Story map
At a glance
Linux kernel: Amber, patch this week. In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: restore network header before routing and forwarding ipv6_srh_rcv() runs with skb->data at the Segment Routing Header (SRH) while skb_network_header() points at the IPv6 header. When segments_left > 0, ipv6_srh_rcv() previously restored the …
The flaws
- CVE-2026-53134: Information disclosure (CVSS 5.5 · EPSS 0%)
- CVE-2026-98096: Out-of-bounds write (CVSS 7.4 · EPSS 1%)
- CVE-2026-98115: Race condition (CVSS 8.8 · EPSS 0%)
- CVE-2026-98117: Use-after-free (CVSS 7.8 · EPSS 0%)
The fix
Fix: Apply the vendor's security update; see the linked advisory.
Who is exposed: Linux kernel
Where it stands
- No known exploitation
How it unfolded
- 6 Nov, Ubuntu security notices (official): USN-9002-1: Linux kernel (NVIDIA Tegra) vulnerabilities
Connects to
- Same weakness: CWE-401 (CWE-401). 43 other warnings in 30 days
- Same product: Earlier Linux kernel warnings. 156 in the last 90 days
Why it is Yellow
- CVSS 5.5 medium
- On your watchlist: linux kernel
- Named in a government or vendor bulletin
Government and vendor bulletins
References
- https://ubuntu.com/security/notices/USN-9002-1
- https://git.kernel.org/stable/c/3544210609f6d1db282bbdeca639104ef624c393
- https://git.kernel.org/stable/c/6744e49fe51bfba26522acc2d0e9703cb41d8e50
- https://git.kernel.org/stable/c/84d8f58cf28a0415413f43ba7148f7bacd4c1b6e
- https://git.kernel.org/stable/c/8c84885e9790823828bb8084736ea15769b1ac16
- https://git.kernel.org/stable/c/ab185e0c4fb82dfba6fb86f8271e06f931d9c64c
- https://git.kernel.org/stable/c/d19ddef8c327a4773ff81f8e51027d1e0b4cf069
- https://git.kernel.org/stable/c/eb8a8124484dbc3c2b543e207da39bbccb703d31
- https://git.kernel.org/stable/c/eca18feed38b3377a2ec5d1f22af1170c55d0171
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
Original description
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: fix stale stack leak via the OIFNAME register For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one register via "*dest = 0". The remaining three registers are left as whatever was on the stack in nft_do_chain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace. The NFTA_FIB_F_PRESENT existence check has the same shape: it is only meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type while the eval stores a single byte via nft_reg_store8(), leaving the rest of the declared span stale. Fix both: - replace the bare "*dest = 0" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.
Last activity 6 Nov 2026. Patch Forecast updates every hour.