Report Double Fetch Bug Found in Linux-4.6.1/kernel/auditsc.c

[Richard Guy Briggs]

On 2016-06-21 10:37, Pengfei Wang wrote:
> 
> > 在 2016年6月20日，下午8:18，Oleg Nesterov <oleg at redhat.com> 写道：
> > 
> > Not that I understand this report, but
> > 
> > On 06/20, Richard Guy Briggs wrote:
> >> 
> >> This function is only ever called by __audit_free(), which is only ever
> >> called on failure of task creation or on exit of the task, so in neither
> >> case can anything else change it.
> > 
> > How so?
> > 
> > Another thread or CLONE_VM task or /proc/pid/mem can change the user-space
> > memory in parallel.
> > 
> > Oleg.
> 
> Exactly, by saying “change the data”, I mean the modification from
> malicious users with crafted operations on the user space memory
> directly, rather than the normal operations within the audit subsystem
> in Linux. Moreover, since the copy operations from the user space are
> not protected by any locks or synchronization primitives, changing the
> data under race condition is feasible I think. Besides, there isn’t
> any visible checking step in the code to guarantee the consistency
> between the two copy operations.

Ok, fair enough.  So if that is the case, then the iterative call to
copy_from_user() within each loop isn't safe either and needs a lock.

> Here I would like to figure out what the consequences really are once
> the data is changed between the two copy operations, such as changing
> a none-control string to a control string but process it as a
> none-control string that has no control chars. I think problems will
> happen.

If it is possible, I agree that it would cause problems.

So, next question, is each loop itself safe?

> Pengfei

- RGB

--
Richard Guy Briggs <rgb at redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635