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]
Date:   Wed, 8 Sep 2021 04:06:43 +0000
From:   "Luck, Tony" <tony.luck@...el.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>
CC:     "x86@...nel.org" <x86@...nel.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Song Liu <songliubraving@...com>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Peter Ziljstra <peterz@...radead.org>
Subject: RE: [patch V2 00/20] x86/fpu: Clean up exception fixups and error
 handling in sigframe related code

>> Huch? That tree is based on 0bcfe68b876 and it just has those 20 patches
>> on top which should not at all interfere with your root filesystem
>> device. Let me verify.
>
> I lost connection to my test machines. Will continue tomorrow morning.

To save you some time I ran a bisect. It says the wheels fall off the bus at
patch 13/20

$ git bisect bad
43bce826b58940bd3143f110d36f5901d009e527 is the first bad commit
commit 43bce826b58940bd3143f110d36f5901d009e527
Author: Thomas Gleixner <tglx@...utronix.de>
Date:   Mon Aug 30 18:27:25 2021 +0200

    x86/fpu/signal: Move xstate clearing out of copy_fpregs_to_sigframe()

    When the direct saving of the FPU registers to the user space sigframe
    fails, copy_fpregs_to_sigframe() attempts to clear the user buffer.

    The most likely reason for such a fail is a page fault. As
    copy_fpregs_to_sigframe() is invoked with pagefaults disabled the chance
    that __clear_user() succeeds is minuscule.

    Move the clearing out into the caller which replaces the
    fault_in_pages_writeable() in that error handling path.

    The return value confusion will be cleaned up separately.

    Suggested-by: Al Viro <viro@...iv.linux.org.uk>
    Signed-off-by: Thomas Gleixner <tglx@...utronix.de>

:040000 040000 a7dce9444541186dcc30f21c9d0416d48f215507 71056cf4baa014ca33ab4861b0aca76b154979bf M arch

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ