Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: fix use-after-free in device_for_each_child()<br /> <br /> Syzbot has reported the following KASAN splat:<br /> <br /> BUG: KASAN: slab-use-after-free in device_for_each_child+0x18f/0x1a0<br /> Read of size 8 at addr ffff88801f605308 by task kbnepd bnep0/4980<br /> <br /> CPU: 0 UID: 0 PID: 4980 Comm: kbnepd bnep0 Not tainted 6.12.0-rc4-00161-gae90f6a6170d #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x100/0x190<br /> ? device_for_each_child+0x18f/0x1a0<br /> print_report+0x13a/0x4cb<br /> ? __virt_addr_valid+0x5e/0x590<br /> ? __phys_addr+0xc6/0x150<br /> ? device_for_each_child+0x18f/0x1a0<br /> kasan_report+0xda/0x110<br /> ? device_for_each_child+0x18f/0x1a0<br /> ? __pfx_dev_memalloc_noio+0x10/0x10<br /> device_for_each_child+0x18f/0x1a0<br /> ? __pfx_device_for_each_child+0x10/0x10<br /> pm_runtime_set_memalloc_noio+0xf2/0x180<br /> netdev_unregister_kobject+0x1ed/0x270<br /> unregister_netdevice_many_notify+0x123c/0x1d80<br /> ? __mutex_trylock_common+0xde/0x250<br /> ? __pfx_unregister_netdevice_many_notify+0x10/0x10<br /> ? trace_contention_end+0xe6/0x140<br /> ? __mutex_lock+0x4e7/0x8f0<br /> ? __pfx_lock_acquire.part.0+0x10/0x10<br /> ? rcu_is_watching+0x12/0xc0<br /> ? unregister_netdev+0x12/0x30<br /> unregister_netdevice_queue+0x30d/0x3f0<br /> ? __pfx_unregister_netdevice_queue+0x10/0x10<br /> ? __pfx_down_write+0x10/0x10<br /> unregister_netdev+0x1c/0x30<br /> bnep_session+0x1fb3/0x2ab0<br /> ? __pfx_bnep_session+0x10/0x10<br /> ? __pfx_lock_release+0x10/0x10<br /> ? __pfx_woken_wake_function+0x10/0x10<br /> ? __kthread_parkme+0x132/0x200<br /> ? __pfx_bnep_session+0x10/0x10<br /> ? kthread+0x13a/0x370<br /> ? __pfx_bnep_session+0x10/0x10<br /> kthread+0x2b7/0x370<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x48/0x80<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> Allocated by task 4974:<br /> kasan_save_stack+0x30/0x50<br /> kasan_save_track+0x14/0x30<br /> __kasan_kmalloc+0xaa/0xb0<br /> __kmalloc_noprof+0x1d1/0x440<br /> hci_alloc_dev_priv+0x1d/0x2820<br /> __vhci_create_device+0xef/0x7d0<br /> vhci_write+0x2c7/0x480<br /> vfs_write+0x6a0/0xfc0<br /> ksys_write+0x12f/0x260<br /> do_syscall_64+0xc7/0x250<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Freed by task 4979:<br /> kasan_save_stack+0x30/0x50<br /> kasan_save_track+0x14/0x30<br /> kasan_save_free_info+0x3b/0x60<br /> __kasan_slab_free+0x4f/0x70<br /> kfree+0x141/0x490<br /> hci_release_dev+0x4d9/0x600<br /> bt_host_release+0x6a/0xb0<br /> device_release+0xa4/0x240<br /> kobject_put+0x1ec/0x5a0<br /> put_device+0x1f/0x30<br /> vhci_release+0x81/0xf0<br /> __fput+0x3f6/0xb30<br /> task_work_run+0x151/0x250<br /> do_exit+0xa79/0x2c30<br /> do_group_exit+0xd5/0x2a0<br /> get_signal+0x1fcd/0x2210<br /> arch_do_signal_or_restart+0x93/0x780<br /> syscall_exit_to_user_mode+0x140/0x290<br /> do_syscall_64+0xd4/0x250<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> In &amp;#39;hci_conn_del_sysfs()&amp;#39;, &amp;#39;device_unregister()&amp;#39; may be called when<br /> an underlying (kobject) reference counter is greater than 1. This<br /> means that reparenting (happened when the device is actually freed)<br /> is delayed and, during that delay, parent controller device (hciX)<br /> may be deleted. Since the latter may create a dangling pointer to<br /> freed parent, avoid that scenario by reparenting to NULL explicitly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: 6fire: Release resources at card release<br /> <br /> The current 6fire code tries to release the resources right after the<br /> call of usb6fire_chip_abort(). But at this moment, the card object<br /> might be still in use (as we&amp;#39;re calling snd_card_free_when_closed()).<br /> <br /> For avoid potential UAFs, move the release of resources to the card&amp;#39;s<br /> private_free instead of the manual call of usb6fire_chip_destroy() at<br /> the USB disconnect callback.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: caiaq: Use snd_card_free_when_closed() at disconnection<br /> <br /> The USB disconnect callback is supposed to be short and not too-long<br /> waiting. OTOH, the current code uses snd_card_free() at<br /> disconnection, but this waits for the close of all used fds, hence it<br /> can take long. It eventually blocks the upper layer USB ioctls, which<br /> may trigger a soft lockup.<br /> <br /> An easy workaround is to replace snd_card_free() with<br /> snd_card_free_when_closed(). This variant returns immediately while<br /> the release of resources is done asynchronously by the card device<br /> release at the last close.<br /> <br /> This patch also splits the code to the disconnect and the free phases;<br /> the former is called immediately at the USB disconnect callback while<br /> the latter is called from the card destructor.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: us122l: Use snd_card_free_when_closed() at disconnection<br /> <br /> The USB disconnect callback is supposed to be short and not too-long<br /> waiting. OTOH, the current code uses snd_card_free() at<br /> disconnection, but this waits for the close of all used fds, hence it<br /> can take long. It eventually blocks the upper layer USB ioctls, which<br /> may trigger a soft lockup.<br /> <br /> An easy workaround is to replace snd_card_free() with<br /> snd_card_free_when_closed(). This variant returns immediately while<br /> the release of resources is done asynchronously by the card device<br /> release at the last close.<br /> <br /> The loop of us122l-&gt;mmap_count check is dropped as well. The check is<br /> useless for the asynchronous operation with *_when_closed().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usx2y: Use snd_card_free_when_closed() at disconnection<br /> <br /> The USB disconnect callback is supposed to be short and not too-long<br /> waiting. OTOH, the current code uses snd_card_free() at<br /> disconnection, but this waits for the close of all used fds, hence it<br /> can take long. It eventually blocks the upper layer USB ioctls, which<br /> may trigger a soft lockup.<br /> <br /> An easy workaround is to replace snd_card_free() with<br /> snd_card_free_when_closed(). This variant returns immediately while<br /> the release of resources is done asynchronously by the card device<br /> release at the last close.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: kvm: Fix out-of-bounds array access<br /> <br /> In kvm_riscv_vcpu_sbi_init() the entry-&gt;ext_idx can contain an<br /> out-of-bound index. This is used as a special marker for the base<br /> extensions, that cannot be disabled. However, when traversing the<br /> extensions, that special marker is not checked prior indexing the<br /> array.<br /> <br /> Add an out-of-bounds check to the function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/s390: Implement blocking domain<br /> <br /> This fixes a crash when surprise hot-unplugging a PCI device. This crash<br /> happens because during hot-unplug __iommu_group_set_domain_nofail()<br /> attaching the default domain fails when the platform no longer<br /> recognizes the device as it has already been removed and we end up with<br /> a NULL domain pointer and UAF. This is exactly the case referred to in<br /> the second comment in __iommu_device_set_domain() and just as stated<br /> there if we can instead attach the blocking domain the UAF is prevented<br /> as this can handle the already removed device. Implement the blocking<br /> domain to use this handling. With this change, the crash is fixed but<br /> we still hit a warning attempting to change DMA ownership on a blocked<br /> device.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: fix file-backed mounts over FUSE<br /> <br /> syzbot reported a null-ptr-deref in fuse_read_args_fill:<br /> fuse_read_folio+0xb0/0x100 fs/fuse/file.c:905<br /> filemap_read_folio+0xc6/0x2a0 mm/filemap.c:2367<br /> do_read_cache_folio+0x263/0x5c0 mm/filemap.c:3825<br /> read_mapping_folio include/linux/pagemap.h:1011 [inline]<br /> erofs_bread+0x34d/0x7e0 fs/erofs/data.c:41<br /> erofs_read_superblock fs/erofs/super.c:281 [inline]<br /> erofs_fc_fill_super+0x2b9/0x2500 fs/erofs/super.c:625<br /> <br /> Unlike most filesystems, some network filesystems and FUSE need<br /> unavoidable valid `file` pointers for their read I/Os [1].<br /> Anyway, those use cases need to be supported too.<br /> <br /> [1] https://docs.kernel.org/filesystems/vfs.html

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Fix the qp flush warnings in req<br /> <br /> When the qp is in error state, the status of WQEs in the queue should be<br /> set to error. Or else the following will appear.<br /> <br /> [ 920.617269] WARNING: CPU: 1 PID: 21 at drivers/infiniband/sw/rxe/rxe_comp.c:756 rxe_completer+0x989/0xcc0 [rdma_rxe]<br /> [ 920.617744] Modules linked in: rnbd_client(O) rtrs_client(O) rtrs_core(O) rdma_ucm rdma_cm iw_cm ib_cm crc32_generic rdma_rxe ip6_udp_tunnel udp_tunnel ib_uverbs ib_core loop brd null_blk ipv6<br /> [ 920.618516] CPU: 1 PID: 21 Comm: ksoftirqd/1 Tainted: G O 6.1.113-storage+ #65<br /> [ 920.618986] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> [ 920.619396] RIP: 0010:rxe_completer+0x989/0xcc0 [rdma_rxe]<br /> [ 920.619658] Code: 0f b6 84 24 3a 02 00 00 41 89 84 24 44 04 00 00 e9 2a f7 ff ff 39 ca bb 03 00 00 00 b8 0e 00 00 00 48 0f 45 d8 e9 15 f7 ff ff 0b e9 cb f8 ff ff 41 bf f5 ff ff ff e9 08 f8 ff ff 49 8d bc 24<br /> [ 920.620482] RSP: 0018:ffff97b7c00bbc38 EFLAGS: 00010246<br /> [ 920.620817] RAX: 0000000000000000 RBX: 000000000000000c RCX: 0000000000000008<br /> [ 920.621183] RDX: ffff960dc396ebc0 RSI: 0000000000005400 RDI: ffff960dc4e2fbac<br /> [ 920.621548] RBP: 0000000000000000 R08: 0000000000000001 R09: ffffffffac406450<br /> [ 920.621884] R10: ffffffffac4060c0 R11: 0000000000000001 R12: ffff960dc4e2f800<br /> [ 920.622254] R13: ffff960dc4e2f928 R14: ffff97b7c029c580 R15: 0000000000000000<br /> [ 920.622609] FS: 0000000000000000(0000) GS:ffff960ef7d00000(0000) knlGS:0000000000000000<br /> [ 920.622979] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 920.623245] CR2: 00007fa056965e90 CR3: 00000001107f1000 CR4: 00000000000006e0<br /> [ 920.623680] Call Trace:<br /> [ 920.623815] <br /> [ 920.623933] ? __warn+0x79/0xc0<br /> [ 920.624116] ? rxe_completer+0x989/0xcc0 [rdma_rxe]<br /> [ 920.624356] ? report_bug+0xfb/0x150<br /> [ 920.624594] ? handle_bug+0x3c/0x60<br /> [ 920.624796] ? exc_invalid_op+0x14/0x70<br /> [ 920.624976] ? asm_exc_invalid_op+0x16/0x20<br /> [ 920.625203] ? rxe_completer+0x989/0xcc0 [rdma_rxe]<br /> [ 920.625474] ? rxe_completer+0x329/0xcc0 [rdma_rxe]<br /> [ 920.625749] rxe_do_task+0x80/0x110 [rdma_rxe]<br /> [ 920.626037] rxe_requester+0x625/0xde0 [rdma_rxe]<br /> [ 920.626310] ? rxe_cq_post+0xe2/0x180 [rdma_rxe]<br /> [ 920.626583] ? do_complete+0x18d/0x220 [rdma_rxe]<br /> [ 920.626812] ? rxe_completer+0x1a3/0xcc0 [rdma_rxe]<br /> [ 920.627050] rxe_do_task+0x80/0x110 [rdma_rxe]<br /> [ 920.627285] tasklet_action_common.constprop.0+0xa4/0x120<br /> [ 920.627522] handle_softirqs+0xc2/0x250<br /> [ 920.627728] ? sort_range+0x20/0x20<br /> [ 920.627942] run_ksoftirqd+0x1f/0x30<br /> [ 920.628158] smpboot_thread_fn+0xc7/0x1b0<br /> [ 920.628334] kthread+0xd6/0x100<br /> [ 920.628504] ? kthread_complete_and_exit+0x20/0x20<br /> [ 920.628709] ret_from_fork+0x1f/0x30<br /> [ 920.628892]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: CPPC: Fix possible null-ptr-deref for cppc_get_cpu_cost()<br /> <br /> cpufreq_cpu_get_raw() may return NULL if the cpu is not in<br /> policy-&gt;cpus cpu mask and it will cause null pointer dereference,<br /> so check NULL for cppc_get_cpu_cost().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: CPPC: Fix possible null-ptr-deref for cpufreq_cpu_get_raw()<br /> <br /> cpufreq_cpu_get_raw() may return NULL if the cpu is not in<br /> policy-&gt;cpus cpu mask and it will cause null pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> unicode: Fix utf8_load() error path<br /> <br /> utf8_load() requests the symbol "utf8_data_table" and then checks if the<br /> requested UTF-8 version is supported. If it&amp;#39;s unsupported, it tries to<br /> put the data table using symbol_put(). If an unsupported version is<br /> requested, symbol_put() fails like this:<br /> <br /> kernel BUG at kernel/module/main.c:786!<br /> RIP: 0010:__symbol_put+0x93/0xb0<br /> Call Trace:<br /> <br /> ? __die_body.cold+0x19/0x27<br /> ? die+0x2e/0x50<br /> ? do_trap+0xca/0x110<br /> ? do_error_trap+0x65/0x80<br /> ? __symbol_put+0x93/0xb0<br /> ? exc_invalid_op+0x51/0x70<br /> ? __symbol_put+0x93/0xb0<br /> ? asm_exc_invalid_op+0x1a/0x20<br /> ? __pfx_cmp_name+0x10/0x10<br /> ? __symbol_put+0x93/0xb0<br /> ? __symbol_put+0x62/0xb0<br /> utf8_load+0xf8/0x150<br /> <br /> That happens because symbol_put() expects the unique string that<br /> identify the symbol, instead of a pointer to the loaded symbol. Fix that<br /> by using such string.