On Tue, 18 Mar 2025 at 01:30, Joanne Koong <joannelkoong@xxxxxxxxx> wrote:
>
> There is a race condition leading to a kernel crash from a null
> dereference when attemping to access fc->lock in
> fuse_uring_create_queue(). fc may be NULL in the case where another
> thread is creating the uring in fuse_uring_create() and has set
> fc->ring but has not yet set ring->fc when fuse_uring_create_queue()
> reads ring->fc. There is another race condition as well where in
> fuse_uring_register(), ring->nr_queues may still be 0 and not yet set
> to the new value when we compare qid against it.
>
> This fix sets fc->ring only after ring->fc and ring->nr_queues have been
> set, which guarantees now that ring->fc is a proper pointer when any
> queues are created and ring->nr_queues reflects the right number of
> queues if ring is not NULL. We must use smp_store_release() and
> smp_load_acquire() semantics to ensure the ordering will remain correct
> where fc->ring is assigned only after ring->fc and ring->nr_queues have
> been assigned.
>
> Signed-off-by: Joanne Koong <joannelkoong@xxxxxxxxx>
> Fixes: 24fe962c86f5 ("fuse: {io-uring} Handle SQEs - register commands")
Acked-by: Miklos Szeredi <mszeredi@xxxxxxxxxx>
Christian, can you please queue this fix up for 6.14-final?
Thanks,
Miklos
