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

[Ben Hutchings <ben@decadent.org.uk>]

[-- Attachment #1.1: Type: text/plain, Size: 1962 bytes --]

On Tue, 2016-06-21 at 10:37 +0100, Pengfei Wang wrote:
> > 
> > 在 2016年6月20日，下午8:18，Oleg Nesterov <oleg@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.
> 
> 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.

So far as userland can see, kernel log lines are separated by newlines.
If we fail to escape a newline, that makes it possible to inject
arbitrary log lines into the kernel log, which may be misleading to the
administrator or to software parsing the log.

Ben.

-- 
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had
thought.
... I realized that a large part of my life from then on was going to
be spent
in finding mistakes in my own programs. - Maurice Wilkes, 1949

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]