On Wed, Nov 9, 2022 at 10:04 AM David Laight <David.Laight@xxxxxxxxxx> wrote: > > From: Jann Horn > > Sent: 08 November 2022 14:53 > > > > 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. > > I'd have thought that the kernel stack and process areas couldn't > be freed because they might contain 'live data'. > There is also the much smaller pid_t structure. > > Of course I might be wrong... > But I'm sure /proc/pid/stack is valid for an oopsed process. No. It might be in the edgecase where the process oopses, then the kernel tries to exit, then it oopses again, and the kernel decides that that process is a hazardous mess and can't be cleaned up. But in the general case, oopsed processes don't have /proc/$pid/stack anymore, they go through the normal exit path, and they get reaped normally by their parent.
