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: <CACaBj2YUiowSKzvh02OjpQNqQViA8N0eyRMimkK=90NagRF40w@mail.gmail.com>
Date:   Thu, 27 May 2021 13:51:13 +0200
From:   Rodrigo Campos <rodrigo@...volk.io>
To:     Sargun Dhillon <sargun@...gun.me>
Cc:     Kees Cook <keescook@...omium.org>,
        LKML <linux-kernel@...r.kernel.org>, containers@...ts.linux.dev,
        Tycho Andersen <tycho@...ho.pizza>,
        Andy Lutomirski <luto@...nel.org>,
        Mauricio Vásquez Bernal <mauricio@...volk.io>,
        Giuseppe Scrivano <gscrivan@...hat.com>,
        Christian Brauner <christian.brauner@...ntu.com>,
        Mickaël Salaün <mic@...ux.microsoft.com>
Subject: Re: [PATCH v2 2/4] seccomp: Refactor notification handler to prepare
 for new semantics

On Mon, May 17, 2021 at 9:39 PM Sargun Dhillon <sargun@...gun.me> wrote:
>
> This refactors the user notification code to have a do / while loop around
> the completion condition. This has a small change in semantic, in that
> previously we ignored addfd calls upon wakeup if the notification had been
> responded to, but instead with the new change we check for an outstanding
> addfd calls prior to returning to userspace.
>
> Rodrigo Campos also identified a bug that can result in addfd causing
> an early return, when the supervisor didn't actually handle the
> syscall [1].
>
> [1]: https://lore.kernel.org/lkml/20210413160151.3301-1-rodrigo@kinvolk.io/
>
> Fixes: 7cf97b125455 ("seccomp: Introduce addfd ioctl to seccomp user notifier")
> Signed-off-by: Sargun Dhillon <sargun@...gun.me>
> Acked-by: Tycho Andersen <tycho@...ho.pizza>

Kees, as I mentioned in the linked thread, this issue is present in
5.9+ kernels. Should we add the cc to stable for this patch? Or should
we cc to stable the one linked, that just fixes the issue without
semantic changes to userspace?

Just to be clear, the other patch that fixes the problem without
userspace visible changes is this:
https://lore.kernel.org/lkml/20210413160151.3301-1-rodrigo@kinvolk.io/


Best,
Rodrigo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ