CVE-2026-63896

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: composite: fix integer underflow in WebUSB GET_URL handling<br /> <br /> The WebUSB GET_URL handler in composite_setup() narrows<br /> landing_page_length to fit the host-supplied wLength using<br /> <br /> landing_page_length = w_length<br /> - WEBUSB_URL_DESCRIPTOR_HEADER_LENGTH + landing_page_offset;<br /> <br /> If wLength is smaller than WEBUSB_URL_DESCRIPTOR_HEADER_LENGTH the<br /> unsigned subtraction wraps, and the subsequent<br /> <br /> memcpy(url_descriptor-&gt;URL,<br /> cdev-&gt;landing_page + landing_page_offset,<br /> landing_page_length - landing_page_offset);<br /> <br /> ends up copying close to UINT_MAX bytes from cdev-&gt;landing_page into<br /> cdev-&gt;req-&gt;buf. KASAN reports a slab-out-of-bounds in composite_setup<br /> on the kmalloc-2k gadget_info allocation, and FORTIFY_SOURCE traps the<br /> memcpy as a 4294967293-byte field-spanning write into<br /> url_descriptor-&gt;URL (size 252).<br /> <br /> A USB host can reach this from a single SETUP packet against any<br /> gadget that has webusb/use=1 and a landingPage configured.<br /> <br /> Handle the small-wLength case before the math: when the host requested<br /> fewer bytes than the URL descriptor header, only the header is<br /> meaningful and no URL bytes need to be copied. Setting<br /> landing_page_length to landing_page_offset makes the existing memcpy a<br /> no-op and leaves the descriptor returned to the host unchanged for all<br /> larger wLength values.