netdev - Re: [PATCH nf] netfilter: ebtables: compat: reject all padding in matches/watchers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20191220011124.addyezhijttukqw5@salvia>
Date:   Fri, 20 Dec 2019 02:11:24 +0100
From:   Pablo Neira Ayuso <pablo@...filter.org>
To:     Florian Westphal <fw@...len.de>
Cc:     netfilter-devel@...r.kernel.org, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org,
        syzbot+f68108fed972453a0ad4@...kaller.appspotmail.com,
        syzkaller-bugs@...glegroups.com
Subject: Re: [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.