On Fri, Feb 17, 2023 at 11:20:06PM +0100, Florian Westphal wrote: > 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. Applied, thanks
