lkml.org 
[lkml]   [2018]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: usercopy whitelist woe in scsi_sense_cache
Hi.

04.04.2018 23:25, Kees Cook wrote:
>> Actually, I can trigger a BUG too:
>>
>> [ 129.259213] usercopy: Kernel memory exposure attempt detected from
>> SLUB
>> object 'scsi_sense_cache' (offset 119, size 22)!
>
> Wow, yeah, that's totally outside the slub object_size. How did you
> trigger this? Just luck or something specific?

Just luck, I suppose. It usually comes after the first warning if you
wait long enough (maybe, a couple of extra minutes).

To give you an idea regarding variety of offsets, I've summarised kernel
log from the server:

$ sudo journalctl -kb | grep "Kernel memory exposure attempt detected" |
grep -oE 'offset [0-9]+, size [0-9]+' | sort | uniq -c
9 offset 107, size 22
6 offset 108, size 22
8 offset 109, size 22
7 offset 110, size 22
5 offset 111, size 22
5 offset 112, size 22
2 offset 113, size 22
2 offset 114, size 22
1 offset 115, size 22
1 offset 116, size 22
1 offset 119, size 22
1 offset 85, size 22

> I'd really like to understand how the buffer position can be
> changing... I'd expect that to break all kinds of things (i.e.
> free()ing the slab later would break too...)

I haven't checked the code yet, but the first thing that comes to my
mind is some uninitialised variable. Just guessing here, though.

> Thanks for the report! I hope someone more familiar with sg_io() can
> help explain the changing buffer offset... :P

Hopefully, SCSI people are Cc'ed here properly…

Thanks!

Regards,
Oleksandr

\
 
 \ /
  Last update: 2018-04-04 23:35    [W:0.069 / U:2.488 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site