linux-kernel - RE: [PATCH 1/1] net: ioctl: Use kernel memory on protocol ioctl callbacks

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: <ab85b4420e93475dacd5e18017704b24@AcuMS.aculab.com>
Date:   Sat, 20 May 2023 13:02:57 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Willem de Bruijn' <willemdebruijn.kernel@...il.com>,
        Breno Leitao <leitao@...ian.org>
CC:     "axboe@...nel.dk" <axboe@...nel.dk>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "courmisch@...il.com" <courmisch@...il.com>,
        "nhorman@...driver.com" <nhorman@...driver.com>,
        "asml.silence@...il.com" <asml.silence@...il.com>,
        "alex.aring@...il.com" <alex.aring@...il.com>,
        "dccp@...r.kernel.org" <dccp@...r.kernel.org>,
        "mptcp@...ts.linux.dev" <mptcp@...ts.linux.dev>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "matthieu.baerts@...sares.net" <matthieu.baerts@...sares.net>,
        "marcelo.leitner@...il.com" <marcelo.leitner@...il.com>,
        "linux-wpan@...r.kernel.org" <linux-wpan@...r.kernel.org>,
        "linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>,
        "leit@...com" <leit@...com>,
        "dsahern@...nel.org" <dsahern@...nel.org>
Subject: RE: [PATCH 1/1] net: ioctl: Use kernel memory on protocol ioctl
 callbacks

From: Willem de Bruijn
> Sent: 19 May 2023 16:09
...
> Since that is a limited well understood list, I'm not in favor of the
> suggestion to add an explicit length argument that then needs to be
> checked in each callee.

While calls from userspace and direct calls from drivers can be
reasonably expected to have the required length buffer, I'm
not sure that is guaranteed for indirect calls via io_uring
and bpf.
In those cases the associated length is likely to come from
userspace and a suitably sized kernel buffer allocated.
So something needs to ensure the buffer is long enough
(and, indeed, not stupidly long).

Now you could require that the caller always supply a buffer
of at least (say) 64 bytes as well as the actual length.
Then only callee functions that have a long buffer need check.

An alternate option is to define a union of all the valid
argument types and require that any code making 'unknown'
requests supply a kernel buffer of that length.
(With due care taken to avoid overlong copies of uninitialised
kernel memory back to userspace.)

The same union would be useful as an upper bound for the
kernel buffer size - even if it is too large to always
allocate on stack.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)