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

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

[Ginger]

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.

Please kindly check at your convenience. Thank you for your time and
consideration.

Best regards,
Ginger

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

[Dmitry Torokhov]

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

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

[Ginger]

Hi Dmitry,

Many thanks for the clarification.

In that case, may I kindly ask if it is necessary to fix joydev with locks,
or we can leave it this way and let it just tolerate some inconsistencies?

Regards,
Ginger

On Tue, Jun 2, 2026 at 1:22 AM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> 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