netdev - Re: [PATCH net] net: bridge: fix stale eth hdr pointer in br_dev

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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 24 Feb 2020 17:33:22 +0200
From:   Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
To:     netdev@...r.kernel.org
Cc:     davem@...emloft.net, roopa@...ulusnetworks.com,
        bridge@...ts.linux-foundation.org,
        syzbot+18c8b623c66fc198c493@...kaller.appspotmail.com
Subject: Re: [PATCH net] net: bridge: fix stale eth hdr pointer in br_dev_xmit

On 24/02/2020 15:07, Nikolay Aleksandrov wrote:
> In br_dev_xmit() we perform vlan filtering in br_allowed_ingress() but
> if the packet has the vlan header inside (e.g. bridge with disabled
> tx-vlan-offload) then the vlan filtering code will use skb_vlan_untag()
> to extract the vid before filtering which in turn calls pskb_may_pull()
> and we may end up with a stale eth pointer. Moreover the cached eth header
> pointer will generally be wrong after that operation. Remove the eth header
> caching and just use eth_hdr() directly, the compiler does the right thing
> and calculates it only once so we don't lose anything.
> 
> Reported-by: syzbot+18c8b623c66fc198c493@...kaller.appspotmail.com
> Fixes: 057658cb33fb ("bridge: suppress arp pkts on BR_NEIGH_SUPPRESS ports")
> Signed-off-by: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
> ---
>  net/bridge/br_device.c | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 

Funny but this might turn out to be a totally unrelated bug to the one reported by syzbot.
I just noticed it's saying uninit instead of use-after-free. I'm now building the
whole syz environment mentioned in the report to check it out.
That being said - the bug that I'm fixing here exists, we just might have to drop the
Reported-by: tag if it turns out the uninit bug is a different one. :)

I'll report back when I'm able to reproduce the syz uninit bug.