* Re: [PATCH] dm ioctl: prevent stack leak in dm ioctl call
[not found] <20170425233129.GA155598@google.com>
@ 2017-04-26 0:11 ` Alasdair G Kergon
[not found] ` <CAEP91RFJTRk7Ux3W=1TMfgjzF1cMc5jXF+om4Qchh8RDx84MtQ@mail.gmail.com>
0 siblings, 1 reply; 4+ messages in thread
From: Alasdair G Kergon @ 2017-04-26 0:11 UTC (permalink / raw)
To: Adrian Salido; +Cc: dm-devel, snitzer, agk
On Tue, Apr 25, 2017 at 04:31:29PM -0700, Adrian Salido wrote:
> Struct dm_ioctl has some padding/data that is not explicitly cleared
> before copying to user. This can cause kernel stack contents to be
> leaked to user space.
Please be more precise here, explaining which part of the buffer
and under exactly what circumstances you have found that uninitialised
content gets returned to userspace.
Alasdair
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] dm ioctl: prevent stack leak in dm ioctl call
[not found] ` <CAEP91RFJTRk7Ux3W=1TMfgjzF1cMc5jXF+om4Qchh8RDx84MtQ@mail.gmail.com>
@ 2017-04-26 0:42 ` Alasdair G Kergon
[not found] ` <CAEP91RG_9i80LpiGY+qSrcpcOt-F1ziUXAttSX2GUGFMsD8G6g@mail.gmail.com>
2017-04-27 15:43 ` Alasdair G Kergon
1 sibling, 1 reply; 4+ messages in thread
From: Alasdair G Kergon @ 2017-04-26 0:42 UTC (permalink / raw)
To: Adrian Salido; +Cc: dm-devel, snitzer, agk
On Tue, Apr 25, 2017 at 05:33:19PM -0700, Adrian Salido wrote:
> it's actually the data portion of the struct under a custom user ioctl
> where (param_kernel->data_size - minimum_data_size) <
> sizeof(param_kernel->data)
> Will update the patch to be clear
Yes - but before updating the patch, we need to be clearer about the
requirements of the ioctl here.
Why are two different minimum data sizes used?
If we let userspace send a truncated dm_ioctl struct, why are we not
returning the same truncated one?
Is this the bug?
param->data_size = sizeof(*param);
Alasdair
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] dm ioctl: prevent stack leak in dm ioctl call
[not found] ` <CAEP91RG_9i80LpiGY+qSrcpcOt-F1ziUXAttSX2GUGFMsD8G6g@mail.gmail.com>
@ 2017-04-26 1:06 ` Alasdair G Kergon
0 siblings, 0 replies; 4+ messages in thread
From: Alasdair G Kergon @ 2017-04-26 1:06 UTC (permalink / raw)
To: Adrian Salido; +Cc: dm-devel, snitzer, agk
On Tue, Apr 25, 2017 at 05:57:41PM -0700, Adrian Salido wrote:
> 1. param_kernel is allocated from stack and passed to copy_params
> 2. copy_params only copies up to param_kernel->data from user
> (param_kernel->data still contains stack contents)
> 3. in copy_params, since there are no params it will skip through and
> return param = dmi = param_kernel
after setting
dmi->data_size = minimum_data_size;
and then
input_param_size = param->data_size;
> 4. that stale data is copied back to user
because it is incorrectly extending the buffer?
param->data_size = sizeof(*param);
instead of continuing to use input_param_size?
Alasdair
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] dm ioctl: prevent stack leak in dm ioctl call
[not found] ` <CAEP91RFJTRk7Ux3W=1TMfgjzF1cMc5jXF+om4Qchh8RDx84MtQ@mail.gmail.com>
2017-04-26 0:42 ` Alasdair G Kergon
@ 2017-04-27 15:43 ` Alasdair G Kergon
1 sibling, 0 replies; 4+ messages in thread
From: Alasdair G Kergon @ 2017-04-27 15:43 UTC (permalink / raw)
To: Adrian Salido; +Cc: dm-devel, mpatocka, snitzer
On Tue, Apr 25, 2017 at 05:33:19PM -0700, Adrian Salido wrote:
> Will update the patch to be clear
So at the moment, we're leaning towards just:
param->data_size = offsetof(struct dm_ioctl, data)
to replace
param->data_size = sizeof(*param);
in the caller.
Alasdair
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-04-27 15:43 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20170425233129.GA155598@google.com>
2017-04-26 0:11 ` [PATCH] dm ioctl: prevent stack leak in dm ioctl call Alasdair G Kergon
[not found] ` <CAEP91RFJTRk7Ux3W=1TMfgjzF1cMc5jXF+om4Qchh8RDx84MtQ@mail.gmail.com>
2017-04-26 0:42 ` Alasdair G Kergon
[not found] ` <CAEP91RG_9i80LpiGY+qSrcpcOt-F1ziUXAttSX2GUGFMsD8G6g@mail.gmail.com>
2017-04-26 1:06 ` Alasdair G Kergon
2017-04-27 15:43 ` Alasdair G Kergon
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.