Page 271 of 1915 results (0.015 seconds)

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btrtl: fix out of bounds memory access The problem is detected by KASAN. btrtl driver uses private hci data to store 'struct btrealtek_data'. If btrtl driver is used with btusb, then memory for private hci data is allocated in btusb. But no private data is allocated after hci_dev, when btrtl is used with hci_h5. This commit adds memory allocation for hci_h5 case. ================================================================== BUG: KASAN: slab-out-of-bounds in btrtl_initialize+0x6cc/0x958 [btrtl] Write of size 8 at addr ffff00000f5a5748 by task kworker/u9:0/76 Hardware name: Pine64 PinePhone (1.2) (DT) Workqueue: hci0 hci_power_on [bluetooth] Call trace: dump_backtrace+0x9c/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x48/0x60 print_report+0xf8/0x5d8 kasan_report+0x90/0xd0 __asan_store8+0x9c/0xc0 [btrtl] h5_btrtl_setup+0xd0/0x2f8 [hci_uart] h5_setup+0x50/0x80 [hci_uart] hci_uart_setup+0xd4/0x260 [hci_uart] hci_dev_open_sync+0x1cc/0xf68 [bluetooth] hci_dev_do_open+0x34/0x90 [bluetooth] hci_power_on+0xc4/0x3c8 [bluetooth] process_one_work+0x328/0x6f0 worker_thread+0x410/0x778 kthread+0x168/0x178 ret_from_fork+0x10/0x20 Allocated by task 53: kasan_save_stack+0x3c/0x68 kasan_save_track+0x20/0x40 kasan_save_alloc_info+0x68/0x78 __kasan_kmalloc+0xd4/0xd8 __kmalloc+0x1b4/0x3b0 hci_alloc_dev_priv+0x28/0xa58 [bluetooth] hci_uart_register_device+0x118/0x4f8 [hci_uart] h5_serdev_probe+0xf4/0x178 [hci_uart] serdev_drv_probe+0x54/0xa0 really_probe+0x254/0x588 __driver_probe_device+0xc4/0x210 driver_probe_device+0x64/0x160 __driver_attach_async_helper+0x88/0x158 async_run_entry_fn+0xd0/0x388 process_one_work+0x328/0x6f0 worker_thread+0x410/0x778 kthread+0x168/0x178 ret_from_fork+0x10/0x20 Last potentially related work creation: kasan_save_stack+0x3c/0x68 __kasan_record_aux_stack+0xb0/0x150 kasan_record_aux_stack_noalloc+0x14/0x20 __queue_work+0x33c/0x960 queue_work_on+0x98/0xc0 hci_recv_frame+0xc8/0x1e8 [bluetooth] h5_complete_rx_pkt+0x2c8/0x800 [hci_uart] h5_rx_payload+0x98/0xb8 [hci_uart] h5_recv+0x158/0x3d8 [hci_uart] hci_uart_receive_buf+0xa0/0xe8 [hci_uart] ttyport_receive_buf+0xac/0x178 flush_to_ldisc+0x130/0x2c8 process_one_work+0x328/0x6f0 worker_thread+0x410/0x778 kthread+0x168/0x178 ret_from_fork+0x10/0x20 Second to last potentially related work creation: kasan_save_stack+0x3c/0x68 __kasan_record_aux_stack+0xb0/0x150 kasan_record_aux_stack_noalloc+0x14/0x20 __queue_work+0x788/0x960 queue_work_on+0x98/0xc0 __hci_cmd_sync_sk+0x23c/0x7a0 [bluetooth] __hci_cmd_sync+0x24/0x38 [bluetooth] btrtl_initialize+0x760/0x958 [btrtl] h5_btrtl_setup+0xd0/0x2f8 [hci_uart] h5_setup+0x50/0x80 [hci_uart] hci_uart_setup+0xd4/0x260 [hci_uart] hci_dev_open_sync+0x1cc/0xf68 [bluetooth] hci_dev_do_open+0x34/0x90 [bluetooth] hci_power_on+0xc4/0x3c8 [bluetooth] process_one_work+0x328/0x6f0 worker_thread+0x410/0x778 kthread+0x168/0x178 ret_from_fork+0x10/0x20 ================================================================== En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: Bluetooth: btrtl: arreglar acceso a memoria fuera de los límites El problema es detectado por KASAN. El controlador btrtl utiliza datos privados de hci para almacenar 'struct btrealtek_data'. Si se utiliza el controlador btrtl con btusb, entonces la memoria para los datos privados de hci se asigna en btusb. Pero no se asignan datos privados después de hci_dev, cuando se usa btrtl con hci_h5. • https://git.kernel.org/stable/c/5b355944b19011011dd3fd4187444c5ff1d76ad2 https://git.kernel.org/stable/c/dd163fa34c483f1674aa2510accce11a224f649e https://git.kernel.org/stable/c/2f232bc389a4f5943c40733582f9edf77b89e499 https://git.kernel.org/stable/c/0c657e641df1e77d6087688190f632cad9c0439b https://git.kernel.org/stable/c/de4e88ec58c4202efd1f02eebb4939bbf6945358 •

CVSS: -EPSS: 0%CPEs: 11EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: Fix possible buffer overflow struct hci_dev_info has a fixed size name[8] field so in the event that hdev->name is bigger than that strcpy would attempt to write past its size, so this fixes this problem by switching to use strscpy. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: hci_core: soluciona un posible desbordamiento del búfer struct hci_dev_info tiene un campo de nombre de tamaño fijo[8], por lo que en caso de que hdev->name sea mayor que strcpy intentaría escribir más allá su tamaño, por lo que esto soluciona este problema cambiando al uso de strscpy. • https://git.kernel.org/stable/c/194ab82c1ea187512ff2f822124bd05b63fc9f76 https://git.kernel.org/stable/c/b48595f5b1c6e81e06e164e7d2b7a30b1776161e https://git.kernel.org/stable/c/ffb060b136dd75a033ced0fc0aed2882c02e8b56 https://git.kernel.org/stable/c/bbec1724519ecd9c468d1186a8f30b7567175bfb https://git.kernel.org/stable/c/a55d53ad5c86aee3f6da50ee73626008997673fa https://git.kernel.org/stable/c/dcda165706b9fbfd685898d46a6749d7d397e0c0 https://git.kernel.org/stable/c/d9ce7d438366431e5688be98d8680336ce0a0f8d https://git.kernel.org/stable/c/5558f4312dca43cebfb9a1aab3d632be9 •

CVSS: 5.3EPSS: 0%CPEs: 7EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: af_bluetooth: Fix deadlock Attemting to do sock_lock on .recvmsg may cause a deadlock as shown bellow, so instead of using sock_sock this uses sk_receive_queue.lock on bt_sock_ioctl to avoid the UAF: INFO: task kworker/u9:1:121 blocked for more than 30 seconds. Not tainted 6.7.6-lemon #183 Workqueue: hci0 hci_rx_work Call Trace: <TASK> __schedule+0x37d/0xa00 schedule+0x32/0xe0 __lock_sock+0x68/0xa0 ? __pfx_autoremove_wake_function+0x10/0x10 lock_sock_nested+0x43/0x50 l2cap_sock_recv_cb+0x21/0xa0 l2cap_recv_frame+0x55b/0x30a0 ? psi_task_switch+0xeb/0x270 ? finish_task_switch.isra.0+0x93/0x2a0 hci_rx_work+0x33a/0x3f0 process_one_work+0x13a/0x2f0 worker_thread+0x2f0/0x410 ? __pfx_worker_thread+0x10/0x10 kthread+0xe0/0x110 ? • https://git.kernel.org/stable/c/37f71e2c9f515834841826f4eb68ec33cfb2a1ff https://git.kernel.org/stable/c/1d576c3a5af850bf11fbd103f9ba11aa6d6061fb https://git.kernel.org/stable/c/2e07e8348ea454615e268222ae3fc240421be768 https://git.kernel.org/stable/c/db1b14eec8c61a20374de9f9c2ddc6c9406a8c42 https://git.kernel.org/stable/c/2b16d960c79abc397f102c3d23d30005b68cb036 https://git.kernel.org/stable/c/cb8adca52f306563d958a863bb0cbae9c184d1ae https://git.kernel.org/stable/c/64be3c6154886200708da0dfe259705fb992416c https://git.kernel.org/stable/c/817e8138ce86001b2fa5c63d6ede756e2 • CWE-833: Deadlock •

CVSS: 7.8EPSS: 0%CPEs: 7EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix DEVMAP_HASH overflow check on 32-bit arches The devmap code allocates a number hash buckets equal to the next power of two of the max_entries value provided when creating the map. When rounding up to the next power of two, the 32-bit variable storing the number of buckets can overflow, and the code checks for overflow by checking if the truncated 32-bit value is equal to 0. However, on 32-bit arches the rounding up itself can overflow mid-way through, because it ends up doing a left-shift of 32 bits on an unsigned long value. If the size of an unsigned long is four bytes, this is undefined behaviour, so there is no guarantee that we'll end up with a nice and tidy 0-value at the end. Syzbot managed to turn this into a crash on arm32 by creating a DEVMAP_HASH with max_entries > 0x80000000 and then trying to update it. Fix this by moving the overflow check to before the rounding up operation. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: corrige la verificación de desbordamiento de DEVMAP_HASH en arcos de 32 bits. • https://git.kernel.org/stable/c/6f9d451ab1a33728adb72d7ff66a7b374d665176 https://git.kernel.org/stable/c/225da02acdc97af01b6bc6ce1a3e5362bf01d3fb https://git.kernel.org/stable/c/c826502bed93970f2fd488918a7b8d5f1d30e2e3 https://git.kernel.org/stable/c/edf7990baa48de5097daa9ac02e06cb4c798a737 https://git.kernel.org/stable/c/250051acc21f9d4c5c595e4fcb55986ea08c4691 https://git.kernel.org/stable/c/22079b3a423382335f47d9ed32114e6c9fe88d7c https://git.kernel.org/stable/c/e89386f62ce9a9ab9a94835a9890883c23d9d52c https://git.kernel.org/stable/c/281d464a34f540de166cee74b723e97ac • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer •

CVSS: 7.8EPSS: 0%CPEs: 9EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix hashtab overflow check on 32-bit arches The hashtab code relies on roundup_pow_of_two() to compute the number of hash buckets, and contains an overflow check by checking if the resulting value is 0. However, on 32-bit arches, the roundup code itself can overflow by doing a 32-bit left-shift of an unsigned long value, which is undefined behaviour, so it is not guaranteed to truncate neatly. This was triggered by syzbot on the DEVMAP_HASH type, which contains the same check, copied from the hashtab code. So apply the same fix to hashtab, by moving the overflow check to before the roundup. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: corrige la comprobación de desbordamiento de hashtab en arcos de 32 bits. • https://git.kernel.org/stable/c/daaf427c6ab392bedcd018e326b2ffa1e1110cd6 https://git.kernel.org/stable/c/33ec04cadb77605b71d9298311919303d390c4d5 https://git.kernel.org/stable/c/92c81fbb3ed2e0dfc33a4183a67135e1ab566ace https://git.kernel.org/stable/c/64f00b4df0597590b199b62a37a165473bf658a6 https://git.kernel.org/stable/c/3b08cfc65f07b1132c1979d73f014ae6e04de55d https://git.kernel.org/stable/c/a83fdaeaea3677b83a53f72ace2d73a19bcd6d93 https://git.kernel.org/stable/c/8435f0961bf3dc65e204094349bd9aeaac1f8868 https://git.kernel.org/stable/c/d817f0d34d927f2deb17dadbfe212c9a6 • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer •