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
