Re: [BUG] FUT_OFF_MMSHARED futex waiters can outlive mm_struct (because of futex_requeue() and maybe io_uring)

[Peter Zijlstra <peterz@infradead.org>]

On Thu, Sep 24, 2026 at 09:26:45PM +0200, Jann Horn wrote:
> == Summary ==
> FUT_OFF_MMSHARED futex waiters can outlive the mm_struct that the
> futex_key refers to because of futex_requeue() [tested] and probably
> also via io_uring [untested].
> 
> This doesn't have much practical impact, I think at most it could:
> 1. cause missed wakeups for non-private futexes in anonymous memory
> 2. allow unrelated processes to guess addresses of FUT_OFF_MMSHARED futexes.
> 
> I propose we handle FUT_OFF_MMSHARED like FUT_OFF_INODE and put a
> unique 64-bit ID into struct futex_mm_data, which can be used in futex
> keys. That should address both futex_requeue() and io_uring. If that
> sounds good, I'd be happy to write a patch.

Whee, you do find the best problems :-)

> == Fixing it ==
> I see two approaches to fixing this:
> 
> 1. Put a unique 64-bit ID into struct futex_mm_data, which can be used
> in futex keys, similar to how FUT_OFF_INODE is already handled with
> get_inode_sequence_number(). That should address both futex_requeue()
> and io_uring.
> 2. Ensure that FUT_OFF_MMSHARED waiters can't wait on another
> mm_struct by blocking attempts to requeue FUT_OFF_INODE waiters onto a
> FUT_OFF_MMSHARED key. For io_uring, make io_req_track_inflight()
> unconditional.
> 
> I like option 1 because it also avoids feeding a kernel pointer into a
> hash function together with user input, which probably creates a
> timing side channel leak of mm_struct pointers.

I agree that option 1 is the sanest. Please write that patch.