linux-kernel - Re: [PATCH v3] net: netlink: af_netlink: Prevent empty skb by adding a check on len.

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: <20211129074730.277eebc3@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Mon, 29 Nov 2021 07:47:30 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Stephen Hemminger <stephen@...workplumber.org>
Cc:     Harshit Mogalapalli <harshit.m.mogalapalli@...cle.com>,
        ramanan.govindarajan@...cle.com, george.kennedy@...cle.com,
        vijayendra.suman@...cle.com,
        syzkaller <syzkaller@...glegroups.com>,
        "David S. Miller" <davem@...emloft.net>,
        Yajun Deng <yajun.deng@...ux.dev>,
        David Ahern <dsahern@...nel.org>,
        Florian Westphal <fw@...len.de>,
        Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
        Alexander Aring <aahringo@...hat.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Johannes Berg <johannes.berg@...el.com>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] net: netlink: af_netlink: Prevent empty skb by
 adding a check on len.

On Sat, 27 Nov 2021 09:28:41 -0800 Stephen Hemminger wrote:
> Are you sure no application is doing zero length send for some
> reason?
> Maybe doing the check in netlink_deliver_tap would be less likely
> to cause visible change in behavior to applications.

That's still a uAPI change, and leads to less obvious code.

I'd prefer to stick to the current patch which at least signals very
clearly that the functionality has been broken by returning an error 
to the caller, and we can rethink if anyone actually complains.

Maybe adding a pr_warn_once() to the case would save the hypothetical
user/developer some time, too?