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]
Message-ID: <CAG48ez3AGh-R+deQMbNPt6PCQazOz8a96skW+qP3_HmUaANmmQ@mail.gmail.com>
Date:   Tue, 8 Nov 2022 15:53:07 +0100
From:   Jann Horn <jannh@...gle.com>
To:     David Laight <David.Laight@...lab.com>
Cc:     Kees Cook <keescook@...omium.org>,
        "linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>,
        "kernel-hardening@...ts.openwall.com" 
        <kernel-hardening@...ts.openwall.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Linus Torvalds <torvalds@...uxfoundation.org>,
        Seth Jenkins <sethjenkins@...gle.com>,
        "Eric W . Biederman" <ebiederm@...ssion.com>,
        Andy Lutomirski <luto@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] exit: Put an upper limit on how often we can oops

On Tue, Nov 8, 2022 at 10:26 AM David Laight <David.Laight@...lab.com> wrote:
> > Many Linux systems are configured to not panic on oops; but allowing an
> > attacker to oops the system **really** often can make even bugs that look
> > completely unexploitable exploitable (like NULL dereferences and such) if
> > each crash elevates a refcount by one or a lock is taken in read mode, and
> > this causes a counter to eventually overflow.
> >
> > The most interesting counters for this are 32 bits wide (like open-coded
> > refcounts that don't use refcount_t). (The ldsem reader count on 32-bit
> > platforms is just 16 bits, but probably nobody cares about 32-bit platforms
> > that much nowadays.)
> >
> > So let's panic the system if the kernel is constantly oopsing.
>
> I think you are pretty much guaranteed to run out of memory
> (or at least KVA) before any 32bit counter wraps.

Not if you repeatedly take a reference and then oops without dropping
the reference, and the oops path cleans up all the resources that were
allocated for the crashing tasks. In that case, each oops increments
the reference count by 1 without causing memory allocation.

(Also, as a sidenote: To store 2^32 densely packed pointers, you just
need around 8 bytes * (2^32) = 32 GiB of RAM. So on a workstation or
server with a decent amount of RAM, there can already be cases where
you can overflow a 32-bit reference counter with legitimate references
- see <https://bugs.chromium.org/p/project-zero/issues/detail?id=809>.
Another example that needs more RAM is
<https://bugs.chromium.org/p/project-zero/issues/detail?id=1752>, that
needs ~140 GiB. Still probably within the realm of what a beefy server
might have nowadays? Kernel virtual address space is not a meaningful
limit on x86-64 - even with 4-level paging, the kernel has a 64 TiB
virtual memory area (the direct mapping) that is used for slab
allocations and such, see
<https://www.kernel.org/doc/html/latest/x86/x86_64/mm.html>. With
5-level paging it's even more, 32 PiB.)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ