Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <34d52b94-6fb2-10d1-575e-df4eeaf54ca7@alu.unizg.hr>
Date:   Mon, 8 May 2023 19:26:10 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.10.0
Subject: Re: [BUG] Kmemleak, possibly hiddev_connect(), in 6.3.0+ torvalds
 tree commit gfc4354c6e5c2
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Mirsad Goran Todorovac <mirsad.goran.todorovac@alu.hr>
Cc:     linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-input@vger.kernel.org,
        Benjamin Tissoires <benjamin.tissoires@redhat.com>,
        Jiri Kosina <jikos@kernel.org>
References: <f64b17fa-d509-ad30-6e8d-e4c979818047@alu.unizg.hr>
 <2023050824-juiciness-catching-9290@gregkh>
 <2023050854-collage-dreamt-660c@gregkh>
Content-Language: en-US
From:   Mirsad Goran Todorovac <mirsad.goran.todorovac@alu.hr>
In-Reply-To: <2023050854-collage-dreamt-660c@gregkh>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 08. 05. 2023. 16:01, Greg Kroah-Hartman wrote:

> On Mon, May 08, 2023 at 08:51:55AM +0200, 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@hostname:/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?
> No, wait, it's still there, I was looking at a development branch of
> mine that isn't sent upstream yet.  And syzbot just reported the same
> thing:
> 	https://lore.kernel.org/r/00000000000058d15f05fb264013@google.com
>
> So something's wrong here, let me dig into it tomorrow when I get a
> chance...

Hi,

I can confirm that the leak is still present in 6.4-rc1:

root@host:/home/user# cat /sys/kernel/debug/kmemleak
unreferenced object 0xffff9e6b57bd8ea0 (size 96):
   comm "systemd-udevd", pid 322, jiffies 4294892584 (age 123.516s)
   hex dump (first 32 bytes):
     a4 90 ee b6 ff ff ff ff 00 00 00 00 00 00 00 00 ................
     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
   backtrace:
     [<ffffffffb5ba74be>] __kmem_cache_alloc_node+0x22e/0x2b0
     [<ffffffffb5b27b6e>] kmalloc_trace+0x2e/0xa0
     [<ffffffffb6154959>] class_create+0x29/0x80
     [<ffffffffb62812a4>] usb_register_dev+0x1d4/0x2e0
     [<ffffffffc066ebab>] hiddev_connect+0x11b/0x1b0 [usbhid]
     [<ffffffffc0629d4e>] hid_connect+0xde/0x580 [hid]
     [<ffffffffc062a24c>] hid_hw_start+0x4c/0x70 [hid]
     [<ffffffffc05e8092>] hid_generic_probe+0x32/0x40 [hid_generic]
     [<ffffffffc062a450>] hid_device_probe+0x100/0x170 [hid]
     [<ffffffffb6152602>] really_probe+0x1b2/0x420
     [<ffffffffb61528fe>] __driver_probe_device+0x7e/0x170
     [<ffffffffb6152a23>] driver_probe_device+0x23/0xa0
     [<ffffffffb6152cc8>] __driver_attach+0xe8/0x1e0
     [<ffffffffb614fe6e>] bus_for_each_dev+0x7e/0xd0
     [<ffffffffb6151da2>] driver_attach+0x22/0x30
     [<ffffffffb61513f0>] bus_add_driver+0x120/0x220
unreferenced object 0xffff9e6b58d75800 (size 512):
   comm "systemd-udevd", pid 322, jiffies 4294892584 (age 123.516s)
   hex dump (first 32 bytes):
     00 58 d7 58 6b 9e ff ff 00 58 d7 58 6b 9e ff ff .X.Xk....X.Xk...
     00 00 00 00 00 00 00 00 a4 90 ee b6 ff ff ff ff ................
   backtrace:
     [<ffffffffb5ba74be>] __kmem_cache_alloc_node+0x22e/0x2b0
     [<ffffffffb5b27b6e>] kmalloc_trace+0x2e/0xa0
     [<ffffffffb6154812>] class_register+0x32/0x140
     [<ffffffffb6154974>] class_create+0x44/0x80
     [<ffffffffb62812a4>] usb_register_dev+0x1d4/0x2e0
     [<ffffffffc066ebab>] hiddev_connect+0x11b/0x1b0 [usbhid]
     [<ffffffffc0629d4e>] hid_connect+0xde/0x580 [hid]
     [<ffffffffc062a24c>] hid_hw_start+0x4c/0x70 [hid]
     [<ffffffffc05e8092>] hid_generic_probe+0x32/0x40 [hid_generic]
     [<ffffffffc062a450>] hid_device_probe+0x100/0x170 [hid]
     [<ffffffffb6152602>] really_probe+0x1b2/0x420
     [<ffffffffb61528fe>] __driver_probe_device+0x7e/0x170
     [<ffffffffb6152a23>] driver_probe_device+0x23/0xa0
     [<ffffffffb6152cc8>] __driver_attach+0xe8/0x1e0
     [<ffffffffb614fe6e>] bus_for_each_dev+0x7e/0xd0
     [<ffffffffb6151da2>] driver_attach+0x22/0x30
root@host:/home/user#

Would you need a bisect on this one? Maybe it would help.

Best regards,
Mirsad