linux-kernel - Re: [PATCH v2] HID: rate-limit hid

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <446o7on5-8s99-01p9-rq78-4qo9pqo3qpr0@xreary.bet>
Date: Fri, 20 Jun 2025 09:09:37 +0200 (CEST)
From: Jiri Kosina <jikos@...nel.org>
To: Li Chen <me@...ux.beauty>
cc: Benjamin Tissoires <bentiss@...nel.org>, linux-input@...r.kernel.org, 
    linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] HID: rate-limit hid_warn to prevent log flooding

On Fri, 20 Jun 2025, Li Chen wrote:

> From: Li Chen <chenl311@...natelecom.cn>
> 
> Syzkaller can create many uhid devices that trigger
> repeated warnings like:
> 
>   "hid-generic xxxx: unknown main item tag 0x0"
> 
> These messages can flood the system log, especially if a crash occurs
> (e.g., with a slow UART console, leading to soft lockups). To mitigate
> this, convert `hid_warn()` to use `dev_warn_ratelimited()`.
> 
> This helps reduce log noise and improves system stability under fuzzing
> or faulty device scenarios.
> 
> Signed-off-by: Li Chen <chenl311@...natelecom.cn>
> ---
> Changelog:
> 
> v2: Introduce hid_warn_ratelimited to rate-limit the specified log.
> 
>  drivers/hid/hid-core.c | 2 +-
>  include/linux/hid.h    | 2 ++
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index b348d0464314c..aaba7164a8c9a 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -661,7 +661,7 @@ static int hid_parser_main(struct hid_parser *parser, struct hid_item *item)
>  			item->tag <= HID_MAIN_ITEM_TAG_RESERVED_MAX)
>  			hid_warn(parser->device, "reserved main item tag 0x%x\n", item->tag);
>  		else
> -			hid_warn(parser->device, "unknown main item tag 0x%x\n", item->tag);
> +			hid_warn_ratelimited(parser->device, "unknown main item tag 0x%x\n", item->tag);
>  		ret = 0;

While I agree in principle that we shouldn't be flooding dmesg in case the 
report descriptor is completely bogus, I think we should be more 
consistent then.

I am pretty sure syzkaller produce report descriptors that will emit flood 
of "reserved main item tag", but you don't seem to be addresing that case?

Thanks,

-- 
Jiri Kosina
SUSE Labs