On Wed, Jun 28, 2017 at 09:44:13AM -0700, Kees Cook wrote: > On Mon, Jun 19, 2017 at 9:08 PM, Eric Biggers <ebiggers3@xxxxxxxxx> wrote: > > On Mon, Jun 19, 2017 at 04:36:31PM -0700, Kees Cook wrote: > >> From: David Windsor <dave@xxxxxxxxxxxx> > >> > >> When a dentry name is short enough, it can be stored directly in > >> the dentry itself. These dentry short names, stored in struct > >> dentry.d_iname and therefore contained in the dentry_cache slab cache, > >> need to be coped to/from userspace. > >> > >> In support of usercopy hardening, this patch defines a region in > >> the dentry_cache slab cache in which userspace copy operations > >> are allowed. > >> > >> This region is known as the slab cache's usercopy region. Slab > >> caches can now check that each copy operation involving cache-managed > >> memory falls entirely within the slab's usercopy region. > >> > >> This patch is modified from Brad Spengler/PaX Team's PAX_USERCOPY > >> whitelisting code in the last public patch of grsecurity/PaX based on my > >> understanding of the code. Changes or omissions from the original code are > >> mine and don't reflect the original grsecurity/PaX code. > >> > > > > For all these patches please mention *where* the data is being copied to/from > > userspace. > > Can you explain what you mean here? The field being copied is already > mentioned in the commit log; do you mean where in the kernel source > does the copy happen? > Yes, for the ones where it isn't obvious, mentioning a syscall or ioctl might be sufficient. Others may need more explanation. Eric -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
