On 2016-06-21 10:37, Pengfei Wang wrote: > > > 在 2016年6月20日，下午8:18，Oleg Nesterov <[email protected]> 写道： > > > > 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 <[email protected]> Kernel Security Engineering, Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635 -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
