Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tpm: Add !tpm_amd_is_rng_defective() to the hwrng_unregister() call site<br /> <br /> The following crash was reported:<br /> <br /> [ 1950.279393] list_del corruption, ffff99560d485790-&gt;next is NULL<br /> [ 1950.279400] ------------[ cut here ]------------<br /> [ 1950.279401] kernel BUG at lib/list_debug.c:49!<br /> [ 1950.279405] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 1950.279407] CPU: 11 PID: 5886 Comm: modprobe Tainted: G O 6.2.8_1 #1<br /> [ 1950.279409] Hardware name: Gigabyte Technology Co., Ltd. B550M AORUS PRO-P/B550M AORUS PRO-P,<br /> BIOS F15c 05/11/2022<br /> [ 1950.279410] RIP: 0010:__list_del_entry_valid+0x59/0xc0<br /> [ 1950.279415] Code: 48 8b 01 48 39 f8 75 5a 48 8b 72 08 48 39 c6 75 65 b8 01 00 00 00 c3 cc cc cc<br /> cc 48 89 fe 48 c7 c7 08 a8 13 9e e8 b7 0a bc ff 0b 48 89 fe 48 c7 c7 38 a8 13 9e e8 a6 0a bc<br /> ff 0f 0b 48 89 fe<br /> [ 1950.279416] RSP: 0018:ffffa96d05647e08 EFLAGS: 00010246<br /> [ 1950.279418] RAX: 0000000000000033 RBX: ffff99560d485750 RCX: 0000000000000000<br /> [ 1950.279419] RDX: 0000000000000000 RSI: ffffffff9e107c59 RDI: 00000000ffffffff<br /> [ 1950.279420] RBP: ffffffffc19c5168 R08: 0000000000000000 R09: ffffa96d05647cc8<br /> [ 1950.279421] R10: 0000000000000003 R11: ffffffff9ea2a568 R12: 0000000000000000<br /> [ 1950.279422] R13: ffff99560140a2e0 R14: ffff99560127d2e0 R15: 0000000000000000<br /> [ 1950.279422] FS: 00007f67da795380(0000) GS:ffff995d1f0c0000(0000) knlGS:0000000000000000<br /> [ 1950.279424] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 1950.279424] CR2: 00007f67da7e65c0 CR3: 00000001feed2000 CR4: 0000000000750ee0<br /> [ 1950.279426] PKRU: 55555554<br /> [ 1950.279426] Call Trace:<br /> [ 1950.279428] <br /> [ 1950.279430] hwrng_unregister+0x28/0xe0 [rng_core]<br /> [ 1950.279436] tpm_chip_unregister+0xd5/0xf0 [tpm]<br /> <br /> Add the forgotten !tpm_amd_is_rng_defective() invariant to the<br /> hwrng_unregister() call site inside tpm_chip_unregister().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Use correct encap attribute during invalidation<br /> <br /> With introduction of post action infrastructure most of the users of encap<br /> attribute had been modified in order to obtain the correct attribute by<br /> calling mlx5e_tc_get_encap_attr() helper instead of assuming encap action<br /> is always on default attribute. However, the cited commit didn&amp;#39;t modify<br /> mlx5e_invalidate_encap() which prevents it from destroying correct modify<br /> header action which leads to a warning [0]. Fix the issue by using correct<br /> attribute.<br /> <br /> [0]:<br /> <br /> Feb 21 09:47:35 c-237-177-40-045 kernel: WARNING: CPU: 17 PID: 654 at drivers/net/ethernet/mellanox/mlx5/core/en_tc.c:684 mlx5e_tc_attach_mod_hdr+0x1cc/0x230 [mlx5_core]<br /> Feb 21 09:47:35 c-237-177-40-045 kernel: RIP: 0010:mlx5e_tc_attach_mod_hdr+0x1cc/0x230 [mlx5_core]<br /> Feb 21 09:47:35 c-237-177-40-045 kernel: Call Trace:<br /> Feb 21 09:47:35 c-237-177-40-045 kernel: <br /> Feb 21 09:47:35 c-237-177-40-045 kernel: mlx5e_tc_fib_event_work+0x8e3/0x1f60 [mlx5_core]<br /> Feb 21 09:47:35 c-237-177-40-045 kernel: ? mlx5e_take_all_encap_flows+0xe0/0xe0 [mlx5_core]<br /> Feb 21 09:47:35 c-237-177-40-045 kernel: ? lock_downgrade+0x6d0/0x6d0<br /> Feb 21 09:47:35 c-237-177-40-045 kernel: ? lockdep_hardirqs_on_prepare+0x273/0x3f0<br /> Feb 21 09:47:35 c-237-177-40-045 kernel: ? lockdep_hardirqs_on_prepare+0x273/0x3f0<br /> Feb 21 09:47:35 c-237-177-40-045 kernel: process_one_work+0x7c2/0x1310<br /> Feb 21 09:47:35 c-237-177-40-045 kernel: ? lockdep_hardirqs_on_prepare+0x3f0/0x3f0<br /> Feb 21 09:47:35 c-237-177-40-045 kernel: ? pwq_dec_nr_in_flight+0x230/0x230<br /> Feb 21 09:47:35 c-237-177-40-045 kernel: ? rwlock_bug.part.0+0x90/0x90<br /> Feb 21 09:47:35 c-237-177-40-045 kernel: worker_thread+0x59d/0xec0<br /> Feb 21 09:47:35 c-237-177-40-045 kernel: ? __kthread_parkme+0xd9/0x1d0

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mediatek: common: Fix refcount leak in parse_dai_link_info<br /> <br /> Add missing of_node_put()s before the returns to balance<br /> of_node_get()s and of_node_put()s, which may get unbalanced<br /> in case the for loop &amp;#39;for_each_available_child_of_node&amp;#39; returns<br /> early.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix missed ses refcounting<br /> <br /> Use new cifs_smb_ses_inc_refcount() helper to get an active reference<br /> of @ses and @ses-&gt;dfs_root_ses (if set). This will prevent<br /> @ses-&gt;dfs_root_ses of being put in the next call to cifs_put_smb_ses()<br /> and thus potentially causing an use-after-free bug.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Fix memory leak if ntfs_read_mft failed<br /> <br /> Label ATTR_ROOT in ntfs_read_mft() sets is_root = true and<br /> ni-&gt;ni_flags |= NI_FLAG_DIR, then next attr will goto label ATTR_ALLOC<br /> and alloc ni-&gt;dir.alloc_run. However two states are not always<br /> consistent and can make memory leak.<br /> <br /> 1) attr_name in ATTR_ROOT does not fit the condition it will set<br /> is_root = true but NI_FLAG_DIR is not set.<br /> 2) next attr_name in ATTR_ALLOC fits the condition and alloc<br /> ni-&gt;dir.alloc_run<br /> 3) in cleanup function ni_clear(), when NI_FLAG_DIR is set, it frees<br /> ni-&gt;dir.alloc_run, otherwise it frees ni-&gt;file.run<br /> 4) because NI_FLAG_DIR is not set in this case, ni-&gt;dir.alloc_run is<br /> leaked as kmemleak reported:<br /> <br /> unreferenced object 0xffff888003bc5480 (size 64):<br /> backtrace:<br /> [] __kmalloc_node+0x4e/0x1c0<br /> [] kvmalloc_node+0x39/0x1f0<br /> [] run_add_entry+0x18a/0xa40 [ntfs3]<br /> [] run_unpack+0x75d/0x8e0 [ntfs3]<br /> [] run_unpack_ex+0xbc/0x500 [ntfs3]<br /> [] ntfs_iget5+0xb25/0x2dd0 [ntfs3]<br /> [] ntfs_fill_super+0x218d/0x3580 [ntfs3]<br /> [] get_tree_bdev+0x3fb/0x710<br /> [] vfs_get_tree+0x8e/0x280<br /> [] path_mount+0xf3c/0x1930<br /> [] do_mount+0xf3/0x110<br /> ...<br /> <br /> Fix this by always setting is_root and NI_FLAG_DIR together.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: max9286: Free control handler<br /> <br /> The control handler is leaked in some probe-time error paths, as well as<br /> in the remove path. Fix it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: bq27xxx: Fix poll_interval handling and races on remove<br /> <br /> Before this patch bq27xxx_battery_teardown() was setting poll_interval = 0<br /> to avoid bq27xxx_battery_update() requeuing the delayed_work item.<br /> <br /> There are 2 problems with this:<br /> <br /> 1. If the driver is unbound through sysfs, rather then the module being<br /> rmmod-ed, this changes poll_interval unexpectedly<br /> <br /> 2. This is racy, after it being set poll_interval could be changed<br /> before bq27xxx_battery_update() checks it through<br /> /sys/module/bq27xxx_battery/parameters/poll_interval<br /> <br /> Fix this by added a removed attribute to struct bq27xxx_device_info and<br /> using that instead of setting poll_interval to 0.<br /> <br /> There also is another poll_interval related race on remove(), writing<br /> /sys/module/bq27xxx_battery/parameters/poll_interval will requeue<br /> the delayed_work item for all devices on the bq27xxx_battery_devices<br /> list and the device being removed was only removed from that list<br /> after cancelling the delayed_work item.<br /> <br /> Fix this by moving the removal from the bq27xxx_battery_devices list<br /> to before cancelling the delayed_work item.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: zoned: skip splitting and logical rewriting on pre-alloc write<br /> <br /> When doing a relocation, there is a chance that at the time of<br /> btrfs_reloc_clone_csums(), there is no checksum for the corresponding<br /> region.<br /> <br /> In this case, btrfs_finish_ordered_zoned()&amp;#39;s sum points to an invalid item<br /> and so ordered_extent&amp;#39;s logical is set to some invalid value. Then,<br /> btrfs_lookup_block_group() in btrfs_zone_finish_endio() failed to find a<br /> block group and will hit an assert or a null pointer dereference as<br /> following.<br /> <br /> This can be reprodcued by running btrfs/028 several times (e.g, 4 to 16<br /> times) with a null_blk setup. The device&amp;#39;s zone size and capacity is set to<br /> 32 MB and the storage size is set to 5 GB on my setup.<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f]<br /> CPU: 6 PID: 3105720 Comm: kworker/u16:13 Tainted: G W 6.5.0-rc6-kts+ #1<br /> Hardware name: Supermicro Super Server/X10SRL-F, BIOS 2.0 12/17/2015<br /> Workqueue: btrfs-endio-write btrfs_work_helper [btrfs]<br /> RIP: 0010:btrfs_zone_finish_endio.part.0+0x34/0x160 [btrfs]<br /> Code: 41 54 49 89 fc 55 48 89 f5 53 e8 57 7d fc ff 48 8d b8 88 00 00 00 48 89 c3 48 b8 00 00 00 00 00<br /> &gt; 3c 02 00 0f 85 02 01 00 00 f6 83 88 00 00 00 01 0f 84 a8 00 00<br /> RSP: 0018:ffff88833cf87b08 EFLAGS: 00010206<br /> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000<br /> RDX: 0000000000000011 RSI: 0000000000000004 RDI: 0000000000000088<br /> RBP: 0000000000000002 R08: 0000000000000001 R09: ffffed102877b827<br /> R10: ffff888143bdc13b R11: ffff888125b1cbc0 R12: ffff888143bdc000<br /> R13: 0000000000007000 R14: ffff888125b1cba8 R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffff88881e500000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f3ed85223d5 CR3: 00000001519b4005 CR4: 00000000001706e0<br /> Call Trace:<br /> <br /> ? die_addr+0x3c/0xa0<br /> ? exc_general_protection+0x148/0x220<br /> ? asm_exc_general_protection+0x22/0x30<br /> ? btrfs_zone_finish_endio.part.0+0x34/0x160 [btrfs]<br /> ? btrfs_zone_finish_endio.part.0+0x19/0x160 [btrfs]<br /> btrfs_finish_one_ordered+0x7b8/0x1de0 [btrfs]<br /> ? rcu_is_watching+0x11/0xb0<br /> ? lock_release+0x47a/0x620<br /> ? btrfs_finish_ordered_zoned+0x59b/0x800 [btrfs]<br /> ? __pfx_btrfs_finish_one_ordered+0x10/0x10 [btrfs]<br /> ? btrfs_finish_ordered_zoned+0x358/0x800 [btrfs]<br /> ? __smp_call_single_queue+0x124/0x350<br /> ? rcu_is_watching+0x11/0xb0<br /> btrfs_work_helper+0x19f/0xc60 [btrfs]<br /> ? __pfx_try_to_wake_up+0x10/0x10<br /> ? _raw_spin_unlock_irq+0x24/0x50<br /> ? rcu_is_watching+0x11/0xb0<br /> process_one_work+0x8c1/0x1430<br /> ? __pfx_lock_acquire+0x10/0x10<br /> ? __pfx_process_one_work+0x10/0x10<br /> ? __pfx_do_raw_spin_lock+0x10/0x10<br /> ? _raw_spin_lock_irq+0x52/0x60<br /> worker_thread+0x100/0x12c0<br /> ? __kthread_parkme+0xc1/0x1f0<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0x2ea/0x3c0<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x30/0x70<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> <br /> On the zoned mode, writing to pre-allocated region means data relocation<br /> write. Such write always uses WRITE command so there is no need of splitting<br /> and rewriting logical address. Thus, we can just skip the function for the<br /> case.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xen: speed up grant-table reclaim<br /> <br /> When a grant entry is still in use by the remote domain, Linux must put<br /> it on a deferred list. Normally, this list is very short, because<br /> the PV network and block protocols expect the backend to unmap the grant<br /> first. However, Qubes OS&amp;#39;s GUI protocol is subject to the constraints<br /> of the X Window System, and as such winds up with the frontend unmapping<br /> the window first. As a result, the list can grow very large, resulting<br /> in a massive memory leak and eventual VM freeze.<br /> <br /> To partially solve this problem, make the number of entries that the VM<br /> will attempt to free at each iteration tunable. The default is still<br /> 10, but it can be overridden via a module parameter.<br /> <br /> This is Cc: stable because (when combined with appropriate userspace<br /> changes) it fixes a severe performance and stability problem for Qubes<br /> OS users.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Fix OOB read in indx_insert_into_buffer<br /> <br /> Syzbot reported a OOB read bug:<br /> <br /> BUG: KASAN: slab-out-of-bounds in indx_insert_into_buffer+0xaa3/0x13b0<br /> fs/ntfs3/index.c:1755<br /> Read of size 17168 at addr ffff8880255e06c0 by task syz-executor308/3630<br /> <br /> Call Trace:<br /> <br /> memmove+0x25/0x60 mm/kasan/shadow.c:54<br /> indx_insert_into_buffer+0xaa3/0x13b0 fs/ntfs3/index.c:1755<br /> indx_insert_entry+0x446/0x6b0 fs/ntfs3/index.c:1863<br /> ntfs_create_inode+0x1d3f/0x35c0 fs/ntfs3/inode.c:1548<br /> ntfs_create+0x3e/0x60 fs/ntfs3/namei.c:100<br /> lookup_open fs/namei.c:3413 [inline]<br /> <br /> If the member struct INDEX_BUFFER *index of struct indx_node is<br /> incorrect, that is, the value of __le32 used is greater than the value<br /> of __le32 total in struct INDEX_HDR. Therefore, OOB read occurs when<br /> memmove is called in indx_insert_into_buffer().<br /> Fix this by adding a check in hdr_find_e().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipmi:ssif: Fix a memory leak when scanning for an adapter<br /> <br /> The adapter scan ssif_info_find() sets info-&gt;adapter_name if the adapter<br /> info came from SMBIOS, as it&amp;#39;s not set in that case. However, this<br /> function can be called more than once, and it will leak the adapter name<br /> if it had already been set. So check for NULL before setting it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: realtek: fix out-of-bounds access<br /> <br /> The probe function sets priv-&gt;chip_data to (void *)priv + sizeof(*priv)<br /> with the expectation that priv has enough trailing space.<br /> <br /> However, only realtek-smi actually allocated this chip_data space.<br /> Do likewise in realtek-mdio to fix out-of-bounds accesses.<br /> <br /> These accesses likely went unnoticed so far, because of an (unused)<br /> buf[4096] member in struct realtek_priv, which caused kmalloc to<br /> round up the allocated buffer to a big enough size, so nothing of<br /> value was overwritten. With a different allocator (like in the barebox<br /> bootloader port of the driver) or with KASAN, the memory corruption<br /> becomes quickly apparent.