[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210705105414.GG26672@kadam>
Date: Mon, 5 Jul 2021 13:54:14 +0300
From: Dan Carpenter <dan.carpenter@...cle.com>
To: Denis Efremov <denis.e.efremov@...cle.com>
Cc: Alexander Larkin <avlarkin82@...il.com>, dmitry.torokhov@...il.com,
linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
security@...nel.org,
Murray McAllister <murray.mcallister@...il.com>
Subject: Re: [PATCH] Input: joydev - prevent potential write out of bounds in
ioctl
On Sat, Jul 03, 2021 at 07:21:58PM +0300, Denis Efremov wrote:
> Hi,
>
> On 6/20/21 3:00 PM, Alexander Larkin wrote:
> > The problem is that the check of user input values that is just
> > before the fixed line of code is for the part of first values
> > (before len or before len/2), but then the usage of all the values
> > including i >= len (or i >= len/2) could be.
> > Since the resulted array of values inited by default with some
> > good values, the fix is to ignore out of bounds values and
> > just to use only correct input values by user.
> > Originally detected by Murray with this simple poc
> > (If you run the following as an unprivileged user on a default install
> > it will instantly panic the system:
> >
> > int main(void) {
> > int fd, ret;
> > unsigned int buffer[10000];
> >
> > fd = open("/dev/input/js0", O_RDONLY);
> > if (fd == -1)
> > printf("Error opening file\n");
> >
> > ret = ioctl(fd, JSIOCSBTNMAP & ~IOCSIZE_MASK, &buffer);
> > printf("%d\n", ret);
> > }
> >
> > Fixes: 182d679b2298 ("Input: joydev - prevent potential read overflow in ioctl")
>
>
> I'm not sure that this is a proper fixes tag. Seems like the bug is in the
> code since the first commit (1da177e4c3f4). Maybe it's possible to add 2 fixes
> tags just to notify developers that this bug is older than a 182d679b2298
> partial fix.
Normally just setting the fixes tag to my patch would be the correct
thing to do. But in this case, I didn't get a CVE for my patch so
scripts which determine if a patch is required automatically might get
confused? It's not unusual to use two fixes tags so it might be a good
idea in this case just to avoid any confusion.
regards,
dan carpenter
Powered by blists - more mailing lists