linux-kernel - Re: [Question] audit_names use after delete in audit_filter

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 22 Aug 2019 15:22:00 +0800
From:   Chen Wandun <chenwandun@...wei.com>
To:     Paul Moore <paul@...l-moore.com>
CC:     <linux-kernel@...r.kernel.org>, <linux-audit@...hat.com>,
        Eric Paris <eparis@...hat.com>,
        Kefeng Wang <wangkefeng.wang@...wei.com>
Subject: Re: [Question] audit_names use after delete in audit_filter_inodes



On 2019/8/21 23:36, Paul Moore wrote:
> On Wed, Aug 21, 2019 at 5:31 AM Chen Wandun <chenwandun@...wei.com> wrote:
>>
>> Hi,
>> Recently, I hit a use after delete in audit_filter_inodes,
> 
> ...
> 
>> the call stack is below:
>> [321315.077117] CPU: 6 PID: 8944 Comm: DefSch0100 Tainted: G           OE  ----V-------   3.10.0-327.62.59.83.w75.x86_64 #1
>> [321315.077117] Hardware name: OpenStack Foundation OpenStack Nova, BIOS rel-1.8.1-0-g4adadbd-20170107_142945-9_64_246_229 04/01/2014
> 
> It looks like this is a vendor kernel and not an upstream kernel, yes?

I analysed the upstream kernel about audit, and found there is no significant change
in audit_names add/read/delete since v3.10.

audit_names could be delete in __audit_syscall_exit, do_exit, copy_process
on upstream kernel(same as v3.10).

if we are reading audit_names, such as
	__audit_syscall_exit
		audit_filter_inodes
			read each audit_names ...
			

is there any situation could delete audit_names at the same time?

>   Assuming that is the case I would suggest you contact your distro for
> help/debugging/support; we simply don't know enough about your kernel
> (what patches are included, how was it built/configured/etc.) to
> comment with any certainty.
> 
> Linux Kernels based on v3.10.0 are extremely old from an upstream
> perspective, with a number of fixes and changes to the audit subsystem
> since v3.10.0 was released.  If you see the same problem on a modern
> upstream kernel please let us know, we'll be happy to help.
>