Re: [PATCH] fbdev: udlfb: validate vendor descriptor items

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Out-of-bounds read in `dev_info` using `%11ph` format specifier, potentially causing a kernel panic.
--

commit 8284c1b4f9c66a4ef2393d5e8aa1741e7ef14d8a
Author: Pengpeng Hou <pengpeng@iscas.ac.cn>

fbdev: udlfb: validate vendor descriptor items

This commit validates key-length-value items inside the DisplayLink vendor
descriptor in dlfb_parse_vendor_descriptor(). It ensures each item contains
its key, length, and declared value bytes before reading item-specific fields.

> diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c
> index fdbb8671a810c..e78d6f95c9c5c 100644
> --- a/drivers/video/fbdev/udlfb.c
> +++ b/drivers/video/fbdev/udlfb.c
> @@ -1586,19 +1586,29 @@ static int dlfb_parse_vendor_descriptor(struct dlfb_data *dlfb,

[Severity: High]
This isn't a bug introduced by this patch, but earlier in
dlfb_parse_vendor_descriptor(), there is a potential out-of-bounds read:

	if (total_len > 5) {
		dev_info(&intf->dev,
			 "vendor descriptor length: %d data: %11ph\n",
			 total_len, desc);

Can this unconditionally read 11 bytes even if total_len is as small as 6?

If a malicious USB device stalls the initial control request for the vendor
descriptor, and instead provides it as a 6-byte extra descriptor within the
configuration descriptor blob, desc will point directly into the USB core's
rawdescriptors allocation, and total_len will be 6.

Because the %11ph format specifier unconditionally reads exactly 11 bytes,
would this read 5 bytes out of bounds, potentially causing a kernel panic if
the buffer ends at a page boundary?

>  		desc += 5; /* the fixed header we've already parsed */
>  
>  		while (desc < desc_end) {

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260706093038.80131-1-pengpeng@iscas.ac.cn?part=1