linux-kernel - Re: [PATCH v6 02/13] user_events: Add minimal support for trace

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20211209145738.4da346ba@gandalf.local.home>
Date:   Thu, 9 Dec 2021 14:57:38 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Beau Belgrave <beaub@...ux.microsoft.com>
Cc:     mhiramat@...nel.org, linux-trace-devel@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 02/13] user_events: Add minimal support for
 trace_event into ftrace

On Thu, 9 Dec 2021 11:42:35 -0800
Beau Belgrave <beaub@...ux.microsoft.com> wrote:

> User program task:
> CPU0: ioctl(fd, REG)
> CPU1: close(fd)
> 
> IE: Some program registers and then immediately calls close on the file.
> If the CPU migrates right between the 2 and the close swaps, it is
> possible this could occur.
> 
> This could be attempted in tight loops maliciously as well.
> 
> I assume with a mutex there that some barrier is imposed to ensure
> correct reads in this condition? (By virtue of the mutex acquire/check)

But as I stated before, the ioctl() uses fdget() which will prevent he
close from calling the release. Even if they get swapped. If close goes
first and starts down the path of the release, then the ioctl is guaranteed
to return -EBADF. If it gets the fd, then close will be a nop, and the exit
of the ioctl will call the release.

If this wasn't the case, then the race I was concerned about would be an
issue.

Because we are both confused by this, add the mutex! :-)

-- Steve