Messages in this thread | | | Date | Mon, 8 Jan 2018 12:57:20 -0200 | From | Marcelo Ricardo Leitner <> | Subject | Re: [RFC] memdup_user() and friends |
| |
On Sun, Jan 07, 2018 at 02:16:56AM +0000, Al Viro wrote: ... > > Everything else is definitely fine with GFP_USER - it's stuff like "copy of ioctl > arguments in an ioctl never issued by the kernel code, must have come straight from > ioctl(2)" and things like that. IMO we should simply switch memdup_user() to > GFP_USER and be done with that. Limiting the size ought to be done by callers and > IMO there's no point in __GFP_NOWARN there.
I don't really follow the __GFP_NOWARN part here. You mean that there is no point on using __GFP_NOWARN there?
I would think pretty much otherwise. There is no point in logging the trace as it is always a totally recoverable fault.
> > What I propose is > * switch memdup_user() to GFP_USER > * add vmemdup_user(), using kvmalloc() instead of kmalloc() (also with > GFP_USER) > * switch open-coded instances of the latter to calling it > * switch some of the memdup_user() callers to vmemdup_user() - the ones that > don't need physically contiguous copy and might be larger than a couple of pages. > * add apriori bounds on size in the call sites that do not have those yet - > that'll require comments from maintainers of the code in question in some cases. > > Objections?
None. Good timing, btw. I also got reports about such open size allocations and I'm finishing a patchset for SCTP to limit those. Will migrate sctp code to vmemdup_user() when available.
Thanks, Marcelo
| |