Files
linux/include/linux
Florian Westphal 7997eff828 netfilter: ebtables: reject blobs that don't provide all entry points
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>
2022-08-23 18:23:15 +02:00
..
2022-04-20 12:59:50 +05:30
2022-05-22 20:44:29 +01:00
2022-03-23 19:58:38 +01:00
2022-06-30 13:40:35 +01:00
2022-02-01 14:25:50 +02:00
2022-07-05 20:25:39 +02:00
2022-01-22 08:33:34 +02:00
2022-07-14 12:14:30 -06:00
2022-07-14 12:14:30 -06:00
2022-06-29 13:21:51 -07:00
2022-04-22 12:32:03 +02:00
2022-03-15 10:32:44 +01:00
2021-12-10 17:10:55 -08:00
2022-06-28 10:37:25 -03:00
2021-12-10 12:51:28 +01:00
2022-07-01 14:53:01 +02:00
2022-06-03 06:52:57 -07:00
2022-01-20 08:52:54 +02:00
2022-06-09 21:53:09 -07:00
2022-06-09 21:53:12 -07:00
2022-06-09 21:53:09 -07:00
2022-02-28 23:26:27 -08:00
2022-06-27 06:29:12 -06:00
2022-06-29 17:42:28 -07:00
2022-07-17 17:31:38 -07:00
2022-05-02 14:06:20 -06:00
2022-01-27 13:53:26 +00:00
2022-05-03 16:09:03 -04:00
2022-06-19 10:38:26 +01:00
2022-07-27 14:04:52 +02:00
2022-04-28 23:16:14 -07:00
2022-07-29 18:07:19 -07:00
2022-08-02 12:34:04 -04:00
2021-12-16 22:22:20 +01:00
2022-04-28 16:31:10 +02:00
2022-05-17 13:32:46 -04:00
2022-08-09 14:11:34 -04:00
2022-07-29 20:16:58 -04:00
2022-02-09 09:24:40 -05:00
2022-01-12 10:14:09 -06:00
2022-07-01 16:38:35 -06:00
2022-02-02 07:49:59 -07:00
2022-02-09 08:04:44 +01:00
2022-02-09 08:04:44 +01:00
2022-01-22 08:33:37 +02:00
2022-01-08 12:43:57 -06:00
2022-01-24 14:45:02 +01:00
2022-03-08 14:33:36 -06:00
2022-03-17 20:16:29 -07:00
2022-03-23 19:58:41 +01:00
2022-05-22 21:03:01 +01:00
2022-04-07 12:53:54 +02:00
2022-06-27 14:41:31 +02:00
2022-02-24 15:04:51 +00:00
2022-05-08 01:33:08 -07:00
2022-02-25 09:36:06 +01:00
2022-04-11 19:18:27 -06:00
2022-03-22 15:57:11 -07:00
2021-11-25 18:35:23 +01:00
2022-01-27 13:53:27 +00:00
2022-08-08 22:37:24 -04:00
2022-08-11 04:31:14 -04:00
2022-06-13 09:54:52 -07:00
2022-07-10 21:17:30 -04:00