On 2016-06-21 10:37, Pengfei Wang wrote:
> 在 2016年6月20日,下午8:18,Oleg Nesterov <oleg(a)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(a)redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635