summaryrefslogtreecommitdiff
path: root/kernel
diff options
context:
space:
mode:
authorFlorian Westphal <fw@strlen.de>2023-02-17 23:20:06 +0100
committerPablo Neira Ayuso <pablo@netfilter.org>2023-02-22 00:22:31 +0100
commite58a171d35e32e6e8c37cfe0e8a94406732a331f (patch)
tree36765ffc5190d73d9b1942b55cc225bb59cb2fb7 /kernel
parentefb056e5f1f0036179b2f92c1c15f5ea7a891d70 (diff)
netfilter: ebtables: fix table blob use-after-free
We are not allowed to return an error at this point. Looking at the code it looks like ret is always 0 at this point, but its not. t = find_table_lock(net, repl->name, &ret, &ebt_mutex); ... this can return a valid table, with ret != 0. This bug causes update of table->private with the new blob, but then frees the blob right away in the caller. Syzbot report: BUG: KASAN: vmalloc-out-of-bounds in __ebt_unregister_table+0xc00/0xcd0 net/bridge/netfilter/ebtables.c:1168 Read of size 4 at addr ffffc90005425000 by task kworker/u4:4/74 Workqueue: netns cleanup_net Call Trace: kasan_report+0xbf/0x1f0 mm/kasan/report.c:517 __ebt_unregister_table+0xc00/0xcd0 net/bridge/netfilter/ebtables.c:1168 ebt_unregister_table+0x35/0x40 net/bridge/netfilter/ebtables.c:1372 ops_exit_list+0xb0/0x170 net/core/net_namespace.c:169 cleanup_net+0x4ee/0xb10 net/core/net_namespace.c:613 ... ip(6)tables appears to be ok (ret should be 0 at this point) but make this more obvious. Fixes: c58dd2dd443c ("netfilter: Can't fail and free after table replacement") Reported-by: syzbot+f61594de72d6705aea03@syzkaller.appspotmail.com Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Diffstat (limited to 'kernel')
0 files changed, 0 insertions, 0 deletions