netdev - Re: [PATCH net-next] net: ncsi: check for netlink-driven responses before requiring a handler

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]

Message-ID: <20241103105414.75ddd6bd@kernel.org>
Date: Sun, 3 Nov 2024 10:54:14 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Jeremy Kerr <jk@...econstruct.com.au>
Cc: Samuel Mendoza-Jonas <sam@...dozajonas.com>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni
 <pabeni@...hat.com>, Simon Horman <horms@...nel.org>,
 netdev@...r.kernel.org
Subject: Re: [PATCH net-next] net: ncsi: check for netlink-driven responses
 before requiring a handler

On Mon, 28 Oct 2024 15:08:34 +0800 Jeremy Kerr wrote:
> Subject: [PATCH net-next] net: ncsi: check for netlink-driven responses before requiring a handler

> Currently, the NCSI response path will look up an opcode-specific
> handler for all incoming response messages. However, we may be receiving
> a response from a netlink-generated request, which may not have a
> corresponding in-kernel handler for that request opcode. In that case,
> we'll drop the response because we didn't find a opcode-specific
> handler.

This makes it sound like the code is written this way unintentionally,
which I doubt. A better description of the patch would be "allow
userspace to issue commands unknown to the kernel". And then it'd be
great to get some examples of commands you'd like to issue..

> Perform the lookup for the pending request (and hence for
> NETLINK_DRIVEN) before requiring an in-kernel handler, and defer the
> requirement for a corresponding kernel request until we know it's a
> kernel-driven command.

As for the code - delaying handling ret != 0 makes me worried that
someone will insert code in between and clobber it. Can you split
the handling so that all the ret != 0 (or EPERM for netlink)
are still handled in the if (ret) {} ?
-- 
pw-bot: cr