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

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