archive mirror
 help / color / mirror / Atom feed
From: Dmitry Torokhov <>
To: Alexander Larkin <>
Subject: Re: [PATCH] Input: joydev - prevent potential write out of bounds in ioctl
Date: Mon, 21 Jun 2021 15:38:39 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Alexander,

On Tue, Jun 22, 2021 at 12:32:15AM +0300, Alexander Larkin wrote:
> I'm still studying "git send-email", so the first intro part of prev msg deleted, sorry, again:
> Continuying my previous message, the JSIOCGBTNMAP always returns 1024 return code,
> but not "amount of buttons" like I said before
> (that is probably the size of the keymap that is _u16 keymap[KEY_MAX - BTN_MISC + 1] ).
> Is it correct?
> Reading the line of kernel joydev.c
> 579	len = min_t(size_t, _IOC_SIZE(cmd), sizeof(joydev->keypam)),
> , why the min is always sizeof(joydev->keypam) ?
> If I try to call from the userspace
> ioctl(fd, JSIOCGBTNMAP, buttons)
> where the buttons is "__u16 buttons[5]", then still I get 1024.
> Also I did userspace test (that shows how kernel overwrites (out of array bound) the userspace):
> 1. The buttons is "__u16 buttons[5]" in userspace,
> 2. buttons[5] = 1;
> 3. ioctl(fd, JSIOCGBTNMAP, buttons)
> 4. printf("new %i\n", buttons[5]),
> and the output is "new 0", so the value is being overwritten by kernel (so 1024 bytes copied
> to 10 bytes buffer).
> It looks like I don't understand what is the expected value of the _IOC_SIZE(cmd),
> why not 10 for this read ioctl example? Is it possible to make this ioctl safe, so
> it doesn't copy more data than user can handle?

The definition of JSIOCGBTNMAP is:

#define JSIOCGBTNMAP _IOR('j', 0x34, __u16[KEY_MAX - BTN_MISC + 1])

so the size is encoded in the definition and userspace is supposed to
supply buffer of appropriate size. In your examples you are essentially
are lying to the kernel and say that the buffer size is KEY_MAX -
BTN_MISC + 1 words while in reality you only supply 10 bytes (5 words).

Maybe we should have defined (long time ago)

#define JSIOCGBTNMAP_LEN(len)	_IOC(_IOC_READ, 'j', 0x43, len)

to allow userspace better control over the buffer, but I consider joydev
interface obsolete and all new clients should be using evdev to get
events from input devices. so I am not sure if there is any benefit in
fixing joydev ioctls.



  reply	other threads:[~2021-06-21 22:38 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-20 12:00 [PATCH] Input: joydev - prevent potential write out of bounds in ioctl Alexander Larkin
2021-06-20 16:37 ` Linus Torvalds
2021-06-21  5:25   ` Dmitry Torokhov
2021-06-21 15:45     ` Linus Torvalds
2021-06-21 20:06       ` Alexander Larkin
2021-06-21 21:30       ` Alexander Larkin
2021-06-21 21:32       ` Alexander Larkin
2021-06-21 22:38         ` Dmitry Torokhov [this message]
2021-07-03 16:21 ` Denis Efremov
2021-07-05 10:54   ` Dan Carpenter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).