On Nov 5, 2016 8:13 AM, "Kent Overstreet" <kent.overstreet@xxxxxxxxx> wrote: > > On Thu, Nov 03, 2016 at 03:03:01PM -0700, Eric Biggers wrote: > > With the new (in 4.9) option to use a virtually-mapped stack > > (CONFIG_VMAP_STACK), stack buffers cannot be used as input/output for > > the scatterlist crypto API because they may not be directly mappable to > > struct page. For short filenames, fname_encrypt() was encrypting a > > stack buffer holding the padded filename. Fix it by encrypting the > > filename in-place in the output buffer, thereby making the temporary > > buffer unnecessary. > > > > This bug could most easily be observed in a CONFIG_DEBUG_SG kernel > > because this allowed the BUG in sg_set_buf() to be triggered. > > > > Signed-off-by: Eric Biggers <ebiggers@xxxxxxxxxx> > > > - alloc_buf = kmalloc(ciphertext_len, GFP_NOFS); > > - if (!alloc_buf) > > - return -ENOMEM; > > - workbuf = alloc_buf; > > Vmalloc memory does have struct pages - you just need to use vmalloc_to_page() > instead of virt_to_page. Look at drivers/md/bcache/util.c bch_bio_map() if you > want an example. > > It would be better to just fix the sg code to handle vmalloc memory, instead of > adding a kmalloc() that can fail (and an error path that inevitably won't be > tested). Probably not, because (a) vmalloc_to_page is slow and (b) stack buffers can span physically noncontiguous pages. I think it's best to either avoid stack buffers or to teach crypto about kiov. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
