Re: [bug report] Potential atomicity bug in drivers/input/joydev.c, between joydev_0x_read() and joydev_ioctl_common()

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

Hi Ginger,

On Mon, Jun 01, 2026 at 03:07:05PM +0800, Ginger wrote:
> Dear Linux kernel maintainers,
> 
> My research-based static analyzer found a potential atomicity bug
> within the 'drivers/input' subsystem, more specifically, in
> 'drivers/input/joydev.c'.
> 
> This potential issue is present as of git commit
> eb3f4b7426cfd2b79d65b7d37155480b32259a11 of the mainline kernel.
> 
> Potential concurrent triggering executions:
> T0:
> joydev_0x_read
>      --> spin_lock_irq(&input->event_lock);
>      --> read from joydev->abs
>      --> spin_unlock_irq(&input->event_lock);
> 
> T1:
> joydev_ioctl_common
>     --> case JSIOCSCORR:
>     --> write to joydev->abs[i] (no unlocked)
> 
> The above trace is meant to demonstrate an illustrative example of the issue:
> IMHO, in 'joydev_0x_read', the 'input->event_lock' is adopted to
> serialize the read
> accesses to joydev's fields like 'abs' and 'keypam' or input's fields
> like 'input->key.
> However, in either case, the write-side accesses to these fields are
> not similarly
> serialized.

Yes, there is lack of locking in joydev. Some of this might be OK (if
we prevent tearing on reads/writes) since the data may actually be
obsolete immediately after we read it, while in many places we
actually do need consistency, especially when we adjust key and axis
maps.

Thanks.

-- 
Dmitry