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 <[email protected]> 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/[email protected]?part=1
