[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <30daba6b-e264-5141-221f-5daed103b4ce@alu.unizg.hr>
Date: Mon, 8 May 2023 09:40:33 +0200
From: Mirsad Todorovac <mirsad.todorovac@....unizg.hr>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Mirsad Goran Todorovac <mirsad.goran.todorovac@....hr>
Cc: linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-input@...r.kernel.org,
Benjamin Tissoires <benjamin.tissoires@...hat.com>,
Jiri Kosina <jikos@...nel.org>
Subject: Re: [BUG] Kmemleak, possibly hiddev_connect(), in 6.3.0+ torvalds
tree commit gfc4354c6e5c2
On 5/8/23 08:51, Greg Kroah-Hartman wrote:
> On Mon, May 08, 2023 at 08:30:07AM +0200, Mirsad Goran Todorovac wrote:
>> Hi,
>>
>> There seems to be a kernel memory leak in the USB keyboard driver.
>>
>> The leaked memory allocs are 96 and 512 bytes.
>>
>> The platform is Ubuntu 22.04 LTS on a assembled AMD Ryzen 9 with X670E PG
>> Lightning mobo,
>> and Genius SlimStar i220 GK-080012 keyboard.
>>
>> (Logitech M100 HID mouse is not affected by the bug.)
>>
>> BIOS is:
>>
>> *-firmware
>> description: BIOS
>> vendor: American Megatrends International, LLC.
>> physical id: 0
>> version: 1.21
>> date: 04/26/2023
>> size: 64KiB
>>
>> The kernel is 6.3.0-torvalds-<id>-13466-gfc4354c6e5c2.
>>
>> The keyboard is recognised as Chicony:
>>
>> *-usb
>> description: Keyboard
>> product: CHICONY USB Keyboard
>> vendor: CHICONY
>> physical id: 2
>> bus info: usb@5:2
>> logical name: input35
>> logical name: /dev/input/event4
>> logical name: input35::capslock
>> logical name: input35::numlock
>> logical name: input35::scrolllock
>> logical name: input36
>> logical name: /dev/input/event5
>> logical name: input37
>> logical name: /dev/input/event6
>> logical name: input38
>> logical name: /dev/input/event8
>> version: 2.30
>> capabilities: usb-2.00 usb
>> configuration: driver=usbhid maxpower=100mA
>> speed=1Mbit/s
>>
>> The bug is easily reproduced by unplugging the USB keyboard, waiting about a
>> couple of seconds,
>> and then reconnect and scan for memory leaks twice.
>>
>> The kmemleak log is as follows [edited privacy info]:
>>
>> root@...tname:/home/username# cat /sys/kernel/debug/kmemleak
>> unreferenced object 0xffff8dd020037c00 (size 96):
>> comm "systemd-udevd", pid 435, jiffies 4294892550 (age 8909.356s)
>> hex dump (first 32 bytes):
>> 5d 8e 4e b9 ff ff ff ff 00 00 00 00 00 00 00 00 ].N.............
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> backtrace:
>> [<ffffffffb81a74be>] __kmem_cache_alloc_node+0x22e/0x2b0
>> [<ffffffffb8127b6e>] kmalloc_trace+0x2e/0xa0
>> [<ffffffffb87543d9>] class_create+0x29/0x80
>> [<ffffffffb8880d24>] usb_register_dev+0x1d4/0x2e0
>
> As the call to class_create() in this path is now gone in 6.4-rc1, can
> you retry that release to see if this is still there or not?
Certainly, but probably not before 6 PM UTC+02.
Best regards,
Mirsad
--
Mirsad Goran Todorovac
Sistem inženjer
Grafički fakultet | Akademija likovnih umjetnosti
Sveučilište u Zagrebu
System engineer
Faculty of Graphic Arts | Academy of Fine Arts
University of Zagreb, Republic of Croatia
"What’s this thing suddenly coming towards me very fast? Very very fast.
... I wonder if it will be friends with me?"
Powered by blists - more mailing lists