Messages in this thread | | | Date | Wed, 04 Apr 2018 23:34:56 +0200 | From | Oleksandr Natalenko <> | Subject | Re: 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
| |