CVE-2025-38592

{"id": "CVE-2025-38592", "cveTags": [], "metrics": {}, "published": "2025-08-19T17:15:36.930", "references": [{"url": "https://git.kernel.org/stable/c/7af4d7b53502286c6cf946d397ab183e76d14820", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/8c021ad797f9171d015cf0a932a3fbe5232190f5", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/efd55f6a59449f8d4e4953f12c177aa902b7451f", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Awaiting Analysis", "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_devcd_dump: fix out-of-bounds via dev_coredumpv\n\nCurrently both dev_coredumpv and skb_put_data in hci_devcd_dump use\nhdev->dump.head. However, dev_coredumpv can free the buffer. From\ndev_coredumpm_timeout documentation, which is used by dev_coredumpv:\n\n > Creates a new device coredump for the given device. If a previous one hasn't\n > been read yet, the new coredump is discarded. The data lifetime is determined\n > by the device coredump framework and when it is no longer needed the @free\n > function will be called to free the data.\n\nIf the data has not been read by the userspace yet, dev_coredumpv will\ndiscard new buffer, freeing hdev->dump.head. This leads to\nvmalloc-out-of-bounds error when skb_put_data tries to access\nhdev->dump.head.\n\nA crash report from syzbot illustrates this:\n\n ==================================================================\n BUG: KASAN: vmalloc-out-of-bounds in skb_put_data\n include/linux/skbuff.h:2752 [inline]\n BUG: KASAN: vmalloc-out-of-bounds in hci_devcd_dump+0x142/0x240\n net/bluetooth/coredump.c:258\n Read of size 140 at addr ffffc90004ed5000 by task kworker/u9:2/5844\n\n CPU: 1 UID: 0 PID: 5844 Comm: kworker/u9:2 Not tainted\n 6.14.0-syzkaller-10892-g4e82c87058f4 #0 PREEMPT(full)\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS\n Google 02/12/2025\n Workqueue: hci0 hci_devcd_timeout\n Call Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:408 [inline]\n print_report+0xc3/0x670 mm/kasan/report.c:521\n kasan_report+0xe0/0x110 mm/kasan/report.c:634\n check_region_inline mm/kasan/generic.c:183 [inline]\n kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189\n __asan_memcpy+0x23/0x60 mm/kasan/shadow.c:105\n skb_put_data include/linux/skbuff.h:2752 [inline]\n hci_devcd_dump+0x142/0x240 net/bluetooth/coredump.c:258\n hci_devcd_timeout+0xb5/0x2e0 net/bluetooth/coredump.c:413\n process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238\n process_scheduled_works kernel/workqueue.c:3319 [inline]\n worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400\n kthread+0x3c2/0x780 kernel/kthread.c:464\n ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245\n </TASK>\n\n The buggy address ffffc90004ed5000 belongs to a vmalloc virtual mapping\n Memory state around the buggy address:\n ffffc90004ed4f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ffffc90004ed4f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n >ffffc90004ed5000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ^\n ffffc90004ed5080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ffffc90004ed5100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ==================================================================\n\nTo avoid this issue, reorder dev_coredumpv to be called after\nskb_put_data that does not free the data."}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: hci_devcd_dump: corrige fuera de los l\u00edmites mediante dev_coredumpv Actualmente, tanto dev_coredumpv como skb_put_data en hci_devcd_dump usan hdev-&gt;dump.head. Sin embargo, dev_coredumpv puede liberar el b\u00fafer. De la documentaci\u00f3n de dev_coredumpm_timeout, que es utilizada por dev_coredumpv: &gt; Crea un nuevo volcado de memoria del dispositivo para el dispositivo dado. Si a\u00fan no se ha le\u00eddo uno anterior, se descarta el nuevo volcado de memoria. La vida \u00fatil de los datos est\u00e1 determinada por el marco de volcado de memoria del dispositivo y cuando ya no se necesitan, se llamar\u00e1 a la funci\u00f3n @free para liberar los datos. Si el espacio de usuario a\u00fan no ha le\u00eddo los datos, dev_coredumpv descartar\u00e1 el nuevo b\u00fafer, liberando hdev-&gt;dump.head. Esto genera un error vmalloc-out-of-bounds cuando skb_put_data intenta acceder a hdev-&gt;dump.head. Un informe de fallos de syzbot ilustra esto: ======================================================================= ERROR: KASAN: vmalloc-out-of-bounds in skb_put_data include/linux/skbuff.h:2752 [inline] BUG: KASAN: vmalloc-out-of-bounds in hci_devcd_dump+0x142/0x240 net/bluetooth/coredump.c:258 Read of size 140 at addr ffffc90004ed5000 by task kworker/u9:2/5844 CPU: 1 UID: 0 PID: 5844 Comm: kworker/u9:2 Not tainted 6.14.0-syzkaller-10892-g4e82c87058f4 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Workqueue: hci0 hci_devcd_timeout Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 __asan_memcpy+0x23/0x60 mm/kasan/shadow.c:105 skb_put_data include/linux/skbuff.h:2752 [inline] hci_devcd_dump+0x142/0x240 net/bluetooth/coredump.c:258 hci_devcd_timeout+0xb5/0x2e0 net/bluetooth/coredump.c:413 process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [inline] worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 The buggy address ffffc90004ed5000 belongs to a vmalloc virtual mapping Memory state around the buggy address: ffffc90004ed4f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90004ed4f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 &gt;ffffc90004ed5000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90004ed5080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90004ed5100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ================================================================== Para evitar este problema, reordene dev_coredumpv para que se llame despu\u00e9s de skb_put_data que no libera los datos."}], "lastModified": "2025-08-20T14:40:17.713", "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}