[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200814095943.GC5816@salvia>
Date: Fri, 14 Aug 2020 11:59:43 +0200
From: Pablo Neira Ayuso <pablo@...filter.org>
To: Florian Westphal <fw@...len.de>
Cc: netfilter-devel@...r.kernel.org, hch@....de,
syzkaller-bugs@...glegroups.com, netdev@...r.kernel.org,
syzbot+5accb5c62faa1d346480@...kaller.appspotmail.com
Subject: Re: [PATCH nf] netfilter/ebtables: reject bogus getopt len value
On Thu, Aug 13, 2020 at 09:46:11AM +0200, Florian Westphal wrote:
> syzkaller reports splat:
> ------------[ cut here ]------------
> Buffer overflow detected (80 < 137)!
> Call Trace:
> do_ebt_get_ctl+0x2b4/0x790 net/bridge/netfilter/ebtables.c:2317
> nf_getsockopt+0x72/0xd0 net/netfilter/nf_sockopt.c:116
> ip_getsockopt net/ipv4/ip_sockglue.c:1778 [inline]
>
> caused by a copy-to-user with a too-large "*len" value.
> This adds a argument check on *len just like in the non-compat version
> of the handler.
>
> Before the "Fixes" commit, the reproducer fails with -EINVAL as
> expected:
> 1. core calls the "compat" getsockopt version
> 2. compat getsockopt version detects the *len value is possibly
> in 64-bit layout (*len != compat_len)
> 3. compat getsockopt version delegates everything to native getsockopt
> version
> 4. native getsockopt rejects invalid *len
>
> -> compat handler only sees len == sizeof(compat_struct) for GET_ENTRIES.
>
> After the refactor, event sequence is:
> 1. getsockopt calls "compat" version (len != native_len)
> 2. compat version attempts to copy *len bytes, where *len is random
> value from userspace
Applied, thanks.
Powered by blists - more mailing lists