]> exis.tech > repos - linux.git/commit
netfilter: nft_fib: fix stale stack leak via the OIFNAME register
authorDavide Ornaghi <d.ornaghi97@gmail.com>
Wed, 10 Jun 2026 10:39:12 +0000 (12:39 +0200)
committerPablo Neira Ayuso <pablo@netfilter.org>
Wed, 10 Jun 2026 16:00:19 +0000 (18:00 +0200)
commitab185e0c4fb82dfba6fb86f8271e06f931d9c64c
treefe4753675107e422020c0706b4ef3453286bef14
parent772cecf198da732faebb5dcfc46d66a505be8495
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.

Fixes: f6d0cbcf09c5 ("netfilter: nf_tables: add fib expression")
Suggested-by: Florian Westphal <fw@strlen.de>
Cc: stable@vger.kernel.org
Signed-off-by: Davide Ornaghi <d.ornaghi97@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
net/ipv4/netfilter/nft_fib_ipv4.c
net/ipv6/netfilter/nft_fib_ipv6.c
net/netfilter/nft_fib.c