lkml.org 
[lkml]   [2018]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: usercopy whitelist woe in scsi_sense_cache
On Tue, Apr 17, 2018 at 3:02 AM, James Bottomley
<jejb@linux.vnet.ibm.com> wrote:
> On Mon, 2018-04-16 at 20:12 -0700, Kees Cook wrote:
>> I still haven't figured this out, though... any have a moment to look
>> at this?
>
> Just to let you know you're not alone ... but I can't make any sense of
> this either. The bfdq is the elevator_data, which is initialised when
> the scheduler is attached, so it shouldn't change. Is it possible to
> set a data break point on elevator_data after it's initialised and see
> if it got changed by something?

Yeah, it seems like some pointer chain is getting overwritten outside
of a lock or rcu or ?. I don't know this code well enough to guess at
where to check, though. What I find so strange is that the structure
offsets are different between bfpd's rq_in_driver field and
scsi_request's sense field, so even THAT doesn't look to be clear-cut
either:

struct bfq_data {
struct request_queue * queue; /* 0 8 */
struct list_head dispatch; /* 8 16 */
struct bfq_group * root_group; /* 24 8 */
struct rb_root queue_weights_tree; /* 32 8 */
struct rb_root group_weights_tree; /* 40 8 */
int busy_queues; /* 48 4 */
int wr_busy_queues; /* 52 4 */
int queued; /* 56 4 */
int rq_in_driver; /* 60 4 */
...

struct scsi_request {
unsigned char __cmd[16]; /* 0 16 */
unsigned char * cmd; /* 16 8 */
short unsigned int cmd_len; /* 24 2 */

/* XXX 2 bytes hole, try to pack */

int result; /* 28 4 */
unsigned int sense_len; /* 32 4 */
unsigned int resid_len; /* 36 4 */
int retries; /* 40 4 */

/* XXX 4 bytes hole, try to pack */

void * sense; /* 48 8 */
...

This is _so_ weird. :P

-Kees

--
Kees Cook
Pixel Security

\
 
 \ /
  Last update: 2018-04-17 18:32    [W:0.167 / U:35.724 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site