Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: tegra: xusb: Clear the driver reference in usb-phy dev<br /> <br /> For the dual-role port, it will assign the phy dev to usb-phy dev and<br /> use the port dev driver as the dev driver of usb-phy.<br /> <br /> When we try to destroy the port dev, it will destroy its dev driver<br /> as well. But we did not remove the reference from usb-phy dev. This<br /> might cause the use-after-free issue in KASAN.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: firewire-digi00x: prevent potential use after free<br /> <br /> This code was supposed to return an error code if init_stream()<br /> failed, but it instead freed dg00x-&gt;rx_stream and returned success.<br /> This potentially leads to a use after free.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix NULL pointer dereference on fastopen early fallback<br /> <br /> In case of early fallback to TCP, subflow_syn_recv_sock() deletes<br /> the subflow context before returning the newly allocated sock to<br /> the caller.<br /> <br /> The fastopen path does not cope with the above unconditionally<br /> dereferencing the subflow context.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Add preempt_count_{sub,add} into btf id deny list<br /> <br /> The recursion check in __bpf_prog_enter* and __bpf_prog_exit*<br /> leave preempt_count_{sub,add} unprotected. When attaching trampoline to<br /> them we get panic as follows,<br /> <br /> [ 867.843050] BUG: TASK stack guard page was hit at 0000000009d325cf (stack is 0000000046a46a15..00000000537e7b28)<br /> [ 867.843064] stack guard page: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 867.843067] CPU: 8 PID: 11009 Comm: trace Kdump: loaded Not tainted 6.2.0+ #4<br /> [ 867.843100] Call Trace:<br /> [ 867.843101] <br /> [ 867.843104] asm_exc_int3+0x3a/0x40<br /> [ 867.843108] RIP: 0010:preempt_count_sub+0x1/0xa0<br /> [ 867.843135] __bpf_prog_enter_recur+0x17/0x90<br /> [ 867.843148] bpf_trampoline_6442468108_0+0x2e/0x1000<br /> [ 867.843154] ? preempt_count_sub+0x1/0xa0<br /> [ 867.843157] preempt_count_sub+0x5/0xa0<br /> [ 867.843159] ? migrate_enable+0xac/0xf0<br /> [ 867.843164] __bpf_prog_exit_recur+0x2d/0x40<br /> [ 867.843168] bpf_trampoline_6442468108_0+0x55/0x1000<br /> ...<br /> [ 867.843788] preempt_count_sub+0x5/0xa0<br /> [ 867.843793] ? migrate_enable+0xac/0xf0<br /> [ 867.843829] __bpf_prog_exit_recur+0x2d/0x40<br /> [ 867.843837] BUG: IRQ stack guard page was hit at 0000000099bd8228 (stack is 00000000b23e2bc4..000000006d95af35)<br /> [ 867.843841] BUG: IRQ stack guard page was hit at 000000005ae07924 (stack is 00000000ffd69623..0000000014eb594c)<br /> [ 867.843843] BUG: IRQ stack guard page was hit at 00000000028320f0 (stack is 00000000034b6438..0000000078d1bcec)<br /> [ 867.843842] bpf_trampoline_6442468108_0+0x55/0x1000<br /> ...<br /> <br /> That is because in __bpf_prog_exit_recur, the preempt_count_{sub,add} are<br /> called after prog-&gt;active is decreased.<br /> <br /> Fixing this by adding these two functions into btf ids deny list.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubi: Fix possible null-ptr-deref in ubi_free_volume()<br /> <br /> It willl cause null-ptr-deref in the following case:<br /> <br /> uif_init()<br /> ubi_add_volume()<br /> cdev_add() -&gt; if it fails, call kill_volumes()<br /> device_register()<br /> <br /> kill_volumes() -&gt; if ubi_add_volume() fails call this function<br /> ubi_free_volume()<br /> cdev_del()<br /> device_unregister() -&gt; trying to delete a not added device,<br /> it causes null-ptr-deref<br /> <br /> So in ubi_free_volume(), it delete devices whether they are added<br /> or not, it will causes null-ptr-deref.<br /> <br /> Handle the error case whlie calling ubi_add_volume() to fix this<br /> problem. If add volume fails, set the corresponding vol to null,<br /> so it can not be accessed in kill_volumes() and release the<br /> resource in ubi_add_volume() error path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-cgroup: hold queue_lock when removing blkg-&gt;q_node<br /> <br /> When blkg is removed from q-&gt;blkg_list from blkg_free_workfn(), queue_lock<br /> has to be held, otherwise, all kinds of bugs(list corruption, hard lockup,<br /> ..) can be triggered from blkg_destroy_all().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio_pmem: add the missing REQ_OP_WRITE for flush bio<br /> <br /> When doing mkfs.xfs on a pmem device, the following warning was<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 2 PID: 384 at block/blk-core.c:751 submit_bio_noacct<br /> Modules linked in:<br /> CPU: 2 PID: 384 Comm: mkfs.xfs Not tainted 6.4.0-rc7+ #154<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)<br /> RIP: 0010:submit_bio_noacct+0x340/0x520<br /> ......<br /> Call Trace:<br /> <br /> ? submit_bio_noacct+0xd5/0x520<br /> submit_bio+0x37/0x60<br /> async_pmem_flush+0x79/0xa0<br /> nvdimm_flush+0x17/0x40<br /> pmem_submit_bio+0x370/0x390<br /> __submit_bio+0xbc/0x190<br /> submit_bio_noacct_nocheck+0x14d/0x370<br /> submit_bio_noacct+0x1ef/0x520<br /> submit_bio+0x55/0x60<br /> submit_bio_wait+0x5a/0xc0<br /> blkdev_issue_flush+0x44/0x60<br /> <br /> The root cause is that submit_bio_noacct() needs bio_op() is either<br /> WRITE or ZONE_APPEND for flush bio and async_pmem_flush() doesn&amp;#39;t assign<br /> REQ_OP_WRITE when allocating flush bio, so submit_bio_noacct just fail<br /> the flush bio.<br /> <br /> Simply fix it by adding the missing REQ_OP_WRITE for flush bio. And we<br /> could fix the flush order issue and do flush optimization later.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ixgbe: Fix panic during XDP_TX with &gt; 64 CPUs<br /> <br /> Commit 4fe815850bdc ("ixgbe: let the xdpdrv work with more than 64 cpus")<br /> adds support to allow XDP programs to run on systems with more than<br /> 64 CPUs by locking the XDP TX rings and indexing them using cpu % 64<br /> (IXGBE_MAX_XDP_QS).<br /> <br /> Upon trying this out patch on a system with more than 64 cores,<br /> the kernel paniced with an array-index-out-of-bounds at the return in<br /> ixgbe_determine_xdp_ring in ixgbe.h, which means ixgbe_determine_xdp_q_idx<br /> was just returning the cpu instead of cpu % IXGBE_MAX_XDP_QS. An example<br /> splat:<br /> <br /> ==========================================================================<br /> UBSAN: array-index-out-of-bounds in<br /> /var/lib/dkms/ixgbe/5.18.6+focal-1/build/src/ixgbe.h:1147:26<br /> index 65 is out of range for type &amp;#39;ixgbe_ring *[64]&amp;#39;<br /> ==========================================================================<br /> BUG: kernel NULL pointer dereference, address: 0000000000000058<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: 65 PID: 408 Comm: ksoftirqd/65<br /> Tainted: G IOE 5.15.0-48-generic #54~20.04.1-Ubuntu<br /> Hardware name: Dell Inc. PowerEdge R640/0W23H8, BIOS 2.5.4 01/13/2020<br /> RIP: 0010:ixgbe_xmit_xdp_ring+0x1b/0x1c0 [ixgbe]<br /> Code: 3b 52 d4 cf e9 42 f2 ff ff 66 0f 1f 44 00 00 0f 1f 44 00 00 55 b9<br /> 00 00 00 00 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 08 0f b7<br /> 47 58 0f b7 47 5a 0f b7 57 54 44 0f b7 76 08 66 41 39 c0<br /> RSP: 0018:ffffbc3fcd88fcb0 EFLAGS: 00010282<br /> RAX: ffff92a253260980 RBX: ffffbc3fe68b00a0 RCX: 0000000000000000<br /> RDX: ffff928b5f659000 RSI: ffff928b5f659000 RDI: 0000000000000000<br /> RBP: ffffbc3fcd88fce0 R08: ffff92b9dfc20580 R09: 0000000000000001<br /> R10: 3d3d3d3d3d3d3d3d R11: 3d3d3d3d3d3d3d3d R12: 0000000000000000<br /> R13: ffff928b2f0fa8c0 R14: ffff928b9be20050 R15: 000000000000003c<br /> FS: 0000000000000000(0000) GS:ffff92b9dfc00000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000058 CR3: 000000011dd6a002 CR4: 00000000007706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ixgbe_poll+0x103e/0x1280 [ixgbe]<br /> ? sched_clock_cpu+0x12/0xe0<br /> __napi_poll+0x30/0x160<br /> net_rx_action+0x11c/0x270<br /> __do_softirq+0xda/0x2ee<br /> run_ksoftirqd+0x2f/0x50<br /> smpboot_thread_fn+0xb7/0x150<br /> ? sort_range+0x30/0x30<br /> kthread+0x127/0x150<br /> ? set_kthread_struct+0x50/0x50<br /> ret_from_fork+0x1f/0x30<br /> <br /> <br /> I think this is how it happens:<br /> <br /> Upon loading the first XDP program on a system with more than 64 CPUs,<br /> ixgbe_xdp_locking_key is incremented in ixgbe_xdp_setup. However,<br /> immediately after this, the rings are reconfigured by ixgbe_setup_tc.<br /> ixgbe_setup_tc calls ixgbe_clear_interrupt_scheme which calls<br /> ixgbe_free_q_vectors which calls ixgbe_free_q_vector in a loop.<br /> ixgbe_free_q_vector decrements ixgbe_xdp_locking_key once per call if<br /> it is non-zero. Commenting out the decrement in ixgbe_free_q_vector<br /> stopped my system from panicing.<br /> <br /> I suspect to make the original patch work, I would need to load an XDP<br /> program and then replace it in order to get ixgbe_xdp_locking_key back<br /> above 0 since ixgbe_setup_tc is only called when transitioning between<br /> XDP and non-XDP ring configurations, while ixgbe_xdp_locking_key is<br /> incremented every time ixgbe_xdp_setup is called.<br /> <br /> Also, ixgbe_setup_tc can be called via ethtool --set-channels, so this<br /> becomes another path to decrement ixgbe_xdp_locking_key to 0 on systems<br /> with more than 64 CPUs.<br /> <br /> Since ixgbe_xdp_locking_key only protects the XDP_TX path and is tied<br /> to the number of CPUs present, there is no reason to disable it upon<br /> unloading an XDP program. To avoid confusion, I have moved enabling<br /> ixgbe_xdp_locking_key into ixgbe_sw_init, which is part of the probe path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/client: Fix memory leak in drm_client_target_cloned<br /> <br /> dmt_mode is allocated and never freed in this function.<br /> It was found with the ast driver, but most drivers using generic fbdev<br /> setup are probably affected.<br /> <br /> This fixes the following kmemleak report:<br /> backtrace:<br /> [] drm_mode_duplicate+0x45/0x220 [drm]<br /> [] drm_client_target_cloned.constprop.0+0x27b/0x480 [drm]<br /> [] drm_client_modeset_probe+0x6bd/0xf50 [drm]<br /> [] __drm_fb_helper_initial_config_and_unlock+0xb4/0x2c0 [drm_kms_helper]<br /> [] drm_fbdev_client_hotplug+0x2bc/0x4d0 [drm_kms_helper]<br /> [] drm_client_register+0x169/0x240 [drm]<br /> [] ast_pci_probe+0x142/0x190 [ast]<br /> [] local_pci_probe+0xdc/0x180<br /> [] work_for_cpu_fn+0x4e/0xa0<br /> [] process_one_work+0x8b7/0x1540<br /> [] worker_thread+0x70a/0xed0<br /> [] kthread+0x29f/0x340<br /> [] ret_from_fork+0x1f/0x30<br /> unreferenced object 0xff11000333089a00 (size 128):

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: pcm: Fix potential data race at PCM memory allocation helpers<br /> <br /> The PCM memory allocation helpers have a sanity check against too many<br /> buffer allocations. However, the check is performed without a proper<br /> lock and the allocation isn&amp;#39;t serialized; this allows user to allocate<br /> more memories than predefined max size.<br /> <br /> Practically seen, this isn&amp;#39;t really a big problem, as it&amp;#39;s more or<br /> less some "soft limit" as a sanity check, and it&amp;#39;s not possible to<br /> allocate unlimitedly. But it&amp;#39;s still better to address this for more<br /> consistent behavior.<br /> <br /> The patch covers the size check in do_alloc_pages() with the<br /> card-&gt;memory_mutex, and increases the allocated size there for<br /> preventing the further overflow. When the actual allocation fails,<br /> the size is decreased accordingly.

*** 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