On Tue, Nov 8, 2022 at 10:26 AM David Laight <David.Laight@xxxxxxxxxx> 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.)
