Files
linux/include/linux
Florian Westphal 160c4eb47d netfilter: ebtables: reject blobs that don't provide all entry points
[ Upstream commit 7997eff828 ]

Harshit Mogalapalli says:
 In ebt_do_table() function dereferencing 'private->hook_entry[hook]'
 can lead to NULL pointer dereference. [..] Kernel panic:

general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
[..]
RIP: 0010:ebt_do_table+0x1dc/0x1ce0
Code: 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 5c 16 00 00 48 b8 00 00 00 00 00 fc ff df 49 8b 6c df 08 48 8d 7d 2c 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 88
[..]
Call Trace:
 nf_hook_slow+0xb1/0x170
 __br_forward+0x289/0x730
 maybe_deliver+0x24b/0x380
 br_flood+0xc6/0x390
 br_dev_xmit+0xa2e/0x12c0

For some reason ebtables rejects blobs that provide entry points that are
not supported by the table, but what it should instead reject is the
opposite: blobs that DO NOT provide an entry point supported by the table.

t->valid_hooks is the bitmask of hooks (input, forward ...) that will see
packets.  Providing an entry point that is not support is harmless
(never called/used), but the inverse isn't: it results in a crash
because the ebtables traverser doesn't expect a NULL blob for a location
its receiving packets for.

Instead of fixing all the individual checks, do what iptables is doing and
reject all blobs that differ from the expected hooks.

Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Reported-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Reported-by: syzkaller <syzkaller@googlegroups.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-05 10:27:41 +02:00
..
2019-08-09 09:15:05 +02:00
2019-09-17 10:27:46 -07:00
2020-02-19 19:53:09 +01:00
2019-05-31 11:13:10 +02:00
2019-08-20 22:09:52 +02:00
2019-08-28 21:17:12 -06:00
2018-11-07 13:44:59 -07:00
2018-11-07 13:44:59 -07:00
2019-04-09 17:05:46 -07:00
2018-06-15 18:10:01 -03:00
2018-08-22 10:52:48 -07:00
2022-07-07 17:36:49 +02:00
2019-02-28 03:28:53 -05:00
2019-02-28 08:24:23 -07:00
2021-01-30 13:54:11 +01:00
2020-03-25 08:25:58 +01:00
2019-02-15 16:54:38 +01:00
2019-09-05 11:40:54 +02:00
2019-10-02 06:36:50 -07:00
2019-07-05 21:34:50 +02:00
2019-06-26 13:19:46 -07:00
2021-05-19 10:08:30 +02:00
2018-11-19 19:03:46 -07:00
2018-06-22 13:43:27 +09:00
2022-04-15 14:18:32 +02:00
2019-06-10 13:00:24 +02:00
2019-04-08 22:56:14 +02:00
2019-12-13 08:42:53 +01:00
2021-03-04 10:26:29 +01:00
2022-08-25 11:18:04 +02:00
2021-02-07 15:35:49 +01:00
2018-07-12 21:35:28 +02:00
2021-11-17 09:48:17 +01:00
2019-03-07 18:32:03 -08:00
2019-12-13 08:43:18 +01:00
2021-06-30 08:47:51 -04:00
2020-07-29 10:18:36 +02:00
2019-08-14 15:30:35 +02:00
2018-10-17 13:56:58 -07:00
2019-06-13 09:02:33 -04:00
2019-02-20 07:22:17 -07:00
2019-02-20 07:22:10 -07:00
2018-12-06 15:45:46 +01:00
2019-02-08 15:02:49 -08:00
2018-07-10 17:22:35 +02:00
2021-09-03 10:08:12 +02:00
2018-10-21 10:46:39 -04:00
2019-07-16 19:23:25 -07:00
2020-03-18 07:17:46 +01:00
2019-08-01 21:49:46 +02:00
2018-10-08 22:53:10 +11:00
2019-06-15 12:25:49 +02:00
2018-07-20 01:11:45 +02:00
2019-07-31 19:03:35 +02:00
2019-05-08 22:14:36 +02:00
2018-09-25 20:17:35 -07:00
2020-04-02 15:11:00 +02:00
2019-05-31 12:37:46 -07:00
2019-05-16 15:51:55 -07:00
2018-07-07 17:25:23 +02:00
2019-02-07 16:38:35 +01:00
2018-06-20 11:35:56 +02:00
2021-03-07 12:20:49 +01:00
2019-09-07 21:42:25 +02:00
2018-10-11 09:16:44 -07:00
2019-02-07 00:13:27 +01:00
2019-08-01 20:51:22 +02:00
2019-07-31 19:03:35 +02:00
2020-12-11 13:23:28 +01:00
2019-01-11 18:05:40 -08:00
2020-04-02 15:11:00 +02:00
2019-05-15 17:35:54 +01:00
2018-12-22 12:15:29 +01:00
2021-06-10 13:37:14 +02:00