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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 13 May 2017 13:52:29 -0700 From: Linus Torvalds <torvalds@...ux-foundation.org> To: Al Viro <viro@...iv.linux.org.uk> Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org> Subject: Re: [git pull] uaccess-related bits of vfs.git On Sat, May 13, 2017 at 1:37 PM, Al Viro <viro@...iv.linux.org.uk> wrote: > > That's a valid point and it might apply to memdup_user() callers out there. > Potential variants: > * add an explicit upper bound on the size and turn that into > memdup_user() (and check that all memdup_user() callers are bounded). > * have memdup_user() itself pass __GFP_NOWARN. > * add kvmemdup_user() that would use kvmalloc() (with its callers > expected to use kvfree()); see who else might benefit from conversion. All of the above sound reasonable. I wouldn't change the existing "memdup_user()" interface itself, but if there really are users that can validly pass in a maxbyte value, why not add a new helper: void *memdup_user_limit(userptr, nmember, nsize, maxsize); and then have #define memdup_user(ptr,size) memdup_user_limit(ptr, size, 1, -1) or something. I definitely see a couple of memdup_user() people who do that "num*size" multiplication by hand, and it's very easy to get wrong and have an overflow. And for a kvmalloc/kvfree() interface, you *definitely* want that maxsize thing, since it absolutely needs an upper limit. Linus
Powered by blists - more mailing lists