netfilter: nft_fib: fix stale stack leak via the OIFNAME register
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.94, and 2 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
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.
Timeline
- CVE published
- Record last updated
Affected versions
- Linux Linux
From f6d0cbcf09c506b9b022df8f9d7693a7cec3c732 · fixed in 6744e49fe51bfba26522acc2d0e9703cb41d8e50; From f6d0cbcf09c506b9b022df8f9d7693a7cec3c732 · fixed in eca18feed38b3377a2ec5d1f22af1170c55d0171; From f6d0cbcf09c506b9b022df8f9d7693a7cec3c732 · fixed in d19ddef8c327a4773ff81f8e51027d1e0b4cf069; From f6d0cbcf09c506b9b022df8f9d7693a7cec3c732 · fixed in eb8a8124484dbc3c2b543e207da39bbccb703d31; From f6d0cbcf09c506b9b022df8f9d7693a7cec3c732 · fixed in 8c84885e9790823828bb8084736ea15769b1ac16; From f6d0cbcf09c506b9b022df8f9d7693a7cec3c732 · fixed in 84d8f58cf28a0415413f43ba7148f7bacd4c1b6e; From f6d0cbcf09c506b9b022df8f9d7693a7cec3c732 · fixed in 3544210609f6d1db282bbdeca639104ef624c393; From f6d0cbcf09c506b9b022df8f9d7693a7cec3c732 · fixed in ab185e0c4fb82dfba6fb86f8271e06f931d9c64c
- Linux Linux
4.10
- KernelLinux
From 4.10.0 · fixed in 5.10.259; From 5.11.0 · fixed in 5.15.210; From 5.16.0 · fixed in 6.1.176; From 6.2.0 · fixed in 6.6.143; From 6.7.0 · fixed in 6.12.94; From 6.13.0 · fixed in 6.18.36; From 6.19.0 · fixed in 7.0.13
References 8
git.kernel.org
- stable/c/6744e49fe51bfba26522acc2d0e9703cb41d8e50
- stable/c/eca18feed38b3377a2ec5d1f22af1170c55d0171
- stable/c/d19ddef8c327a4773ff81f8e51027d1e0b4cf069
- stable/c/eb8a8124484dbc3c2b543e207da39bbccb703d31
- stable/c/8c84885e9790823828bb8084736ea15769b1ac16
- stable/c/84d8f58cf28a0415413f43ba7148f7bacd4c1b6e
- stable/c/3544210609f6d1db282bbdeca639104ef624c393
- stable/c/ab185e0c4fb82dfba6fb86f8271e06f931d9c64c