Re: [RFC PATCH] iov: Bypass usercopy hardening for kernel iterators

["Chuck Lever" <cel@kernel.org>]

On Tue, Mar 3, 2026, at 1:00 PM, Matthew Wilcox wrote:
> On Tue, Mar 03, 2026 at 11:29:32AM -0500, Chuck Lever wrote:
>> Profiling NFSD under an iozone workload showed that hardened
>> usercopy checks consume roughly 1.3% of CPU in the TCP receive
>> path. The runtime check in check_object_size() validates that
>> copy buffers reside in expected slab regions, which is
>> meaningful when data crosses the user/kernel boundary but adds
>> no value when both source and destination are kernel addresses.
>
> I'm not sure I'd go as far as "no value".  I could see an attack which
> managed to trick the kernel into copying past the end of a slab object
> and sending the contents of that buffer across the network to an attacker.
>
> Or I guess in this case you're talking about copying _to_ a slab object.
> Then we could see a network attacker somewhow confusing the kernel into
> copying past the end of the object they allocated, overwriting slab
> metadata and/or the contents of the next object in the slab.
>
> Limited value, sure.  And the performance change you're showing here
> certainly isn't nothing!

To be clear, I'm absolutely interested in not degrading our security
posture. But NFSD (and other storage ULPs, for example) do a lot of
internal data copying that could be more efficient.

I would place the "trick the kernel into copying past the end of
a slab object" attack in the category of "you should sanitize your
input better"... Perhaps the existing copy_to_iter protection is
a general salve that could be replaced by something more narrow
and less costly. </hand wave>

-- 
Chuck Lever