[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.LRH.2.11.1504150955110.14302@namei.org>
Date: Wed, 15 Apr 2015 09:55:24 +1000 (AEST)
From: James Morris <jmorris@...ei.org>
To: Richard Guy Briggs <rgb@...hat.com>
cc: linux-security-module@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-audit@...hat.com,
sgrubb@...hat.com, eparis@...isplace.org, pmoore@...hat.com,
penguin-kernel@...ove.SAKURA.ne.jp
Subject: Re: [PATCH] lsm: copy comm before calling audit_log to avoid race
in string printing
On Tue, 14 Apr 2015, Richard Guy Briggs wrote:
> When task->comm is passed directly to audit_log_untrustedstring() without
> getting a copy or using the task_lock, there is a race that could happen that
> would output a NULL (\0) in the middle of the output string that would
> effectively truncate the rest of the report text after the comm= field in the
> audit log message, losing fields.
>
> Using get_task_comm() to get a copy while acquiring the task_lock to prevent
> this and to prevent the result from being a mixture of old and new values of
> comm would incur potentially unacceptable overhead, considering that the value
> can be influenced by userspace and therefore untrusted anyways.
>
> Copy the value before passing it to audit_log_untrustedstring() ensures that a
> local copy is used to calculate the length *and* subsequently printed. Even if
> this value contains a mix of old and new values, it will only calculate and
> copy up to the first NULL, preventing the rest of the audit log message being
> truncated.
>
> Use a second local copy of comm to avoid a race between the first and second
> calls to audit_log_untrustedstring() with comm.
>
> Reported-by: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
> Signed-off-by: Richard Guy Briggs <rgb@...hat.com>
Applied.
--
James Morris
<jmorris@...ei.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists