lkml.org 
[lkml]   [2019]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH nf] netfilter: ebtables: compat: reject all padding in matches/watchers
On Sun, Dec 15, 2019 at 03:49:25AM +0100, Florian Westphal wrote:
> syzbot reported following splat:
>
> BUG: KASAN: vmalloc-out-of-bounds in size_entry_mwt net/bridge/netfilter/ebtables.c:2063 [inline]
> BUG: KASAN: vmalloc-out-of-bounds in compat_copy_entries+0x128b/0x1380 net/bridge/netfilter/ebtables.c:2155
> Read of size 4 at addr ffffc900004461f4 by task syz-executor267/7937
>
> CPU: 1 PID: 7937 Comm: syz-executor267 Not tainted 5.5.0-rc1-syzkaller #0
> size_entry_mwt net/bridge/netfilter/ebtables.c:2063 [inline]
> compat_copy_entries+0x128b/0x1380 net/bridge/netfilter/ebtables.c:2155
> compat_do_replace+0x344/0x720 net/bridge/netfilter/ebtables.c:2249
> compat_do_ebt_set_ctl+0x22f/0x27e net/bridge/netfilter/ebtables.c:2333
> [..]
>
> Because padding isn't considered during computation of ->buf_user_offset,
> "total" is decremented by fewer bytes than it should.
>
> Therefore, the first part of
>
> if (*total < sizeof(*entry) || entry->next_offset < sizeof(*entry))
>
> will pass, -- it should not have. This causes oob access:
> entry->next_offset is past the vmalloced size.
>
> Reject padding and check that computed user offset (sum of ebt_entry
> structure plus all individual matches/watchers/targets) is same
> value that userspace gave us as the offset of the next entry.

Applied, thanks.

\
 
 \ /
  Last update: 2019-12-20 02:11    [W:0.052 / U:1.472 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site