* Re: [PATCH RESEND] HID: fix error message in hid_open_report()
From: Jiri Kosina @ 2019-08-20 14:55 UTC (permalink / raw)
To: Michał Mirosław; +Cc: linux-input, Benjamin Tissoires, linux-kernel
In-Reply-To: <1230b0c19fd21fdc4d0eb30f3e32e67fff86fef9.1563818405.git.mirq-linux@rere.qmqm.pl>
On Mon, 22 Jul 2019, Michał Mirosław wrote:
> On HID report descriptor parsing error the code displays bogus
> pointer instead of error offset (subtracts start=NULL from end).
> Make the message more useful by displaying correct error offset
> and include total buffer size for reference.
>
> This was carried over from ancient times - "Fixed" commit just
> promoted the message from DEBUG to ERROR.
>
> Cc: stable@vger.kernel.org
> Fixes: 8c3d52fc393b ("HID: make parser more verbose about parsing errors by default")
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
[ ... snip ... ]
> @@ -1230,7 +1232,8 @@ int hid_open_report(struct hid_device *device)
> }
> }
>
> - hid_err(device, "item fetching failed at offset %d\n", (int)(end - start));
> + hid_err(device, "item fetching failed at offset %zu/%zu\n",
> + size - (end - start), size);
Hi Michal,
thanks for the fix.
This causes:
drivers/hid/hid-core.c: In function ‘hid_open_report’:
drivers/hid/hid-core.c:1235:2: warning: format ‘%zu’ expects argument of type ‘size_t’, but argument 4 has type ‘unsigned int’ [-Wformat=]
hid_err(device, "item fetching failed at offset %zu/%zu\n",
^
could you please fix that up and resubmit?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] Input: hyperv-keyboard: Use in-place iterator API in the channel callback
From: Sasha Levin @ 2019-08-20 15:29 UTC (permalink / raw)
To: dmitry.torokhov@gmail.com
Cc: Dexuan Cui, linux-input@vger.kernel.org,
linux-hyperv@vger.kernel.org, Stephen Hemminger, Sasha Levin,
Haiyang Zhang, KY Srinivasan, Michael Kelley,
gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org
In-Reply-To: <20190820031805.GO121898@dtor-ws>
On Mon, Aug 19, 2019 at 08:18:05PM -0700, dmitry.torokhov@gmail.com wrote:
>On Tue, Aug 20, 2019 at 03:01:23AM +0000, Dexuan Cui wrote:
>> Simplify the ring buffer handling with the in-place API.
>>
>> Also avoid the dynamic allocation and the memory leak in the channel
>> callback function.
>>
>> Signed-off-by: Dexuan Cui <decui@microsoft.com>
>> ---
>>
>> Hi Dmitry, can this patch go through Sasha's hyperv tree:
>> https://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git
>>
>> This is a purely Hyper-V specific change.
>
>Sure, no problem.
>
>Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Queued up for hyperv-fixes, thank you.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH] Input: add support for polling to input devices
From: Dmitry Torokhov @ 2019-08-20 19:05 UTC (permalink / raw)
To: Michal Vokáč
Cc: Benjamin Tissoires, open list:HID CORE LAYER, lkml, Rob Herring
In-Reply-To: <8624c907-6d7e-3301-1044-113bb108ba9e@ysoft.com>
On Tue, Aug 20, 2019 at 01:56:53PM +0200, Michal Vokáč wrote:
> On 13. 08. 19 16:04, Benjamin Tissoires wrote:
> > On Mon, Aug 12, 2019 at 7:11 PM Dmitry Torokhov
> > <dmitry.torokhov@gmail.com> wrote:
> > >
> > > Hi Benjamin,
> > >
> > > On Mon, Aug 12, 2019 at 06:50:38PM +0200, Benjamin Tissoires wrote:
> > > > Hi Dmitry,
> > > >
> > > > On Fri, Aug 9, 2019 at 7:35 PM Dmitry Torokhov
> > > > <dmitry.torokhov@gmail.com> wrote:
> > > > >
> > > > > Separating "normal" and "polled" input devices was a mistake, as often we
> > > > > want to allow the very same device work on both interrupt-driven and
> > > > > polled mode, depending on the board on which the device is used.
> > > > >
> > > > > This introduces new APIs:
> > > > >
> > > > > - input_setup_polling
> > > > > - input_set_poll_interval
> > > > > - input_set_min_poll_interval
> > > > > - input_set_max_poll_interval
> > > > >
> > > > > These new APIs allow switching an input device into polled mode with sysfs
> > > > > attributes matching drivers using input_polled_dev APIs that will be
> > > > > eventually removed.
> > > >
> > > > Are you sure that using sysfs is the correct way here?
> > > > I would think using generic properties that can be overwritten by the
> > > > DSDT or by the device tree would make things easier from a driver
> > > > point of view.
> > >
> > > Couple of points: I wanted it to be compatible with input-polldev.c so
> > > the sysfs attributes must match (so that we can convert existing drivers
> > > and zap input-polldev).
> >
> > Oh, I missed that. Good point.
> >
> > > I also am not sure if polling parameters are
> > > property of board, or it is either fundamental hardware limitation or
> > > simply desired system behavior.
> >
> > I think it's a combination of everything: sometimes the board misses
> > the capability to not do IRQs for that device, and using properties
> > would be better here: you can define them where you need (board,
> > platform or device level), and have a working platfrom from the kernel
> > description entirely.
> > However, it doesn't solve the issue of input-polldev, so maybe
> > properties should be added on top of this sysfs.
> >
> > > If Rob is OK with adding device
> > > properties I'd be fine adding them as a followup, otherwise we can have
> > > udev adjust the behavior as needed for given box shortly after boot.
> >
> > Fair enough.
> >
> > >
> > > >
> > > > Also, checkpatch complains about a few octal permissions that are
> > > > preferred over symbolic ones, and there is a possible 'out of memory'
> > > > nessage at drivers/input/input-poller.c:75.
> > >
> > > Yes, there is. It is there so we would know what device we were trying
> > > to set up when OOM happened. You can probable decipher the driver from
> > > the stack trace, but figuring particular device instance is harder.
> >
> > Could you add a comment there explaining this choice? I have a feeling
> > you'll have to refuse a few patches of people running coccinelle
> > scripts and be too happy to send a kernel patch.
Done.
> >
> > Other than that:
> > Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> >
>
> Hi Dmitry,
>
> what is the status of this patch? Are we still waiting for Rob to
> comment on the device properties or is this ready to land?
I applied it just now.
>
> Little bit OT question: what tree/branch do you use to apply patches?
> According to the mailing list you recently applied some patches but
> I can not find them here [1].
Patches that go into current cycle will be in 'for-linus' branch.
Patches that will be merged in the next merge window (like this one)
will end up in 'next' branch.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2] (submitted) input: misc: soc_button_array: use platform_device_register_resndata()
From: Dmitry Torokhov @ 2019-08-21 3:20 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult; +Cc: linux-kernel, linux-input
In-Reply-To: <1566303944-15321-1-git-send-email-info@metux.net>
Hi Enrico,
On Tue, Aug 20, 2019 at 02:25:44PM +0200, Enrico Weigelt, metux IT consult wrote:
> From: Enrico Weigelt <info@metux.net>
>
> The registration of gpio-keys device can be written much shorter
> by using the platform_device_register_resndata() helper.
>
> v2:
> * pass &pdev->dev to platform_device_register_resndata()
> * fixed errval on failed platform_device_register_resndata()
>
> Signed-off-by: Enrico Weigelt <info@metux.net>
> ---
> drivers/input/misc/soc_button_array.c | 27 +++++++++++++--------------
> 1 file changed, 13 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/input/misc/soc_button_array.c b/drivers/input/misc/soc_button_array.c
> index 5e59f8e5..27550f9 100644
> --- a/drivers/input/misc/soc_button_array.c
> +++ b/drivers/input/misc/soc_button_array.c
> @@ -110,25 +110,24 @@ static int soc_button_lookup_gpio(struct device *dev, int acpi_index)
> gpio_keys_pdata->nbuttons = n_buttons;
> gpio_keys_pdata->rep = autorepeat;
>
> - pd = platform_device_alloc("gpio-keys", PLATFORM_DEVID_AUTO);
> - if (!pd) {
> - error = -ENOMEM;
> + pd = platform_device_register_resndata(
> + &pdev->dev,
> + "gpio-keys",
> + PLATFORM_DEVID_AUTO,
> + NULL,
> + 0,
> + gpio_keys_pdata,
> + sizeof(*gpio_keys_pdata));
> +
> + error = PTR_ERR_OR_ZERO(pd);
> +
> + if (IS_ERR(pd)) {
I changed this and the PTR_ERR() to simply "error" and applied.
> + dev_err(&pdev->dev, "failed registering gpio-keys: %ld\n", PTR_ERR(pd));
> goto err_free_mem;
> }
>
> - error = platform_device_add_data(pd, gpio_keys_pdata,
> - sizeof(*gpio_keys_pdata));
> - if (error)
> - goto err_free_pdev;
> -
> - error = platform_device_add(pd);
> - if (error)
> - goto err_free_pdev;
> -
> return pd;
>
> -err_free_pdev:
> - platform_device_put(pd);
> err_free_mem:
> devm_kfree(&pdev->dev, gpio_keys_pdata);
> return ERR_PTR(error);
> --
> 1.9.1
>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 4/4] input/vmmouse: Update the backdoor call with support for new instructions
From: Dmitry Torokhov @ 2019-08-21 5:09 UTC (permalink / raw)
To: Thomas Hellström (VMware)
Cc: linux-kernel, pv-drivers, Thomas Hellstrom, linux-input,
Doug Covelli
In-Reply-To: <20190818143316.4906-5-thomas_os@shipmail.org>
On Sun, Aug 18, 2019 at 04:33:16PM +0200, Thomas Hellström (VMware) wrote:
> From: Thomas Hellstrom <thellstrom@vmware.com>
>
> Use the definition provided by include/asm/vmware.h
>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: <linux-input@vger.kernel.org>
> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
> Reviewed-by: Doug Covelli <dcovelli@vmware.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Please feel free to merge with the rest of the patches introducing
VMWARE_HYPERCALL.
> ---
> drivers/input/mouse/vmmouse.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/mouse/vmmouse.c b/drivers/input/mouse/vmmouse.c
> index 871e5b5ab129..0c7707c7bede 100644
> --- a/drivers/input/mouse/vmmouse.c
> +++ b/drivers/input/mouse/vmmouse.c
> @@ -16,6 +16,7 @@
> #include <linux/slab.h>
> #include <linux/module.h>
> #include <asm/hypervisor.h>
> +#include <asm/vmware.h>
>
> #include "psmouse.h"
> #include "vmmouse.h"
> @@ -84,7 +85,7 @@ struct vmmouse_data {
> #define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4) \
> ({ \
> unsigned long __dummy1, __dummy2; \
> - __asm__ __volatile__ ("inl %%dx" : \
> + __asm__ __volatile__ (VMWARE_HYPERCALL : \
> "=a"(out1), \
> "=b"(out2), \
> "=c"(out3), \
> --
> 2.20.1
>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v1 01/63] Input: introduce input_mt_report_slot_inactive
From: Jiada Wang @ 2019-08-21 9:13 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: nick, linux-input, linux-kernel, george_davis
In-Reply-To: <20190816171226.GE121898@dtor-ws>
Hi Dmitry
On 2019/08/17 2:12, Dmitry Torokhov wrote:
> Hi Jiada,
>
> On Fri, Aug 16, 2019 at 05:28:50PM +0900, Jiada Wang wrote:
>> input_mt_report_slot_state() ignores the tool when the slot is closed.
>> which has caused a bit of confusion.
>> This patch introduces input_mt_report_slot_inactive() to report slot
>> inactive state.
>> replaces all input_mt_report_slot_state() with input_mt_report_slot_inactive()
>> in case of close of slot, also some other related changes.
>
> This seems to actually contain 2 changes:
>
> - switching to use return value of input_mt_report_slot_state()
> - actually introducing and using input_mt_report_slot_inactive()
>
> Please split them.
>
will split this patch into two in v2 patchset
>>
>> +/**
>> + * input_mt_report_slot_inactive() - report contact inactive state
>> + * @dev: input device with allocated MT slots
>> + *
>> + * Reports the contact inactive state via ABS_MT_TRACKING_ID
>> + *
>> + */
>> +void input_mt_report_slot_inactive(struct input_dev *dev)
>> +{
>> + input_event(dev, EV_ABS, ABS_MT_TRACKING_ID, -1);
>> +}
>> +EXPORT_SYMBOL(input_mt_report_slot_inactive);
>
> I think this should be a static inline, there is no need to have out of
> line implementation for a 1-liner.
>
will change to a inline function in v2 patchset.
Thanks,
Jiada
> Thanks.
>
^ permalink raw reply
* Re: [PATCH 2/2] drivers: input: mouse: alps: drop unneeded likely() call around IS_ERR()
From: Enrico Weigelt, metux IT consult @ 2019-08-21 11:37 UTC (permalink / raw)
To: Pali Rohár
Cc: Enrico Weigelt, metux IT consult, linux-kernel, dmitry.torokhov,
linux-input, linux-ntfs-dev
In-Reply-To: <20190820142204.x352bftlvnb7s57n@pali>
On 20.08.19 16:22, Pali Rohár wrote:
Hi,
>> In that case, wouldn't a comment be more suitable for that ?
>
> And why to add comment if current state of code is more-readable and
> does not need it?
Readability is probably a bit subjective :p
With ongoing efforts of automatically identifying redundant code pathes,
the current situation causes the same discussion coming up over and over
again. Sooner or later somebody might get the idea to add a comment on
that line, that it's exactly as intented :o
OTOH, I'm unsure whether it's important to document that is particular
error path is unlikely, while we don't do it in thousands of other
places. IMHO, error pathes are supposed to be unlikely by nature,
otherwise we wouldn't call it an error situation ;-)
> People normally add comments to code which is problematic to understand
> or is somehow tricky, no so obvious or document how should code behave.
Yes, but isn't this case so obvious that it doesn't need any
documentation at all ? Is it so important to never ever forget that this
particular path is a rare situation ?
I might be wrong, but IMHO the likely()/unlikely() macros have been
introduced for optimization (better pipeline optimization for the
frequent cases).
> People first need to understand that static code analysis cannot work
> 100% reliably and always is needed to properly review changes.
Yes, but we see that this particular case is coming up again and again,
from different people, who can't know the background of this (nobody
can read the whole lkml and remember everything). This could be
prevented by adding a comment on that line, but then the macro call
just for documentation wouldn't be necessary anymore.
> And if the only reason for this change is to satisfy some static code
> analysis program,
Actually, it's more for people who're using the tools for the purpose
of tidying up the code and find potential problems. They need some
information to act on properly, which is currently missing ...
> would not it better to teach this program to no
> generate such false-positive results?
Okay, but how to do that practically ? There's no information in the
code which neither some tool nor any human could recognize this false
alarm. That information is just in your brain, now also in mine, and
the other folks who previously proposed the same change (assuming they
still recall it after years).
Blacklisting doesn't seem to be a good idea in the long run. Once going
that route, such blacklists grow quickly and get hard to maintain (we
now have two entirely separately maintained data sources that need to
be synced manually, when something changes).
I believe the code should be kinda self-documenting, so the reader
shouldn't need any detailed special knowledge to understand it. IMHO,
when such discussions on actual implementation details come up, the
code isn't expressive enough.
How can we improve the situation ?
Shall we consider introducing yet another macro (explicitly different
name) for stating/documenting such cases ?
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287
^ permalink raw reply
* Re: [PATCH 00/11] Face lift for bu21013_ts driver
From: Linus Walleij @ 2019-08-21 12:39 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Linux Input, linux-kernel@vger.kernel.org
In-Reply-To: <20190810002039.95876-1-dmitry.torokhov@gmail.com>
On Sat, Aug 10, 2019 at 2:20 AM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> So your patch has prompted me to take a look at the driver and
> try to clean it up. I am sure I screwed up somewhere, but you said
> you have the device, so please take a look at the series and
> see if you can salvage them
I will funnel patch 1/11 in the ARM SoC tree.
The rest work fine except on the resource release in the error path. I had
to do this:
diff --git a/drivers/input/touchscreen/bu21013_ts.c
b/drivers/input/touchscreen/bu21013_ts.c
index c89a00a6e67c..bdae4cd4243a 100644
--- a/drivers/input/touchscreen/bu21013_ts.c
+++ b/drivers/input/touchscreen/bu21013_ts.c
@@ -390,18 +390,18 @@ static int bu21013_init_chip(struct bu21013_ts *ts)
return 0;
}
-static void bu21013_power_off(void *_ts)
+static void bu21013_power_off(void *data)
{
- struct bu21013_ts *ts = ts;
+ struct regulator *regulator = data;
- regulator_disable(ts->regulator);
+ regulator_disable(regulator);
}
-static void bu21013_disable_chip(void *_ts)
+static void bu21013_disable_chip(void *data)
{
- struct bu21013_ts *ts = ts;
+ struct gpio_desc *gpiod = data;
- gpiod_set_value(ts->cs_gpiod, 0);
+ gpiod_set_value(gpiod, 0);
}
static int bu21013_probe(struct i2c_client *client,
@@ -488,7 +488,8 @@ static int bu21013_probe(struct i2c_client *client,
return error;
}
- error = devm_add_action_or_reset(&client->dev, bu21013_power_off, ts);
+ error = devm_add_action_or_reset(&client->dev, bu21013_power_off,
+ ts->regulator);
if (error) {
dev_err(&client->dev, "failed to install power off handler\n");
return error;
@@ -505,7 +506,7 @@ static int bu21013_probe(struct i2c_client *client,
gpiod_set_consumer_name(ts->cs_gpiod, "BU21013 CS");
error = devm_add_action_or_reset(&client->dev,
- bu21013_disable_chip, ts);
+ bu21013_disable_chip, ts->cs_gpiod);
if (error) {
dev_err(&client->dev,
"failed to install chip disable handler\n");
I think this is because when probe() fails it first free:s the devm_kzalloc()
allocations, so the ts->foo will result in NULL dereference.
If I just reference the gpio desc or regulator directly like this in the
callback, things work fine.
With these changes:
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply related
* Re: [PATCH v5 11/17] net: sgi: ioc3-eth: no need to stop queue set_multicast_list
From: Thomas Bogendoerfer @ 2019-08-21 12:40 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Jonathan Corbet, Ralf Baechle, Paul Burton, James Hogan,
Dmitry Torokhov, Lee Jones, David S. Miller, Srinivas Kandagatla,
Alessandro Zummo, Alexandre Belloni, Greg Kroah-Hartman,
Jiri Slaby, Evgeniy Polyakov, linux-doc, linux-kernel, linux-mips,
linux-input, netdev, linux-rtc, linux-serial
In-Reply-To: <20190819170440.37ff18d4@cakuba.netronome.com>
On Mon, 19 Aug 2019 17:04:53 -0700
Jakub Kicinski <jakub.kicinski@netronome.com> wrote:
> On Mon, 19 Aug 2019 18:31:34 +0200, Thomas Bogendoerfer wrote:
> > netif_stop_queue()/netif_wake_qeue() aren't needed for changing
> > multicast filters. Use spinlocks instead for proper protection
> > of private struct.
> >
>
> I thought it may protect ip->emcr, but that one is accessed with no
> locking from the ioc3_timer() -> ioc3_setup_duplex() path..
it should protect ip->emcr ... I'll add spin_lock/unlock to setup_duplex and
respin the patch.
Thomas.
--
SUSE Linux GmbH
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v4 3/9] nvmem: core: add nvmem_device_find
From: Thomas Bogendoerfer @ 2019-08-21 12:48 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: Ralf Baechle, Paul Burton, James Hogan, Dmitry Torokhov,
Lee Jones, David S. Miller, Alessandro Zummo, Alexandre Belloni,
Greg Kroah-Hartman, Jiri Slaby, Evgeniy Polyakov, linux-mips,
linux-kernel, linux-input, netdev, linux-rtc, linux-serial
In-Reply-To: <fca76e6d-fa0b-176b-abcf-e7551b22e6a9@linaro.org>
On Mon, Aug 19, 2019 at 05:03:42PM +0100, Srinivas Kandagatla wrote:
> >>On 14/08/2019 12:46, Thomas Bogendoerfer wrote:
> >these patches are not in Linus tree, yet. I guess they will show up
> >in 5.4. No idea how to deal with it right now, do you ?
> All these patches are due to go in next merge window,
> You should base your patch on top of linux-next.
that depends, which maintainer will merge this series. Right now
it doesn't look like this series will make it into 5.4 as there
is still no sign form the W1 maintainer. My idea is to break out
the 5.4 parts and submit it. So I'll rebase the nvmem patch to
linux-next and send it. Hope it will be ok, if the user of
the new function will show up in 5.5.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in hidraw_ioctl
From: Andrey Konovalov @ 2019-08-21 12:57 UTC (permalink / raw)
To: syzbot
Cc: Benjamin Tissoires, Jiri Kosina, linux-input, LKML, USB list,
syzkaller-bugs
In-Reply-To: <00000000000016c09c058fdd7faa@google.com>
[-- Attachment #1: Type: text/plain, Size: 4053 bytes --]
On Sun, Aug 11, 2019 at 10:46 PM syzbot
<syzbot+5a6c4ec678a0c6ee84ba@syzkaller.appspotmail.com> wrote:
>
> syzbot has found a reproducer for the following crash on:
>
> HEAD commit: e96407b4 usb-fuzzer: main usb gadget fuzzer driver
> git tree: https://github.com/google/kasan.git usb-fuzzer
> console output: https://syzkaller.appspot.com/x/log.txt?x=150426ba600000
> kernel config: https://syzkaller.appspot.com/x/.config?x=cfa2c18fb6a8068e
> dashboard link: https://syzkaller.appspot.com/bug?extid=5a6c4ec678a0c6ee84ba
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12725c02600000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=162163c2600000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+5a6c4ec678a0c6ee84ba@syzkaller.appspotmail.com
>
> ==================================================================
> BUG: KASAN: slab-out-of-bounds in strlen+0x79/0x90 lib/string.c:525
> Read of size 1 at addr ffff8881d29bdf38 by task syz-executor201/1726
>
> CPU: 1 PID: 1726 Comm: syz-executor201 Not tainted 5.3.0-rc2+ #25
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0xca/0x13e lib/dump_stack.c:113
> print_address_description+0x6a/0x32c mm/kasan/report.c:351
> __kasan_report.cold+0x1a/0x33 mm/kasan/report.c:482
> kasan_report+0xe/0x12 mm/kasan/common.c:612
> strlen+0x79/0x90 lib/string.c:525
> strlen include/linux/string.h:281 [inline]
> hidraw_ioctl+0x245/0xae0 drivers/hid/hidraw.c:446
> vfs_ioctl fs/ioctl.c:46 [inline]
> file_ioctl fs/ioctl.c:509 [inline]
> do_vfs_ioctl+0xd2d/0x1330 fs/ioctl.c:696
> ksys_ioctl+0x9b/0xc0 fs/ioctl.c:713
> __do_sys_ioctl fs/ioctl.c:720 [inline]
> __se_sys_ioctl fs/ioctl.c:718 [inline]
> __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:718
> do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:296
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x445679
> Code: e8 5c ad 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7
> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
> ff 0f 83 9b cd fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007ffc8514f3a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000445679
> RDX: 0000000000000000 RSI: 0000000080404805 RDI: 0000000000000004
> RBP: 00000000006d0018 R08: 000000000000000b R09: 00000000004002e0
> R10: 000000000000000f R11: 0000000000000246 R12: 00000000004028a0
> R13: 0000000000402930 R14: 0000000000000000 R15: 0000000000000000
>
> Allocated by task 0:
> (stack is not available)
>
> Freed by task 0:
> (stack is not available)
>
> The buggy address belongs to the object at ffff8881d29bde60
> which belongs to the cache shmem_inode_cache of size 1168
> The buggy address is located 216 bytes inside of
> 1168-byte region [ffff8881d29bde60, ffff8881d29be2f0)
> The buggy address belongs to the page:
> page:ffffea00074a6f00 refcount:1 mapcount:0 mapping:ffff8881da115180
> index:0x0 compound_mapcount: 0
> flags: 0x200000000010200(slab|head)
> raw: 0200000000010200 dead000000000100 dead000000000122 ffff8881da115180
> raw: 0000000000000000 00000000800c000c 00000001ffffffff 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8881d29bde00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8881d29bde80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > ffff8881d29bdf00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ^
> ffff8881d29bdf80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8881d29be000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ==================================================================
>
Trying Alan's fix from another thread here:
#syz test: https://github.com/google/kasan.git usb-fuzzer e96407b4
[-- Attachment #2: logitech.patch --]
[-- Type: text/x-patch, Size: 1202 bytes --]
Index: usb-devel/drivers/hid/hid-lg.c
===================================================================
--- usb-devel.orig/drivers/hid/hid-lg.c
+++ usb-devel/drivers/hid/hid-lg.c
@@ -818,7 +818,7 @@ static int lg_probe(struct hid_device *h
if (!buf) {
ret = -ENOMEM;
- goto err_free;
+ goto err_stop;
}
ret = hid_hw_raw_request(hdev, buf[0], buf, sizeof(cbuf),
@@ -850,9 +850,12 @@ static int lg_probe(struct hid_device *h
ret = lg4ff_init(hdev);
if (ret)
- goto err_free;
+ goto err_stop;
return 0;
+
+err_stop:
+ hid_hw_stop(hdev);
err_free:
kfree(drv_data);
return ret;
@@ -863,8 +866,7 @@ static void lg_remove(struct hid_device
struct lg_drv_data *drv_data = hid_get_drvdata(hdev);
if (drv_data->quirks & LG_FF4)
lg4ff_deinit(hdev);
- else
- hid_hw_stop(hdev);
+ hid_hw_stop(hdev);
kfree(drv_data);
}
Index: usb-devel/drivers/hid/hid-lg4ff.c
===================================================================
--- usb-devel.orig/drivers/hid/hid-lg4ff.c
+++ usb-devel/drivers/hid/hid-lg4ff.c
@@ -1477,7 +1477,6 @@ int lg4ff_deinit(struct hid_device *hid)
}
}
#endif
- hid_hw_stop(hid);
drv_data->device_props = NULL;
kfree(entry);
^ permalink raw reply
* Re: Re: KASAN: slab-out-of-bounds Read in hidraw_ioctl
From: syzbot @ 2019-08-21 12:57 UTC (permalink / raw)
Cc: andreyknvl, benjamin.tissoires, jikos, linux-input, linux-kernel,
linux-usb, syzkaller-bugs
In-Reply-To: <CAAeHK+zeN+bLTix2yaWDo-iu_G4D8T1KELjds=KVTtywiPpc4g@mail.gmail.com>
> On Sun, Aug 11, 2019 at 10:46 PM syzbot
> <syzbot+5a6c4ec678a0c6ee84ba@syzkaller.appspotmail.com> wrote:
>> syzbot has found a reproducer for the following crash on:
>> HEAD commit: e96407b4 usb-fuzzer: main usb gadget fuzzer driver
>> git tree: https://github.com/google/kasan.git usb-fuzzer
>> console output: https://syzkaller.appspot.com/x/log.txt?x=150426ba600000
>> kernel config:
>> https://syzkaller.appspot.com/x/.config?x=cfa2c18fb6a8068e
>> dashboard link:
>> https://syzkaller.appspot.com/bug?extid=5a6c4ec678a0c6ee84ba
>> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
>> syz repro:
>> https://syzkaller.appspot.com/x/repro.syz?x=12725c02600000
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=162163c2600000
>> IMPORTANT: if you fix the bug, please add the following tag to the
>> commit:
>> Reported-by: syzbot+5a6c4ec678a0c6ee84ba@syzkaller.appspotmail.com
>> ==================================================================
>> BUG: KASAN: slab-out-of-bounds in strlen+0x79/0x90 lib/string.c:525
>> Read of size 1 at addr ffff8881d29bdf38 by task syz-executor201/1726
>> CPU: 1 PID: 1726 Comm: syz-executor201 Not tainted 5.3.0-rc2+ #25
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>> __dump_stack lib/dump_stack.c:77 [inline]
>> dump_stack+0xca/0x13e lib/dump_stack.c:113
>> print_address_description+0x6a/0x32c mm/kasan/report.c:351
>> __kasan_report.cold+0x1a/0x33 mm/kasan/report.c:482
>> kasan_report+0xe/0x12 mm/kasan/common.c:612
>> strlen+0x79/0x90 lib/string.c:525
>> strlen include/linux/string.h:281 [inline]
>> hidraw_ioctl+0x245/0xae0 drivers/hid/hidraw.c:446
>> vfs_ioctl fs/ioctl.c:46 [inline]
>> file_ioctl fs/ioctl.c:509 [inline]
>> do_vfs_ioctl+0xd2d/0x1330 fs/ioctl.c:696
>> ksys_ioctl+0x9b/0xc0 fs/ioctl.c:713
>> __do_sys_ioctl fs/ioctl.c:720 [inline]
>> __se_sys_ioctl fs/ioctl.c:718 [inline]
>> __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:718
>> do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:296
>> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>> RIP: 0033:0x445679
>> Code: e8 5c ad 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89
>> f7
>> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
>> ff 0f 83 9b cd fb ff c3 66 2e 0f 1f 84 00 00 00 00
>> RSP: 002b:00007ffc8514f3a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
>> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000445679
>> RDX: 0000000000000000 RSI: 0000000080404805 RDI: 0000000000000004
>> RBP: 00000000006d0018 R08: 000000000000000b R09: 00000000004002e0
>> R10: 000000000000000f R11: 0000000000000246 R12: 00000000004028a0
>> R13: 0000000000402930 R14: 0000000000000000 R15: 0000000000000000
>> Allocated by task 0:
>> (stack is not available)
>> Freed by task 0:
>> (stack is not available)
>> The buggy address belongs to the object at ffff8881d29bde60
>> which belongs to the cache shmem_inode_cache of size 1168
>> The buggy address is located 216 bytes inside of
>> 1168-byte region [ffff8881d29bde60, ffff8881d29be2f0)
>> The buggy address belongs to the page:
>> page:ffffea00074a6f00 refcount:1 mapcount:0 mapping:ffff8881da115180
>> index:0x0 compound_mapcount: 0
>> flags: 0x200000000010200(slab|head)
>> raw: 0200000000010200 dead000000000100 dead000000000122 ffff8881da115180
>> raw: 0000000000000000 00000000800c000c 00000001ffffffff 0000000000000000
>> page dumped because: kasan: bad access detected
>> Memory state around the buggy address:
>> ffff8881d29bde00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>> ffff8881d29bde80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>> > ffff8881d29bdf00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>> ^
>> ffff8881d29bdf80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>> ffff8881d29be000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>> ==================================================================
> Trying Alan's fix from another thread here:
> #syz test: https://github.com/google/kasan.git usb-fuzzer e96407b4
want 2 args (repo, branch), got 3
^ permalink raw reply
* Re: Re: KASAN: slab-out-of-bounds Read in hidraw_ioctl
From: syzbot @ 2019-08-21 12:57 UTC (permalink / raw)
Cc: benjamin.tissoires, jikos, linux-input, linux-kernel, linux-usb,
syzkaller-bugs
In-Reply-To: <CAAeHK+zeN+bLTix2yaWDo-iu_G4D8T1KELjds=KVTtywiPpc4g@mail.gmail.com>
> On Sun, Aug 11, 2019 at 10:46 PM syzbot
> <syzbot+5a6c4ec678a0c6ee84ba@syzkaller.appspotmail.com> wrote:
>> syzbot has found a reproducer for the following crash on:
>> HEAD commit: e96407b4 usb-fuzzer: main usb gadget fuzzer driver
>> git tree: https://github.com/google/kasan.git usb-fuzzer
>> console output: https://syzkaller.appspot.com/x/log.txt?x=150426ba600000
>> kernel config:
>> https://syzkaller.appspot.com/x/.config?x=cfa2c18fb6a8068e
>> dashboard link:
>> https://syzkaller.appspot.com/bug?extid=5a6c4ec678a0c6ee84ba
>> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
>> syz repro:
>> https://syzkaller.appspot.com/x/repro.syz?x=12725c02600000
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=162163c2600000
>> IMPORTANT: if you fix the bug, please add the following tag to the
>> commit:
>> Reported-by: syzbot+5a6c4ec678a0c6ee84ba@syzkaller.appspotmail.com
>> ==================================================================
>> BUG: KASAN: slab-out-of-bounds in strlen+0x79/0x90 lib/string.c:525
>> Read of size 1 at addr ffff8881d29bdf38 by task syz-executor201/1726
>> CPU: 1 PID: 1726 Comm: syz-executor201 Not tainted 5.3.0-rc2+ #25
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>> __dump_stack lib/dump_stack.c:77 [inline]
>> dump_stack+0xca/0x13e lib/dump_stack.c:113
>> print_address_description+0x6a/0x32c mm/kasan/report.c:351
>> __kasan_report.cold+0x1a/0x33 mm/kasan/report.c:482
>> kasan_report+0xe/0x12 mm/kasan/common.c:612
>> strlen+0x79/0x90 lib/string.c:525
>> strlen include/linux/string.h:281 [inline]
>> hidraw_ioctl+0x245/0xae0 drivers/hid/hidraw.c:446
>> vfs_ioctl fs/ioctl.c:46 [inline]
>> file_ioctl fs/ioctl.c:509 [inline]
>> do_vfs_ioctl+0xd2d/0x1330 fs/ioctl.c:696
>> ksys_ioctl+0x9b/0xc0 fs/ioctl.c:713
>> __do_sys_ioctl fs/ioctl.c:720 [inline]
>> __se_sys_ioctl fs/ioctl.c:718 [inline]
>> __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:718
>> do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:296
>> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>> RIP: 0033:0x445679
>> Code: e8 5c ad 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89
>> f7
>> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
>> ff 0f 83 9b cd fb ff c3 66 2e 0f 1f 84 00 00 00 00
>> RSP: 002b:00007ffc8514f3a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
>> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000445679
>> RDX: 0000000000000000 RSI: 0000000080404805 RDI: 0000000000000004
>> RBP: 00000000006d0018 R08: 000000000000000b R09: 00000000004002e0
>> R10: 000000000000000f R11: 0000000000000246 R12: 00000000004028a0
>> R13: 0000000000402930 R14: 0000000000000000 R15: 0000000000000000
>> Allocated by task 0:
>> (stack is not available)
>> Freed by task 0:
>> (stack is not available)
>> The buggy address belongs to the object at ffff8881d29bde60
>> which belongs to the cache shmem_inode_cache of size 1168
>> The buggy address is located 216 bytes inside of
>> 1168-byte region [ffff8881d29bde60, ffff8881d29be2f0)
>> The buggy address belongs to the page:
>> page:ffffea00074a6f00 refcount:1 mapcount:0 mapping:ffff8881da115180
>> index:0x0 compound_mapcount: 0
>> flags: 0x200000000010200(slab|head)
>> raw: 0200000000010200 dead000000000100 dead000000000122 ffff8881da115180
>> raw: 0000000000000000 00000000800c000c 00000001ffffffff 0000000000000000
>> page dumped because: kasan: bad access detected
>> Memory state around the buggy address:
>> ffff8881d29bde00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>> ffff8881d29bde80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>> > ffff8881d29bdf00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>> ^
>> ffff8881d29bdf80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>> ffff8881d29be000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>> ==================================================================
> Trying Alan's fix from another thread here:
> #syz test: https://github.com/google/kasan.git usb-fuzzer e96407b4
want 2 args (repo, branch), got 3
> --
> You received this message because you are subscribed to the Google
> Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/CAAeHK%2BzeN%2BbLTix2yaWDo-iu_G4D8T1KELjds%3DKVTtywiPpc4g%40mail.gmail.com.
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in hidraw_ioctl
From: Andrey Konovalov @ 2019-08-21 12:58 UTC (permalink / raw)
To: syzbot
Cc: Benjamin Tissoires, Jiri Kosina, linux-input, LKML, USB list,
syzkaller-bugs
In-Reply-To: <CAAeHK+zeN+bLTix2yaWDo-iu_G4D8T1KELjds=KVTtywiPpc4g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4362 bytes --]
On Wed, Aug 21, 2019 at 2:57 PM Andrey Konovalov <andreyknvl@google.com> wrote:
>
> On Sun, Aug 11, 2019 at 10:46 PM syzbot
> <syzbot+5a6c4ec678a0c6ee84ba@syzkaller.appspotmail.com> wrote:
> >
> > syzbot has found a reproducer for the following crash on:
> >
> > HEAD commit: e96407b4 usb-fuzzer: main usb gadget fuzzer driver
> > git tree: https://github.com/google/kasan.git usb-fuzzer
> > console output: https://syzkaller.appspot.com/x/log.txt?x=150426ba600000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=cfa2c18fb6a8068e
> > dashboard link: https://syzkaller.appspot.com/bug?extid=5a6c4ec678a0c6ee84ba
> > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12725c02600000
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=162163c2600000
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+5a6c4ec678a0c6ee84ba@syzkaller.appspotmail.com
> >
> > ==================================================================
> > BUG: KASAN: slab-out-of-bounds in strlen+0x79/0x90 lib/string.c:525
> > Read of size 1 at addr ffff8881d29bdf38 by task syz-executor201/1726
> >
> > CPU: 1 PID: 1726 Comm: syz-executor201 Not tainted 5.3.0-rc2+ #25
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > Call Trace:
> > __dump_stack lib/dump_stack.c:77 [inline]
> > dump_stack+0xca/0x13e lib/dump_stack.c:113
> > print_address_description+0x6a/0x32c mm/kasan/report.c:351
> > __kasan_report.cold+0x1a/0x33 mm/kasan/report.c:482
> > kasan_report+0xe/0x12 mm/kasan/common.c:612
> > strlen+0x79/0x90 lib/string.c:525
> > strlen include/linux/string.h:281 [inline]
> > hidraw_ioctl+0x245/0xae0 drivers/hid/hidraw.c:446
> > vfs_ioctl fs/ioctl.c:46 [inline]
> > file_ioctl fs/ioctl.c:509 [inline]
> > do_vfs_ioctl+0xd2d/0x1330 fs/ioctl.c:696
> > ksys_ioctl+0x9b/0xc0 fs/ioctl.c:713
> > __do_sys_ioctl fs/ioctl.c:720 [inline]
> > __se_sys_ioctl fs/ioctl.c:718 [inline]
> > __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:718
> > do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:296
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > RIP: 0033:0x445679
> > Code: e8 5c ad 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7
> > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
> > ff 0f 83 9b cd fb ff c3 66 2e 0f 1f 84 00 00 00 00
> > RSP: 002b:00007ffc8514f3a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> > RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000445679
> > RDX: 0000000000000000 RSI: 0000000080404805 RDI: 0000000000000004
> > RBP: 00000000006d0018 R08: 000000000000000b R09: 00000000004002e0
> > R10: 000000000000000f R11: 0000000000000246 R12: 00000000004028a0
> > R13: 0000000000402930 R14: 0000000000000000 R15: 0000000000000000
> >
> > Allocated by task 0:
> > (stack is not available)
> >
> > Freed by task 0:
> > (stack is not available)
> >
> > The buggy address belongs to the object at ffff8881d29bde60
> > which belongs to the cache shmem_inode_cache of size 1168
> > The buggy address is located 216 bytes inside of
> > 1168-byte region [ffff8881d29bde60, ffff8881d29be2f0)
> > The buggy address belongs to the page:
> > page:ffffea00074a6f00 refcount:1 mapcount:0 mapping:ffff8881da115180
> > index:0x0 compound_mapcount: 0
> > flags: 0x200000000010200(slab|head)
> > raw: 0200000000010200 dead000000000100 dead000000000122 ffff8881da115180
> > raw: 0000000000000000 00000000800c000c 00000001ffffffff 0000000000000000
> > page dumped because: kasan: bad access detected
> >
> > Memory state around the buggy address:
> > ffff8881d29bde00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > ffff8881d29bde80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > > ffff8881d29bdf00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > ^
> > ffff8881d29bdf80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > ffff8881d29be000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > ==================================================================
> >
>
> Trying Alan's fix from another thread here:
>
> #syz test: https://github.com/google/kasan.git usb-fuzzer e96407b4
><
#syz test: https://github.com/google/kasan.git e96407b4
[-- Attachment #2: logitech.patch --]
[-- Type: text/x-patch, Size: 1202 bytes --]
Index: usb-devel/drivers/hid/hid-lg.c
===================================================================
--- usb-devel.orig/drivers/hid/hid-lg.c
+++ usb-devel/drivers/hid/hid-lg.c
@@ -818,7 +818,7 @@ static int lg_probe(struct hid_device *h
if (!buf) {
ret = -ENOMEM;
- goto err_free;
+ goto err_stop;
}
ret = hid_hw_raw_request(hdev, buf[0], buf, sizeof(cbuf),
@@ -850,9 +850,12 @@ static int lg_probe(struct hid_device *h
ret = lg4ff_init(hdev);
if (ret)
- goto err_free;
+ goto err_stop;
return 0;
+
+err_stop:
+ hid_hw_stop(hdev);
err_free:
kfree(drv_data);
return ret;
@@ -863,8 +866,7 @@ static void lg_remove(struct hid_device
struct lg_drv_data *drv_data = hid_get_drvdata(hdev);
if (drv_data->quirks & LG_FF4)
lg4ff_deinit(hdev);
- else
- hid_hw_stop(hdev);
+ hid_hw_stop(hdev);
kfree(drv_data);
}
Index: usb-devel/drivers/hid/hid-lg4ff.c
===================================================================
--- usb-devel.orig/drivers/hid/hid-lg4ff.c
+++ usb-devel/drivers/hid/hid-lg4ff.c
@@ -1477,7 +1477,6 @@ int lg4ff_deinit(struct hid_device *hid)
}
}
#endif
- hid_hw_stop(hid);
drv_data->device_props = NULL;
kfree(entry);
^ permalink raw reply
* Re: [PATCH v1 03/63] Input: atmel_mxt_ts - only read messages in mxt_acquire_irq() when necessary
From: Jiada Wang @ 2019-08-21 13:26 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: nick, linux-input, linux-kernel, george_davis
In-Reply-To: <20190816171622.GF121898@dtor-ws>
Hi Dmitry
On 2019/08/17 2:16, Dmitry Torokhov wrote:
> On Fri, Aug 16, 2019 at 05:28:52PM +0900, Jiada Wang wrote:
>> From: Nick Dyer <nick.dyer@itdev.co.uk>
>>
>> The workaround of reading all messages until an invalid is received is a
>> way of forcing the CHG line high, which means that when using
>> edge-triggered interrupts the interrupt can be acquired.
>>
>> With level-triggered interrupts the workaround is unnecessary.
>>
>> Also, most recent maXTouch chips have a feature called RETRIGEN which, when
>> enabled, reasserts the interrupt line every cycle if there are messages
>> waiting. This also makes the workaround unnecessary.
>>
>> Note: the RETRIGEN feature is only in some firmware versions/chips, it's
>> not valid simply to enable the bit.
>
> Instead of trying to work around of misconfiguration for IRQ/firmware,
> can we simply error out of probe if we see a level interrupt with
> !RETRIGEN firmware?
>
I think for old firmwares, which doesn't support RETRIGEN feature, this
workaround is needed, otherwise we will break all old firmwares, which
configured with edge-triggered IRQ
for recent firmwares which support RETRIGEN feature, we can fail probe,
if RETRIGEN is not enabled, and configured with edge-triggered IRQ.
what is your thought?
Thanks,
Jiada
> Thanks.
>
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in hidraw_ioctl
From: syzbot @ 2019-08-21 13:37 UTC (permalink / raw)
To: andreyknvl, benjamin.tissoires, jikos, linux-input, linux-kernel,
linux-usb, syzkaller-bugs
In-Reply-To: <CAAeHK+x-q8u_-qyc6=5QjuLAtQafOftdmK_JEFVrvzjmowf2Ow@mail.gmail.com>
Hello,
syzbot has tested the proposed patch but the reproducer still triggered
crash:
KASAN: slab-out-of-bounds Read in hidraw_ioctl
==================================================================
BUG: KASAN: slab-out-of-bounds in strlen+0x79/0x90 lib/string.c:525
Read of size 1 at addr ffff8881c8035f38 by task syz-executor.4/2833
CPU: 1 PID: 2833 Comm: syz-executor.4 Not tainted 5.3.0-rc2+ #1
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xca/0x13e lib/dump_stack.c:113
print_address_description+0x6a/0x32c mm/kasan/report.c:351
__kasan_report.cold+0x1a/0x33 mm/kasan/report.c:482
kasan_report+0xe/0x12 mm/kasan/common.c:612
strlen+0x79/0x90 lib/string.c:525
strlen include/linux/string.h:281 [inline]
hidraw_ioctl+0x245/0xae0 drivers/hid/hidraw.c:446
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:509 [inline]
do_vfs_ioctl+0xd2d/0x1330 fs/ioctl.c:696
ksys_ioctl+0x9b/0xc0 fs/ioctl.c:713
__do_sys_ioctl fs/ioctl.c:720 [inline]
__se_sys_ioctl fs/ioctl.c:718 [inline]
__x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:718
do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x459829
Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f7a68f6dc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000459829
RDX: 0000000000000000 RSI: 0000000080404805 RDI: 0000000000000004
RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f7a68f6e6d4
R13: 00000000004c21de R14: 00000000004d5620 R15: 00000000ffffffff
Allocated by task 0:
(stack is not available)
Freed by task 0:
(stack is not available)
The buggy address belongs to the object at ffff8881c8035e60
which belongs to the cache shmem_inode_cache of size 1168
The buggy address is located 216 bytes inside of
1168-byte region [ffff8881c8035e60, ffff8881c80362f0)
The buggy address belongs to the page:
page:ffffea0007200d00 refcount:1 mapcount:0 mapping:ffff8881da115180
index:0x0 compound_mapcount: 0
flags: 0x200000000010200(slab|head)
raw: 0200000000010200 dead000000000100 dead000000000122 ffff8881da115180
raw: 0000000000000000 00000000800c000c 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8881c8035e00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8881c8035e80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8881c8035f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff8881c8035f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8881c8036000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
Tested on:
commit: e96407b4 usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git
console output: https://syzkaller.appspot.com/x/log.txt?x=14f14a1e600000
kernel config: https://syzkaller.appspot.com/x/.config?x=cfa2c18fb6a8068e
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
patch: https://syzkaller.appspot.com/x/patch.diff?x=171cd95a600000
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in hidraw_ioctl
From: Andrey Konovalov @ 2019-08-21 14:10 UTC (permalink / raw)
To: syzbot
Cc: Benjamin Tissoires, Jiri Kosina, linux-input, LKML, USB list,
syzkaller-bugs
In-Reply-To: <000000000000ed58060590a0aa30@google.com>
On Wed, Aug 21, 2019 at 3:37 PM syzbot
<syzbot+5a6c4ec678a0c6ee84ba@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot has tested the proposed patch but the reproducer still triggered
> crash:
> KASAN: slab-out-of-bounds Read in hidraw_ioctl
Same here, a different bug.
>
> ==================================================================
> BUG: KASAN: slab-out-of-bounds in strlen+0x79/0x90 lib/string.c:525
> Read of size 1 at addr ffff8881c8035f38 by task syz-executor.4/2833
>
> CPU: 1 PID: 2833 Comm: syz-executor.4 Not tainted 5.3.0-rc2+ #1
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0xca/0x13e lib/dump_stack.c:113
> print_address_description+0x6a/0x32c mm/kasan/report.c:351
> __kasan_report.cold+0x1a/0x33 mm/kasan/report.c:482
> kasan_report+0xe/0x12 mm/kasan/common.c:612
> strlen+0x79/0x90 lib/string.c:525
> strlen include/linux/string.h:281 [inline]
> hidraw_ioctl+0x245/0xae0 drivers/hid/hidraw.c:446
> vfs_ioctl fs/ioctl.c:46 [inline]
> file_ioctl fs/ioctl.c:509 [inline]
> do_vfs_ioctl+0xd2d/0x1330 fs/ioctl.c:696
> ksys_ioctl+0x9b/0xc0 fs/ioctl.c:713
> __do_sys_ioctl fs/ioctl.c:720 [inline]
> __se_sys_ioctl fs/ioctl.c:718 [inline]
> __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:718
> do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:296
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x459829
> Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
> ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007f7a68f6dc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000459829
> RDX: 0000000000000000 RSI: 0000000080404805 RDI: 0000000000000004
> RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 00007f7a68f6e6d4
> R13: 00000000004c21de R14: 00000000004d5620 R15: 00000000ffffffff
>
> Allocated by task 0:
> (stack is not available)
>
> Freed by task 0:
> (stack is not available)
>
> The buggy address belongs to the object at ffff8881c8035e60
> which belongs to the cache shmem_inode_cache of size 1168
> The buggy address is located 216 bytes inside of
> 1168-byte region [ffff8881c8035e60, ffff8881c80362f0)
> The buggy address belongs to the page:
> page:ffffea0007200d00 refcount:1 mapcount:0 mapping:ffff8881da115180
> index:0x0 compound_mapcount: 0
> flags: 0x200000000010200(slab|head)
> raw: 0200000000010200 dead000000000100 dead000000000122 ffff8881da115180
> raw: 0000000000000000 00000000800c000c 00000001ffffffff 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8881c8035e00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8881c8035e80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > ffff8881c8035f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ^
> ffff8881c8035f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8881c8036000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ==================================================================
>
>
> Tested on:
>
> commit: e96407b4 usb-fuzzer: main usb gadget fuzzer driver
> git tree: https://github.com/google/kasan.git
> console output: https://syzkaller.appspot.com/x/log.txt?x=14f14a1e600000
> kernel config: https://syzkaller.appspot.com/x/.config?x=cfa2c18fb6a8068e
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> patch: https://syzkaller.appspot.com/x/patch.diff?x=171cd95a600000
>
^ permalink raw reply
* Re: [PATCH v5 10/17] net: sgi: ioc3-eth: rework skb rx handling
From: Thomas Bogendoerfer @ 2019-08-21 14:28 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Jonathan Corbet, Ralf Baechle, Paul Burton, James Hogan,
Dmitry Torokhov, Lee Jones, David S. Miller, Srinivas Kandagatla,
Alessandro Zummo, Alexandre Belloni, Greg Kroah-Hartman,
Jiri Slaby, Evgeniy Polyakov, linux-doc, linux-kernel, linux-mips,
linux-input, netdev, linux-rtc, linux-serial
In-Reply-To: <20190819165522.451f2ea2@cakuba.netronome.com>
On Mon, 19 Aug 2019 16:55:22 -0700
Jakub Kicinski <jakub.kicinski@netronome.com> wrote:
> On Mon, 19 Aug 2019 18:31:33 +0200, Thomas Bogendoerfer wrote:
> > Buffers alloacted by alloc_skb() are already cache aligned so there
> > is no need for an extra align done by ioc3_alloc_skb. And instead
> > of skb_put/skb_trim simply use one skb_put after frame size is known
> > during receive.
> [...]
> > -/* We use this to acquire receive skb's that we can DMA directly into. */
> > -
> > -#define IOC3_CACHELINE 128UL
>
> Is the cache line on the platform this driver works on 128B?
right now yes, in theory IOC3 CAD DUO cards might work in SGI O2 systems,
but the current Linux PCI implementation for O2 will not detect that card.
On X86 usually the BIOS will choke up on that cards.
> This looks like a DMA engine alignment requirement, more than an
> optimization.
that true, there are two constraints for the rx buffers, start must be aligned
to 128 bytes and a buffer must not cross a 16kbyte boundary. I was already
thinking of allocating pages and chop them up. Is there a Linux API available,
which could help for implementing this ?
I'll probably drop this patch or only change the skb_put stuff plus RX_BUF_SIZE
define.
Thomas.
--
SUSE Linux GmbH
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in hidraw_ioctl
From: Alan Stern @ 2019-08-21 14:40 UTC (permalink / raw)
To: syzbot
Cc: andreyknvl, benjamin.tissoires, jikos, linux-input,
Kernel development list, USB list, syzkaller-bugs
In-Reply-To: <000000000000ed58060590a0aa30@google.com>
On Wed, 21 Aug 2019, syzbot wrote:
> Hello,
>
> syzbot has tested the proposed patch but the reproducer still triggered
> crash:
> KASAN: slab-out-of-bounds Read in hidraw_ioctl
>
> ==================================================================
> BUG: KASAN: slab-out-of-bounds in strlen+0x79/0x90 lib/string.c:525
> Read of size 1 at addr ffff8881c8035f38 by task syz-executor.4/2833
>
> CPU: 1 PID: 2833 Comm: syz-executor.4 Not tainted 5.3.0-rc2+ #1
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0xca/0x13e lib/dump_stack.c:113
> print_address_description+0x6a/0x32c mm/kasan/report.c:351
> __kasan_report.cold+0x1a/0x33 mm/kasan/report.c:482
> kasan_report+0xe/0x12 mm/kasan/common.c:612
> strlen+0x79/0x90 lib/string.c:525
> strlen include/linux/string.h:281 [inline]
> hidraw_ioctl+0x245/0xae0 drivers/hid/hidraw.c:446
> vfs_ioctl fs/ioctl.c:46 [inline]
> file_ioctl fs/ioctl.c:509 [inline]
> do_vfs_ioctl+0xd2d/0x1330 fs/ioctl.c:696
> ksys_ioctl+0x9b/0xc0 fs/ioctl.c:713
> __do_sys_ioctl fs/ioctl.c:720 [inline]
> __se_sys_ioctl fs/ioctl.c:718 [inline]
> __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:718
> do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:296
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x459829
> Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
> ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007f7a68f6dc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000459829
> RDX: 0000000000000000 RSI: 0000000080404805 RDI: 0000000000000004
> RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 00007f7a68f6e6d4
> R13: 00000000004c21de R14: 00000000004d5620 R15: 00000000ffffffff
>
> Allocated by task 0:
> (stack is not available)
>
> Freed by task 0:
> (stack is not available)
>
> The buggy address belongs to the object at ffff8881c8035e60
> which belongs to the cache shmem_inode_cache of size 1168
> The buggy address is located 216 bytes inside of
> 1168-byte region [ffff8881c8035e60, ffff8881c80362f0)
> The buggy address belongs to the page:
> page:ffffea0007200d00 refcount:1 mapcount:0 mapping:ffff8881da115180
> index:0x0 compound_mapcount: 0
> flags: 0x200000000010200(slab|head)
> raw: 0200000000010200 dead000000000100 dead000000000122 ffff8881da115180
> raw: 0000000000000000 00000000800c000c 00000001ffffffff 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8881c8035e00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8881c8035e80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > ffff8881c8035f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ^
> ffff8881c8035f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8881c8036000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ==================================================================
>
>
> Tested on:
>
> commit: e96407b4 usb-fuzzer: main usb gadget fuzzer driver
> git tree: https://github.com/google/kasan.git
> console output: https://syzkaller.appspot.com/x/log.txt?x=14f14a1e600000
> kernel config: https://syzkaller.appspot.com/x/.config?x=cfa2c18fb6a8068e
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> patch: https://syzkaller.appspot.com/x/patch.diff?x=171cd95a600000
Get some debugging info:
#syz test: https://github.com/google/kasan.git e96407b4
Index: usb-devel/drivers/hid/hid-core.c
===================================================================
--- usb-devel.orig/drivers/hid/hid-core.c
+++ usb-devel/drivers/hid/hid-core.c
@@ -1973,6 +1973,8 @@ int hid_hw_start(struct hid_device *hdev
{
int error;
+ dev_info(&hdev->dev, "In hid_hw_start for %p\n", hdev);
+ dump_stack();
error = hdev->ll_driver->start(hdev);
if (error)
return error;
@@ -1998,6 +2000,7 @@ EXPORT_SYMBOL_GPL(hid_hw_start);
*/
void hid_hw_stop(struct hid_device *hdev)
{
+ dev_info(&hdev->dev, "In hid_hw_stop for %p\n", hdev);
hid_disconnect(hdev);
hdev->ll_driver->stop(hdev);
}
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in hidraw_ioctl
From: syzbot @ 2019-08-21 14:51 UTC (permalink / raw)
To: andreyknvl, benjamin.tissoires, jikos, linux-input, linux-kernel,
linux-usb, stern, syzkaller-bugs
In-Reply-To: <Pine.LNX.4.44L0.1908211038300.1816-100000@iolanthe.rowland.org>
Hello,
syzbot has tested the proposed patch but the reproducer still triggered
crash:
KASAN: slab-out-of-bounds Read in hidraw_ioctl
==================================================================
BUG: KASAN: slab-out-of-bounds in strlen+0x79/0x90 lib/string.c:525
Read of size 1 at addr ffff8881d619df38 by task syz-executor.5/2984
CPU: 0 PID: 2984 Comm: syz-executor.5 Not tainted 5.3.0-rc2+ #1
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xca/0x13e lib/dump_stack.c:113
print_address_description+0x6a/0x32c mm/kasan/report.c:351
__kasan_report.cold+0x1a/0x33 mm/kasan/report.c:482
kasan_report+0xe/0x12 mm/kasan/common.c:612
strlen+0x79/0x90 lib/string.c:525
strlen include/linux/string.h:281 [inline]
hidraw_ioctl+0x245/0xae0 drivers/hid/hidraw.c:446
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:509 [inline]
do_vfs_ioctl+0xd2d/0x1330 fs/ioctl.c:696
ksys_ioctl+0x9b/0xc0 fs/ioctl.c:713
__do_sys_ioctl fs/ioctl.c:720 [inline]
__se_sys_ioctl fs/ioctl.c:718 [inline]
__x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:718
do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x459829
Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f19881acc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000459829
RDX: 0000000000000000 RSI: 0000000080404805 RDI: 0000000000000004
RBP: 000000000075bfc8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f19881ad6d4
R13: 00000000004c21de R14: 00000000004d5620 R15: 00000000ffffffff
Allocated by task 1607:
save_stack+0x1b/0x80 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_kmalloc mm/kasan/common.c:487 [inline]
__kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:460
kmalloc include/linux/slab.h:552 [inline]
syslog_print kernel/printk/printk.c:1346 [inline]
do_syslog kernel/printk/printk.c:1519 [inline]
do_syslog+0x540/0x1380 kernel/printk/printk.c:1493
kmsg_read+0x8a/0xb0 fs/proc/kmsg.c:40
proc_reg_read+0x1c1/0x280 fs/proc/inode.c:223
__vfs_read+0x76/0x100 fs/read_write.c:425
vfs_read+0x1ea/0x430 fs/read_write.c:461
ksys_read+0x127/0x250 fs/read_write.c:587
do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 1607:
save_stack+0x1b/0x80 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_slab_free+0x130/0x180 mm/kasan/common.c:449
slab_free_hook mm/slub.c:1423 [inline]
slab_free_freelist_hook mm/slub.c:1470 [inline]
slab_free mm/slub.c:3012 [inline]
kfree+0xe4/0x2f0 mm/slub.c:3953
syslog_print kernel/printk/printk.c:1405 [inline]
do_syslog kernel/printk/printk.c:1519 [inline]
do_syslog+0x1098/0x1380 kernel/printk/printk.c:1493
kmsg_read+0x8a/0xb0 fs/proc/kmsg.c:40
proc_reg_read+0x1c1/0x280 fs/proc/inode.c:223
__vfs_read+0x76/0x100 fs/read_write.c:425
vfs_read+0x1ea/0x430 fs/read_write.c:461
ksys_read+0x127/0x250 fs/read_write.c:587
do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff8881d619db00
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 56 bytes to the right of
1024-byte region [ffff8881d619db00, ffff8881d619df00)
The buggy address belongs to the page:
page:ffffea0007586700 refcount:1 mapcount:0 mapping:ffff8881da002280
index:0x0 compound_mapcount: 0
flags: 0x200000000010200(slab|head)
raw: 0200000000010200 dead000000000100 dead000000000122 ffff8881da002280
raw: 0000000000000000 00000000000e000e 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8881d619de00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8881d619de80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8881d619df00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff8881d619df80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8881d619e000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
Tested on:
commit: e96407b4 usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git
console output: https://syzkaller.appspot.com/x/log.txt?x=1138542e600000
kernel config: https://syzkaller.appspot.com/x/.config?x=cfa2c18fb6a8068e
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
patch: https://syzkaller.appspot.com/x/patch.diff?x=1197b996600000
^ permalink raw reply
* Re: [PATCH 4/4] input/vmmouse: Update the backdoor call with support for new instructions
From: Thomas Hellström (VMware) @ 2019-08-21 15:48 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-kernel, pv-drivers, Thomas Hellstrom, linux-input,
Doug Covelli
In-Reply-To: <20190821050925.GA566@penguin>
On 8/21/19 7:09 AM, Dmitry Torokhov wrote:
> On Sun, Aug 18, 2019 at 04:33:16PM +0200, Thomas Hellström (VMware) wrote:
>> From: Thomas Hellstrom <thellstrom@vmware.com>
>>
>> Use the definition provided by include/asm/vmware.h
>>
>> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>> Cc: <linux-input@vger.kernel.org>
>> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
>> Reviewed-by: Doug Covelli <dcovelli@vmware.com>
> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>
> Please feel free to merge with the rest of the patches introducing
> VMWARE_HYPERCALL.
Thanks, Dmitry!
I have a version 2 of the patch were the only difference is that edx is
initialized to zero which is default for vmcall / vmmcall. Can I use
your ack for that one as well?
Thanks,
Thomas
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in hidraw_ioctl
From: Alan Stern @ 2019-08-21 15:53 UTC (permalink / raw)
To: syzbot
Cc: andreyknvl, benjamin.tissoires, jikos, linux-input, linux-kernel,
linux-usb, syzkaller-bugs
In-Reply-To: <000000000000940ec30590a1b35e@google.com>
On Wed, 21 Aug 2019, syzbot wrote:
> Hello,
>
> syzbot has tested the proposed patch but the reproducer still triggered
> crash:
> KASAN: slab-out-of-bounds Read in hidraw_ioctl
>
> ==================================================================
> BUG: KASAN: slab-out-of-bounds in strlen+0x79/0x90 lib/string.c:525
> Read of size 1 at addr ffff8881d619df38 by task syz-executor.5/2984
>
> CPU: 0 PID: 2984 Comm: syz-executor.5 Not tainted 5.3.0-rc2+ #1
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0xca/0x13e lib/dump_stack.c:113
> print_address_description+0x6a/0x32c mm/kasan/report.c:351
> __kasan_report.cold+0x1a/0x33 mm/kasan/report.c:482
> kasan_report+0xe/0x12 mm/kasan/common.c:612
> strlen+0x79/0x90 lib/string.c:525
> strlen include/linux/string.h:281 [inline]
> hidraw_ioctl+0x245/0xae0 drivers/hid/hidraw.c:446
> vfs_ioctl fs/ioctl.c:46 [inline]
> file_ioctl fs/ioctl.c:509 [inline]
> do_vfs_ioctl+0xd2d/0x1330 fs/ioctl.c:696
> ksys_ioctl+0x9b/0xc0 fs/ioctl.c:713
> __do_sys_ioctl fs/ioctl.c:720 [inline]
> __se_sys_ioctl fs/ioctl.c:718 [inline]
> __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:718
> do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:296
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x459829
> Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
> ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007f19881acc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000459829
> RDX: 0000000000000000 RSI: 0000000080404805 RDI: 0000000000000004
> RBP: 000000000075bfc8 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 00007f19881ad6d4
> R13: 00000000004c21de R14: 00000000004d5620 R15: 00000000ffffffff
Looks like a test is missing in hidraw_ioctl.
Alan Stern
#syz test: https://github.com/google/kasan.git e96407b4
Index: usb-devel/drivers/hid/hidraw.c
===================================================================
--- usb-devel.orig/drivers/hid/hidraw.c
+++ usb-devel/drivers/hid/hidraw.c
@@ -370,7 +370,7 @@ static long hidraw_ioctl(struct file *fi
mutex_lock(&minors_lock);
dev = hidraw_table[minor];
- if (!dev) {
+ if (!dev || !dev->exist) {
ret = -ENODEV;
goto out;
}
^ permalink raw reply
* Re: [PATCH 4/4] input/vmmouse: Update the backdoor call with support for new instructions
From: Dmitry Torokhov @ 2019-08-21 16:03 UTC (permalink / raw)
To: Thomas Hellström (VMware)
Cc: linux-kernel, pv-drivers, Thomas Hellstrom, linux-input,
Doug Covelli
In-Reply-To: <027a55d6-ab26-ef9c-bd89-93a38f96160b@shipmail.org>
On Wed, Aug 21, 2019 at 05:48:23PM +0200, Thomas Hellström (VMware) wrote:
> On 8/21/19 7:09 AM, Dmitry Torokhov wrote:
> > On Sun, Aug 18, 2019 at 04:33:16PM +0200, Thomas Hellström (VMware) wrote:
> > > From: Thomas Hellstrom <thellstrom@vmware.com>
> > >
> > > Use the definition provided by include/asm/vmware.h
> > >
> > > Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > > Cc: <linux-input@vger.kernel.org>
> > > Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
> > > Reviewed-by: Doug Covelli <dcovelli@vmware.com>
> > Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> >
> > Please feel free to merge with the rest of the patches introducing
> > VMWARE_HYPERCALL.
>
> Thanks, Dmitry!
>
> I have a version 2 of the patch were the only difference is that edx is
> initialized to zero which is default for vmcall / vmmcall. Can I use your
> ack for that one as well?
Yes, sure.
--
Dmitry
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in hidraw_ioctl
From: syzbot @ 2019-08-21 16:13 UTC (permalink / raw)
To: andreyknvl, benjamin.tissoires, jikos, linux-input, linux-kernel,
linux-usb, stern, syzkaller-bugs
In-Reply-To: <Pine.LNX.4.44L0.1908211152230.1816-100000@iolanthe.rowland.org>
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger
crash:
Reported-and-tested-by:
syzbot+5a6c4ec678a0c6ee84ba@syzkaller.appspotmail.com
Tested on:
commit: e96407b4 usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git
kernel config: https://syzkaller.appspot.com/x/.config?x=cfa2c18fb6a8068e
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
patch: https://syzkaller.appspot.com/x/patch.diff?x=13dca42e600000
Note: testing is done by a robot and is best-effort only.
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in hidraw_ioctl
From: Alan Stern @ 2019-08-21 16:24 UTC (permalink / raw)
To: Andrey Konovalov
Cc: syzbot, Benjamin Tissoires, Jiri Kosina, linux-input, LKML,
USB list, syzkaller-bugs
In-Reply-To: <CAAeHK+xQc5Ce6TwtERTmQ+6qSbuAmGikxCU5SNTdcDAynDEiig@mail.gmail.com>
On Wed, 21 Aug 2019, Andrey Konovalov wrote:
> On Wed, Aug 21, 2019 at 3:37 PM syzbot
> <syzbot+5a6c4ec678a0c6ee84ba@syzkaller.appspotmail.com> wrote:
> >
> > Hello,
> >
> > syzbot has tested the proposed patch but the reproducer still triggered
> > crash:
> > KASAN: slab-out-of-bounds Read in hidraw_ioctl
>
> Same here, a different bug.
It looks like I've got the fix for both these bugs. Testing now...
> > Tested on:
> >
> > commit: e96407b4 usb-fuzzer: main usb gadget fuzzer driver
> > git tree: https://github.com/google/kasan.git
> > console output: https://syzkaller.appspot.com/x/log.txt?x=14f14a1e600000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=cfa2c18fb6a8068e
> > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > patch: https://syzkaller.appspot.com/x/patch.diff?x=171cd95a600000
Why don't these patch-test reports include the dashboard link? It sure
would be handy to have a copy of it here.
Alan Stern
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox