| 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
| ||
|
Message-ID: <2024051737-CVE-2024-35825-9e41@gregkh> Date: Fri, 17 May 2024 15:27:37 +0200 From: Greg Kroah-Hartman <gregkh@...uxfoundation.org> To: linux-cve-announce@...r.kernel.org Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org> Subject: CVE-2024-35825: usb: gadget: ncm: Fix handling of zero block length packets Description =========== In the Linux kernel, the following vulnerability has been resolved: usb: gadget: ncm: Fix handling of zero block length packets While connecting to a Linux host with CDC_NCM_NTB_DEF_SIZE_TX set to 65536, it has been observed that we receive short packets, which come at interval of 5-10 seconds sometimes and have block length zero but still contain 1-2 valid datagrams present. According to the NCM spec: "If wBlockLength = 0x0000, the block is terminated by a short packet. In this case, the USB transfer must still be shorter than dwNtbInMaxSize or dwNtbOutMaxSize. If exactly dwNtbInMaxSize or dwNtbOutMaxSize bytes are sent, and the size is a multiple of wMaxPacketSize for the given pipe, then no ZLP shall be sent. wBlockLength= 0x0000 must be used with extreme care, because of the possibility that the host and device may get out of sync, and because of test issues. wBlockLength = 0x0000 allows the sender to reduce latency by starting to send a very large NTB, and then shortening it when the sender discovers that there’s not sufficient data to justify sending a large NTB" However, there is a potential issue with the current implementation, as it checks for the occurrence of multiple NTBs in a single giveback by verifying if the leftover bytes to be processed is zero or not. If the block length reads zero, we would process the same NTB infintely because the leftover bytes is never zero and it leads to a crash. Fix this by bailing out if block length reads zero. The Linux kernel CVE team has assigned CVE-2024-35825 to this issue. Affected and fixed versions =========================== Issue introduced in 4.19.297 with commit ff3ba016263e and fixed in 4.19.312 with commit e2dbfea520e6 Issue introduced in 5.4.259 with commit e7ca00f35d8a and fixed in 5.4.274 with commit a766761d206e Issue introduced in 5.10.199 with commit 17c653d4913b and fixed in 5.10.215 with commit ef846cdbd100 Issue introduced in 5.15.136 with commit 7014807fb7ef and fixed in 5.15.154 with commit 92b051b87658 Issue introduced in 6.1.59 with commit 49fbc18378ae and fixed in 6.1.84 with commit 7664ee8bd803 Issue introduced in 6.6 with commit 427694cfaafa and fixed in 6.6.24 with commit a0f77b5d6067 Issue introduced in 6.6 with commit 427694cfaafa and fixed in 6.7.12 with commit 6b2c73111a25 Issue introduced in 6.6 with commit 427694cfaafa and fixed in 6.8 with commit f90ce1e04cbc Issue introduced in 4.14.328 with commit 5bdf93a2f545 Issue introduced in 6.5.8 with commit 4bf1a9d20c65 Please see https://www.kernel.org for a full list of currently supported kernel versions by the kernel community. Unaffected versions might change over time as fixes are backported to older supported kernel versions. The official CVE entry at https://cve.org/CVERecord/?id=CVE-2024-35825 will be updated if fixes are backported, please check that for the most up to date information about this issue. Affected files ============== The file(s) affected by this issue are: drivers/usb/gadget/function/f_ncm.c Mitigation ========== The Linux kernel CVE team recommends that you update to the latest stable kernel version for this, and many other bugfixes. Individual changes are never tested alone, but rather are part of a larger kernel release. Cherry-picking individual commits is not recommended or supported by the Linux kernel community at all. If however, updating to the latest release is impossible, the individual changes to resolve this issue can be found at these commits: https://git.kernel.org/stable/c/e2dbfea520e60d58e0c498ba41bde10452257779 https://git.kernel.org/stable/c/a766761d206e7c36d7526e0ae749949d17ca582c https://git.kernel.org/stable/c/ef846cdbd100f7f9dc045e8bcd7fe4b3a3713c03 https://git.kernel.org/stable/c/92b051b87658df7649ffcdef522593f21a2b296b https://git.kernel.org/stable/c/7664ee8bd80309b90d53488b619764f0a057f2b7 https://git.kernel.org/stable/c/a0f77b5d6067285b8eca0ee3bd1e448a6258026f https://git.kernel.org/stable/c/6b2c73111a252263807b7598682663dc33aa4b4c https://git.kernel.org/stable/c/f90ce1e04cbcc76639d6cba0fdbd820cd80b3c70
Powered by blists - more mailing lists