<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent sightings.</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent sightings.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sat, 09 May 2026 20:50:55 +0000</lastBuildDate>
    <item>
      <title>0e8b2ec2-61b8-4f33-842e-ad0d9999519e</title>
      <link>https://vulnerability.circl.lu/sighting/0e8b2ec2-61b8-4f33-842e-ad0d9999519e/export</link>
      <description>{"uuid": "0e8b2ec2-61b8-4f33-842e-ad0d9999519e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2023-52886", "type": "seen", "source": "https://t.me/cvedetector/927", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2023-52886 - Apache USB Core Kernel Hub Port Information Leak\", \n  \"Content\": \"CVE ID : CVE-2023-52886 \nPublished : July 16, 2024, 10:15 a.m. | 32\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nUSB: core: Fix race by not overwriting udev-&amp;gt;descriptor in hub_port_init()  \n  \nSyzbot reported an out-of-bounds read in sysfs.c:read_descriptors():  \n  \nBUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883  \nRead of size 8 at addr ffff88801e78b8c8 by task udevd/5011  \n  \nCPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0  \nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023  \nCall Trace:  \n   \n __dump_stack lib/dump_stack.c:88 [inline]  \n dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106  \n print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351  \n print_report mm/kasan/report.c:462 [inline]  \n kasan_report+0x11c/0x130 mm/kasan/report.c:572  \n read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883  \n...  \nAllocated by task 758:  \n...  \n __do_kmalloc_node mm/slab_common.c:966 [inline]  \n __kmalloc+0x5e/0x190 mm/slab_common.c:979  \n kmalloc include/linux/slab.h:563 [inline]  \n kzalloc include/linux/slab.h:680 [inline]  \n usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887  \n usb_enumerate_device drivers/usb/core/hub.c:2407 [inline]  \n usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545  \n  \nAs analyzed by Khazhy Kumykov, the cause of this bug is a race between  \nread_descriptors() and hub_port_init(): The first routine uses a field  \nin udev-&amp;gt;descriptor, not expecting it to change, while the second  \noverwrites it.  \n  \nPrior to commit 45bf39f8df7f (\"USB: core: Don't hold device lock while  \nreading the \"descriptors\" sysfs file\") this race couldn't occur,  \nbecause the routines were mutually exclusive thanks to the device  \nlocking.  Removing that locking from read_descriptors() exposed it to  \nthe race.  \n  \nThe best way to fix the bug is to keep hub_port_init() from changing  \nudev-&amp;gt;descriptor once udev has been initialized and registered.  \nDrivers expect the descriptors stored in the kernel to be immutable;  \nwe should not undermine this expectation.  In fact, this change should  \nhave been made long ago.  \n  \nSo now hub_port_init() will take an additional argument, specifying a  \nbuffer in which to store the device descriptor it reads.  (If udev has  \nnot yet been initialized, the buffer pointer will be NULL and then  \nhub_port_init() will store the device descriptor in udev as before.)  \nThis eliminates the data race responsible for the out-of-bounds read.  \n  \nThe changes to hub_port_init() appear more extensive than they really  \nare, because of indentation changes resulting from an attempt to avoid  \nwriting to other parts of the usb_device structure after it has been  \ninitialized.  Similar changes should be made to the code that reads  \nthe BOS descriptor, but that can be handled in a separate patch later  \non.  This patch is sufficient to fix the bug found by syzbot. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"16 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-16T12:55:41.000000Z"}</description>
      <content:encoded>{"uuid": "0e8b2ec2-61b8-4f33-842e-ad0d9999519e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2023-52886", "type": "seen", "source": "https://t.me/cvedetector/927", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2023-52886 - Apache USB Core Kernel Hub Port Information Leak\", \n  \"Content\": \"CVE ID : CVE-2023-52886 \nPublished : July 16, 2024, 10:15 a.m. | 32\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nUSB: core: Fix race by not overwriting udev-&amp;gt;descriptor in hub_port_init()  \n  \nSyzbot reported an out-of-bounds read in sysfs.c:read_descriptors():  \n  \nBUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883  \nRead of size 8 at addr ffff88801e78b8c8 by task udevd/5011  \n  \nCPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0  \nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023  \nCall Trace:  \n   \n __dump_stack lib/dump_stack.c:88 [inline]  \n dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106  \n print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351  \n print_report mm/kasan/report.c:462 [inline]  \n kasan_report+0x11c/0x130 mm/kasan/report.c:572  \n read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883  \n...  \nAllocated by task 758:  \n...  \n __do_kmalloc_node mm/slab_common.c:966 [inline]  \n __kmalloc+0x5e/0x190 mm/slab_common.c:979  \n kmalloc include/linux/slab.h:563 [inline]  \n kzalloc include/linux/slab.h:680 [inline]  \n usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887  \n usb_enumerate_device drivers/usb/core/hub.c:2407 [inline]  \n usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545  \n  \nAs analyzed by Khazhy Kumykov, the cause of this bug is a race between  \nread_descriptors() and hub_port_init(): The first routine uses a field  \nin udev-&amp;gt;descriptor, not expecting it to change, while the second  \noverwrites it.  \n  \nPrior to commit 45bf39f8df7f (\"USB: core: Don't hold device lock while  \nreading the \"descriptors\" sysfs file\") this race couldn't occur,  \nbecause the routines were mutually exclusive thanks to the device  \nlocking.  Removing that locking from read_descriptors() exposed it to  \nthe race.  \n  \nThe best way to fix the bug is to keep hub_port_init() from changing  \nudev-&amp;gt;descriptor once udev has been initialized and registered.  \nDrivers expect the descriptors stored in the kernel to be immutable;  \nwe should not undermine this expectation.  In fact, this change should  \nhave been made long ago.  \n  \nSo now hub_port_init() will take an additional argument, specifying a  \nbuffer in which to store the device descriptor it reads.  (If udev has  \nnot yet been initialized, the buffer pointer will be NULL and then  \nhub_port_init() will store the device descriptor in udev as before.)  \nThis eliminates the data race responsible for the out-of-bounds read.  \n  \nThe changes to hub_port_init() appear more extensive than they really  \nare, because of indentation changes resulting from an attempt to avoid  \nwriting to other parts of the usb_device structure after it has been  \ninitialized.  Similar changes should be made to the code that reads  \nthe BOS descriptor, but that can be handled in a separate patch later  \non.  This patch is sufficient to fix the bug found by syzbot. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"16 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-16T12:55:41.000000Z"}</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/sighting/0e8b2ec2-61b8-4f33-842e-ad0d9999519e/export</guid>
      <pubDate>Tue, 16 Jul 2024 12:55:41 +0000</pubDate>
    </item>
    <item>
      <title>a9d56470-5022-4de3-a11a-e1cc5cb875de</title>
      <link>https://vulnerability.circl.lu/sighting/a9d56470-5022-4de3-a11a-e1cc5cb875de/export</link>
      <description>{"uuid": "a9d56470-5022-4de3-a11a-e1cc5cb875de", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2023-52886", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}</description>
      <content:encoded>{"uuid": "a9d56470-5022-4de3-a11a-e1cc5cb875de", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2023-52886", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/sighting/a9d56470-5022-4de3-a11a-e1cc5cb875de/export</guid>
      <pubDate>Wed, 03 Dec 2025 14:14:49 +0000</pubDate>
    </item>
  </channel>
</rss>
