Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/irdma: Fix data race on CQP request done<br /> <br /> KCSAN detects a data race on cqp_request-&gt;request_done memory location<br /> which is accessed locklessly in irdma_handle_cqp_op while being<br /> updated in irdma_cqp_ce_handler.<br /> <br /> Annotate lockless intent with READ_ONCE/WRITE_ONCE to avoid any<br /> compiler optimizations like load fusing and/or KCSAN warning.<br /> <br /> [222808.417128] BUG: KCSAN: data-race in irdma_cqp_ce_handler [irdma] / irdma_wait_event [irdma]<br /> <br /> [222808.417532] write to 0xffff8e44107019dc of 1 bytes by task 29658 on cpu 5:<br /> [222808.417610] irdma_cqp_ce_handler+0x21e/0x270 [irdma]<br /> [222808.417725] cqp_compl_worker+0x1b/0x20 [irdma]<br /> [222808.417827] process_one_work+0x4d1/0xa40<br /> [222808.417835] worker_thread+0x319/0x700<br /> [222808.417842] kthread+0x180/0x1b0<br /> [222808.417852] ret_from_fork+0x22/0x30<br /> <br /> [222808.417918] read to 0xffff8e44107019dc of 1 bytes by task 29688 on cpu 1:<br /> [222808.417995] irdma_wait_event+0x1e2/0x2c0 [irdma]<br /> [222808.418099] irdma_handle_cqp_op+0xae/0x170 [irdma]<br /> [222808.418202] irdma_cqp_cq_destroy_cmd+0x70/0x90 [irdma]<br /> [222808.418308] irdma_puda_dele_rsrc+0x46d/0x4d0 [irdma]<br /> [222808.418411] irdma_rt_deinit_hw+0x179/0x1d0 [irdma]<br /> [222808.418514] irdma_ib_dealloc_device+0x11/0x40 [irdma]<br /> [222808.418618] ib_dealloc_device+0x2a/0x120 [ib_core]<br /> [222808.418823] __ib_unregister_device+0xde/0x100 [ib_core]<br /> [222808.418981] ib_unregister_device+0x22/0x40 [ib_core]<br /> [222808.419142] irdma_ib_unregister_device+0x70/0x90 [irdma]<br /> [222808.419248] i40iw_close+0x6f/0xc0 [irdma]<br /> [222808.419352] i40e_client_device_unregister+0x14a/0x180 [i40e]<br /> [222808.419450] i40iw_remove+0x21/0x30 [irdma]<br /> [222808.419554] auxiliary_bus_remove+0x31/0x50<br /> [222808.419563] device_remove+0x69/0xb0<br /> [222808.419572] device_release_driver_internal+0x293/0x360<br /> [222808.419582] driver_detach+0x7c/0xf0<br /> [222808.419592] bus_remove_driver+0x8c/0x150<br /> [222808.419600] driver_unregister+0x45/0x70<br /> [222808.419610] auxiliary_driver_unregister+0x16/0x30<br /> [222808.419618] irdma_exit_module+0x18/0x1e [irdma]<br /> [222808.419733] __do_sys_delete_module.constprop.0+0x1e2/0x310<br /> [222808.419745] __x64_sys_delete_module+0x1b/0x30<br /> [222808.419755] do_syscall_64+0x39/0x90<br /> [222808.419763] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> [222808.419829] value changed: 0x01 -&gt; 0x03

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bcache: fixup btree_cache_wait list damage<br /> <br /> We get a kernel crash about "list_add corruption. next-&gt;prev should be<br /> prev (ffff9c801bc01210), but was ffff9c77b688237c.<br /> (next=ffffae586d8afe68)."<br /> <br /> crash&gt; struct list_head 0xffff9c801bc01210<br /> struct list_head {<br /> next = 0xffffae586d8afe68,<br /> prev = 0xffffae586d8afe68<br /> }<br /> crash&gt; struct list_head 0xffff9c77b688237c<br /> struct list_head {<br /> next = 0x0,<br /> prev = 0x0<br /> }<br /> crash&gt; struct list_head 0xffffae586d8afe68<br /> struct list_head struct: invalid kernel virtual address: ffffae586d8afe68 type: "gdb_readmem_callback"<br /> Cannot access memory at address 0xffffae586d8afe68<br /> <br /> [230469.019492] Call Trace:<br /> [230469.032041] prepare_to_wait+0x8a/0xb0<br /> [230469.044363] ? bch_btree_keys_free+0x6c/0xc0 [escache]<br /> [230469.056533] mca_cannibalize_lock+0x72/0x90 [escache]<br /> [230469.068788] mca_alloc+0x2ae/0x450 [escache]<br /> [230469.080790] bch_btree_node_get+0x136/0x2d0 [escache]<br /> [230469.092681] bch_btree_check_thread+0x1e1/0x260 [escache]<br /> [230469.104382] ? finish_wait+0x80/0x80<br /> [230469.115884] ? bch_btree_check_recurse+0x1a0/0x1a0 [escache]<br /> [230469.127259] kthread+0x112/0x130<br /> [230469.138448] ? kthread_flush_work_fn+0x10/0x10<br /> [230469.149477] ret_from_fork+0x35/0x40<br /> <br /> bch_btree_check_thread() and bch_dirty_init_thread() may call<br /> mca_cannibalize() to cannibalize other cached btree nodes. Only one thread<br /> can do it at a time, so the op of other threads will be added to the<br /> btree_cache_wait list.<br /> <br /> We must call finish_wait() to remove op from btree_cache_wait before free<br /> it&amp;#39;s memory address. Otherwise, the list will be damaged. Also should call<br /> bch_cannibalize_unlock() to release the btree_cache_alloc_lock and wake_up<br /> other waiters.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid10: fix memleak of md thread<br /> <br /> In raid10_run(), if setup_conf() succeed and raid10_run() failed before<br /> setting &amp;#39;mddev-&gt;thread&amp;#39;, then in the error path &amp;#39;conf-&gt;thread&amp;#39; is not<br /> freed.<br /> <br /> Fix the problem by setting &amp;#39;mddev-&gt;thread&amp;#39; right after setup_conf().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: spi-nor: Fix shift-out-of-bounds in spi_nor_set_erase_type<br /> <br /> spi_nor_set_erase_type() was used either to set or to mask out an erase<br /> type. When we used it to mask out an erase type a shift-out-of-bounds<br /> was hit:<br /> UBSAN: shift-out-of-bounds in drivers/mtd/spi-nor/core.c:2237:24<br /> shift exponent 4294967295 is too large for 32-bit type &amp;#39;int&amp;#39;<br /> <br /> The setting of the size_{shift, mask} and of the opcode are unnecessary<br /> when the erase size is zero, as throughout the code just the erase size<br /> is considered to determine whether an erase type is supported or not.<br /> Setting the opcode to 0xFF was wrong too as nobody guarantees that 0xFF<br /> is an unused opcode. Thus when masking out an erase type, just set the<br /> erase size to zero. This will fix the shift-out-of-bounds.<br /> <br /> [ta: refine changes, new commit message, fix compilation error]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SVM: Get source vCPUs from source VM for SEV-ES intrahost migration<br /> <br /> Fix a goof where KVM tries to grab source vCPUs from the destination VM<br /> when doing intrahost migration. Grabbing the wrong vCPU not only hoses<br /> the guest, it also crashes the host due to the VMSA pointer being left<br /> NULL.<br /> <br /> BUG: unable to handle page fault for address: ffffe38687000000<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] SMP NOPTI<br /> CPU: 39 PID: 17143 Comm: sev_migrate_tes Tainted: GO 6.5.0-smp--fff2e47e6c3b-next #151<br /> Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.28.0 07/10/2023<br /> RIP: 0010:__free_pages+0x15/0xd0<br /> RSP: 0018:ffff923fcf6e3c78 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffffe38687000000 RCX: 0000000000000100<br /> RDX: 0000000000000100 RSI: 0000000000000000 RDI: ffffe38687000000<br /> RBP: ffff923fcf6e3c88 R08: ffff923fcafb0000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: ffffffff83619b90 R12: ffff923fa9540000<br /> R13: 0000000000080007 R14: ffff923f6d35d000 R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffff929d0d7c0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffe38687000000 CR3: 0000005224c34005 CR4: 0000000000770ee0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> sev_free_vcpu+0xcb/0x110 [kvm_amd]<br /> svm_vcpu_free+0x75/0xf0 [kvm_amd]<br /> kvm_arch_vcpu_destroy+0x36/0x140 [kvm]<br /> kvm_destroy_vcpus+0x67/0x100 [kvm]<br /> kvm_arch_destroy_vm+0x161/0x1d0 [kvm]<br /> kvm_put_kvm+0x276/0x560 [kvm]<br /> kvm_vm_release+0x25/0x30 [kvm]<br /> __fput+0x106/0x280<br /> ____fput+0x12/0x20<br /> task_work_run+0x86/0xb0<br /> do_exit+0x2e3/0x9c0<br /> do_group_exit+0xb1/0xc0<br /> __x64_sys_exit_group+0x1b/0x20<br /> do_syscall_64+0x41/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> CR2: ffffe38687000000

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: zoned: fix memory leak after finding block group with super blocks<br /> <br /> At exclude_super_stripes(), if we happen to find a block group that has<br /> super blocks mapped to it and we are on a zoned filesystem, we error out<br /> as this is not supposed to happen, indicating either a bug or maybe some<br /> memory corruption for example. However we are exiting the function without<br /> freeing the memory allocated for the logical address of the super blocks.<br /> Fix this by freeing the logical address.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thermal: intel: quark_dts: fix error pointer dereference<br /> <br /> If alloc_soc_dts() fails, then we can just return. Trying to free<br /> "soc_dts" will lead to an Oops.

*** Pendiente de traducción *** Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: release path before inode lookup during the ino lookup ioctl<br /> <br /> During the ino lookup ioctl we can end up calling btrfs_iget() to get an<br /> inode reference while we are holding on a root&amp;#39;s btree. If btrfs_iget()<br /> needs to lookup the inode from the root&amp;#39;s btree, because it&amp;#39;s not<br /> currently loaded in memory, then it will need to lock another or the<br /> same path in the same root btree. This may result in a deadlock and<br /> trigger the following lockdep splat:<br /> <br /> WARNING: possible circular locking dependency detected<br /> 6.5.0-rc7-syzkaller-00004-gf7757129e3de #0 Not tainted<br /> ------------------------------------------------------<br /> syz-executor277/5012 is trying to acquire lock:<br /> ffff88802df41710 (btrfs-tree-01){++++}-{3:3}, at: __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136<br /> <br /> but task is already holding lock:<br /> ffff88802df418e8 (btrfs-tree-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136<br /> <br /> which lock already depends on the new lock.<br /> <br /> the existing dependency chain (in reverse order) is:<br /> <br /> -&gt; #1 (btrfs-tree-00){++++}-{3:3}:<br /> down_read_nested+0x49/0x2f0 kernel/locking/rwsem.c:1645<br /> __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136<br /> btrfs_search_slot+0x13a4/0x2f80 fs/btrfs/ctree.c:2302<br /> btrfs_init_root_free_objectid+0x148/0x320 fs/btrfs/disk-io.c:4955<br /> btrfs_init_fs_root fs/btrfs/disk-io.c:1128 [inline]<br /> btrfs_get_root_ref+0x5ae/0xae0 fs/btrfs/disk-io.c:1338<br /> btrfs_get_fs_root fs/btrfs/disk-io.c:1390 [inline]<br /> open_ctree+0x29c8/0x3030 fs/btrfs/disk-io.c:3494<br /> btrfs_fill_super+0x1c7/0x2f0 fs/btrfs/super.c:1154<br /> btrfs_mount_root+0x7e0/0x910 fs/btrfs/super.c:1519<br /> legacy_get_tree+0xef/0x190 fs/fs_context.c:611<br /> vfs_get_tree+0x8c/0x270 fs/super.c:1519<br /> fc_mount fs/namespace.c:1112 [inline]<br /> vfs_kern_mount+0xbc/0x150 fs/namespace.c:1142<br /> btrfs_mount+0x39f/0xb50 fs/btrfs/super.c:1579<br /> legacy_get_tree+0xef/0x190 fs/fs_context.c:611<br /> vfs_get_tree+0x8c/0x270 fs/super.c:1519<br /> do_new_mount+0x28f/0xae0 fs/namespace.c:3335<br /> do_mount fs/namespace.c:3675 [inline]<br /> __do_sys_mount fs/namespace.c:3884 [inline]<br /> __se_sys_mount+0x2d9/0x3c0 fs/namespace.c:3861<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> -&gt; #0 (btrfs-tree-01){++++}-{3:3}:<br /> check_prev_add kernel/locking/lockdep.c:3142 [inline]<br /> check_prevs_add kernel/locking/lockdep.c:3261 [inline]<br /> validate_chain kernel/locking/lockdep.c:3876 [inline]<br /> __lock_acquire+0x39ff/0x7f70 kernel/locking/lockdep.c:5144<br /> lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5761<br /> down_read_nested+0x49/0x2f0 kernel/locking/rwsem.c:1645<br /> __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136<br /> btrfs_tree_read_lock fs/btrfs/locking.c:142 [inline]<br /> btrfs_read_lock_root_node+0x292/0x3c0 fs/btrfs/locking.c:281<br /> btrfs_search_slot_get_root fs/btrfs/ctree.c:1832 [inline]<br /> btrfs_search_slot+0x4ff/0x2f80 fs/btrfs/ctree.c:2154<br /> btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:412<br /> btrfs_read_locked_inode fs/btrfs/inode.c:3892 [inline]<br /> btrfs_iget_path+0x2d9/0x1520 fs/btrfs/inode.c:5716<br /> btrfs_search_path_in_tree_user fs/btrfs/ioctl.c:1961 [inline]<br /> btrfs_ioctl_ino_lookup_user+0x77a/0xf50 fs/btrfs/ioctl.c:2105<br /> btrfs_ioctl+0xb0b/0xd40 fs/btrfs/ioctl.c:4683<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:870 [inline]<br /> __se_sys_ioctl+0xf8/0x170 fs/ioctl.c:856<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> other info <br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: tuners: qt1010: replace BUG_ON with a regular error<br /> <br /> BUG_ON is unnecessary here, and in addition it confuses smatch.<br /> Replacing this with an error return help resolve this smatch<br /> warning:<br /> <br /> drivers/media/tuners/qt1010.c:350 qt1010_init() error: buffer overflow &amp;#39;i2c_data&amp;#39; 34

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Address KCSAN report on bpf_lru_list<br /> <br /> KCSAN reported a data-race when accessing node-&gt;ref.<br /> Although node-&gt;ref does not have to be accurate,<br /> take this chance to use a more common READ_ONCE() and WRITE_ONCE()<br /> pattern instead of data_race().<br /> <br /> There is an existing bpf_lru_node_is_ref() and bpf_lru_node_set_ref().<br /> This patch also adds bpf_lru_node_clear_ref() to do the<br /> WRITE_ONCE(node-&gt;ref, 0) also.<br /> <br /> ==================================================================<br /> BUG: KCSAN: data-race in __bpf_lru_list_rotate / __htab_lru_percpu_map_update_elem<br /> <br /> write to 0xffff888137038deb of 1 bytes by task 11240 on cpu 1:<br /> __bpf_lru_node_move kernel/bpf/bpf_lru_list.c:113 [inline]<br /> __bpf_lru_list_rotate_active kernel/bpf/bpf_lru_list.c:149 [inline]<br /> __bpf_lru_list_rotate+0x1bf/0x750 kernel/bpf/bpf_lru_list.c:240<br /> bpf_lru_list_pop_free_to_local kernel/bpf/bpf_lru_list.c:329 [inline]<br /> bpf_common_lru_pop_free kernel/bpf/bpf_lru_list.c:447 [inline]<br /> bpf_lru_pop_free+0x638/0xe20 kernel/bpf/bpf_lru_list.c:499<br /> prealloc_lru_pop kernel/bpf/hashtab.c:290 [inline]<br /> __htab_lru_percpu_map_update_elem+0xe7/0x820 kernel/bpf/hashtab.c:1316<br /> bpf_percpu_hash_update+0x5e/0x90 kernel/bpf/hashtab.c:2313<br /> bpf_map_update_value+0x2a9/0x370 kernel/bpf/syscall.c:200<br /> generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall.c:1687<br /> bpf_map_do_batch+0x2d9/0x3d0 kernel/bpf/syscall.c:4534<br /> __sys_bpf+0x338/0x810<br /> __do_sys_bpf kernel/bpf/syscall.c:5096 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:5094 [inline]<br /> __x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5094<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> read to 0xffff888137038deb of 1 bytes by task 11241 on cpu 0:<br /> bpf_lru_node_set_ref kernel/bpf/bpf_lru_list.h:70 [inline]<br /> __htab_lru_percpu_map_update_elem+0x2f1/0x820 kernel/bpf/hashtab.c:1332<br /> bpf_percpu_hash_update+0x5e/0x90 kernel/bpf/hashtab.c:2313<br /> bpf_map_update_value+0x2a9/0x370 kernel/bpf/syscall.c:200<br /> generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall.c:1687<br /> bpf_map_do_batch+0x2d9/0x3d0 kernel/bpf/syscall.c:4534<br /> __sys_bpf+0x338/0x810<br /> __do_sys_bpf kernel/bpf/syscall.c:5096 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:5094 [inline]<br /> __x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5094<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> value changed: 0x01 -&gt; 0x00<br /> <br /> Reported by Kernel Concurrency Sanitizer on:<br /> CPU: 0 PID: 11241 Comm: syz-executor.3 Not tainted 6.3.0-rc7-syzkaller-00136-g6a66fdd29ea1 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/30/2023<br /> ==================================================================

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: av7110: prevent underflow in write_ts_to_decoder()<br /> <br /> The buf[4] value comes from the user via ts_play(). It is a value in<br /> the u8 range. The final length we pass to av7110_ipack_instant_repack()<br /> is "len - (buf[4] + 1) - 4" so add a check to ensure that the length is<br /> not negative. It&amp;#39;s not clear that passing a negative len value does<br /> anything bad necessarily, but it&amp;#39;s not best practice.<br /> <br /> With the new bounds checking the "if (!len)" condition is no longer<br /> possible or required so remove that.