Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: remove BUG_ON()&amp;#39;s in add_new_free_space()<br /> <br /> At add_new_free_space() we have these BUG_ON()&amp;#39;s that are there to deal<br /> with any failure to add free space to the in memory free space cache.<br /> Such failures are mostly -ENOMEM that should be very rare. However there&amp;#39;s<br /> no need to have these BUG_ON()&amp;#39;s, we can just return any error to the<br /> caller and all callers and their upper call chain are already dealing with<br /> errors.<br /> <br /> So just make add_new_free_space() return any errors, while removing the<br /> BUG_ON()&amp;#39;s, and returning the total amount of added free space to an<br /> optional u64 pointer argument.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: altmodes/displayport: fix pin_assignment_show<br /> <br /> This patch fixes negative indexing of buf array in pin_assignment_show<br /> when get_current_pin_assignments returns 0 i.e. no compatible pin<br /> assignments are found.<br /> <br /> BUG: KASAN: use-after-free in pin_assignment_show+0x26c/0x33c<br /> ...<br /> Call trace:<br /> dump_backtrace+0x110/0x204<br /> dump_stack_lvl+0x84/0xbc<br /> print_report+0x358/0x974<br /> kasan_report+0x9c/0xfc<br /> __do_kernel_fault+0xd4/0x2d4<br /> do_bad_area+0x48/0x168<br /> do_tag_check_fault+0x24/0x38<br /> do_mem_abort+0x6c/0x14c<br /> el1_abort+0x44/0x68<br /> el1h_64_sync_handler+0x64/0xa4<br /> el1h_64_sync+0x78/0x7c<br /> pin_assignment_show+0x26c/0x33c<br /> dev_attr_show+0x50/0xc0

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix potential corruption when moving a directory<br /> <br /> F2FS has the same issue in ext4_rename causing crash revealed by<br /> xfstests/generic/707.<br /> <br /> See also commit 0813299c586b ("ext4: Fix possible corruption when moving a directory")

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: apple-admac: Fix &amp;#39;current_tx&amp;#39; not getting freed<br /> <br /> In terminate_all we should queue up all submitted descriptors to be<br /> freed. We do that for the content of the &amp;#39;issued&amp;#39; and &amp;#39;submitted&amp;#39; lists,<br /> but the &amp;#39;current_tx&amp;#39; descriptor falls through the cracks as it&amp;#39;s<br /> removed from the &amp;#39;issued&amp;#39; list once it gets assigned to be the current<br /> descriptor. Explicitly queue up freeing of the &amp;#39;current_tx&amp;#39; descriptor<br /> to address a memory leak that is otherwise present.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pstore/ram: Add check for kstrdup<br /> <br /> Add check for the return value of kstrdup() and return the error<br /> if it fails in order to avoid NULL pointer dereference.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> leds: led-core: Fix refcount leak in of_led_get()<br /> <br /> class_find_device_by_of_node() calls class_find_device(), it will take<br /> the reference, use the put_device() to drop the reference when not need<br /> anymore.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/hyperv: Disable IBT when hypercall page lacks ENDBR instruction<br /> <br /> On hardware that supports Indirect Branch Tracking (IBT), Hyper-V VMs<br /> with ConfigVersion 9.3 or later support IBT in the guest. However,<br /> current versions of Hyper-V have a bug in that there&amp;#39;s not an ENDBR64<br /> instruction at the beginning of the hypercall page. Since hypercalls are<br /> made with an indirect call to the hypercall page, all hypercall attempts<br /> fail with an exception and Linux panics.<br /> <br /> A Hyper-V fix is in progress to add ENDBR64. But guard against the Linux<br /> panic by clearing X86_FEATURE_IBT if the hypercall page doesn&amp;#39;t start<br /> with ENDBR. The VM will boot and run without IBT.<br /> <br /> If future Linux 32-bit kernels were to support IBT, additional hypercall<br /> page hackery would be needed to make IBT work for such kernels in a<br /> Hyper-V VM.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Disable preemption in bpf_event_output<br /> <br /> We received report [1] of kernel crash, which is caused by<br /> using nesting protection without disabled preemption.<br /> <br /> The bpf_event_output can be called by programs executed by<br /> bpf_prog_run_array_cg function that disabled migration but<br /> keeps preemption enabled.<br /> <br /> This can cause task to be preempted by another one inside the<br /> nesting protection and lead eventually to two tasks using same<br /> perf_sample_data buffer and cause crashes like:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000001<br /> #PF: supervisor instruction fetch in kernel mode<br /> #PF: error_code(0x0010) - not-present page<br /> ...<br /> ? perf_output_sample+0x12a/0x9a0<br /> ? finish_task_switch.isra.0+0x81/0x280<br /> ? perf_event_output+0x66/0xa0<br /> ? bpf_event_output+0x13a/0x190<br /> ? bpf_event_output_data+0x22/0x40<br /> ? bpf_prog_dfc84bbde731b257_cil_sock4_connect+0x40a/0xacb<br /> ? xa_load+0x87/0xe0<br /> ? __cgroup_bpf_run_filter_sock_addr+0xc1/0x1a0<br /> ? release_sock+0x3e/0x90<br /> ? sk_setsockopt+0x1a1/0x12f0<br /> ? udp_pre_connect+0x36/0x50<br /> ? inet_dgram_connect+0x93/0xa0<br /> ? __sys_connect+0xb4/0xe0<br /> ? udp_setsockopt+0x27/0x40<br /> ? __pfx_udp_push_pending_frames+0x10/0x10<br /> ? __sys_setsockopt+0xdf/0x1a0<br /> ? __x64_sys_connect+0xf/0x20<br /> ? do_syscall_64+0x3a/0x90<br /> ? entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> Fixing this by disabling preemption in bpf_event_output.<br /> <br /> [1] https://github.com/cilium/cilium/issues/26756

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio: Fix NULL pointer dereference caused by uninitialized group-&gt;iommufd<br /> <br /> group-&gt;iommufd is not initialized for the iommufd_ctx_put()<br /> <br /> [20018.331541] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [20018.377508] RIP: 0010:iommufd_ctx_put+0x5/0x10 [iommufd]<br /> ...<br /> [20018.476483] Call Trace:<br /> [20018.479214] <br /> [20018.481555] vfio_group_fops_unl_ioctl+0x506/0x690 [vfio]<br /> [20018.487586] __x64_sys_ioctl+0x6a/0xb0<br /> [20018.491773] ? trace_hardirqs_on+0xc5/0xe0<br /> [20018.496347] do_syscall_64+0x67/0x90<br /> [20018.500340] entry_SYSCALL_64_after_hwframe+0x4b/0xb5

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: xiic: xiic_xfer(): Fix runtime PM leak on error path<br /> <br /> The xiic_xfer() function gets a runtime PM reference when the function is<br /> entered. This reference is released when the function is exited. There is<br /> currently one error path where the function exits directly, which leads to<br /> a leak of the runtime PM reference.<br /> <br /> Make sure that this error path also releases the runtime PM reference.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: stricter state check in mptcp_worker<br /> <br /> As reported by Christoph, the mptcp protocol can run the<br /> worker when the relevant msk socket is in an unexpected state:<br /> <br /> connect()<br /> // incoming reset + fastclose<br /> // the mptcp worker is scheduled<br /> mptcp_disconnect()<br /> // msk is now CLOSED<br /> listen()<br /> mptcp_worker()<br /> <br /> Leading to the following splat:<br /> <br /> divide error: 0000 [#1] PREEMPT SMP<br /> CPU: 1 PID: 21 Comm: kworker/1:0 Not tainted 6.3.0-rc1-gde5e8fd0123c #11<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014<br /> Workqueue: events mptcp_worker<br /> RIP: 0010:__tcp_select_window+0x22c/0x4b0 net/ipv4/tcp_output.c:3018<br /> RSP: 0018:ffffc900000b3c98 EFLAGS: 00010293<br /> RAX: 000000000000ffd7 RBX: 000000000000ffd7 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: ffffffff8214ce97 RDI: 0000000000000004<br /> RBP: 000000000000ffd7 R08: 0000000000000004 R09: 0000000000010000<br /> R10: 000000000000ffd7 R11: ffff888005afa148 R12: 000000000000ffd7<br /> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000405270 CR3: 000000003011e006 CR4: 0000000000370ee0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> tcp_select_window net/ipv4/tcp_output.c:262 [inline]<br /> __tcp_transmit_skb+0x356/0x1280 net/ipv4/tcp_output.c:1345<br /> tcp_transmit_skb net/ipv4/tcp_output.c:1417 [inline]<br /> tcp_send_active_reset+0x13e/0x320 net/ipv4/tcp_output.c:3459<br /> mptcp_check_fastclose net/mptcp/protocol.c:2530 [inline]<br /> mptcp_worker+0x6c7/0x800 net/mptcp/protocol.c:2705<br /> process_one_work+0x3bd/0x950 kernel/workqueue.c:2390<br /> worker_thread+0x5b/0x610 kernel/workqueue.c:2537<br /> kthread+0x138/0x170 kernel/kthread.c:376<br /> ret_from_fork+0x2c/0x50 arch/x86/entry/entry_64.S:308<br /> <br /> <br /> This change addresses the issue explicitly checking for bad states<br /> before running the mptcp worker.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> quota: fix warning in dqgrab()<br /> <br /> There&amp;#39;s issue as follows when do fault injection:<br /> WARNING: CPU: 1 PID: 14870 at include/linux/quotaops.h:51 dquot_disable+0x13b7/0x18c0<br /> Modules linked in:<br /> CPU: 1 PID: 14870 Comm: fsconfig Not tainted 6.3.0-next-20230505-00006-g5107a9c821af-dirty #541<br /> RIP: 0010:dquot_disable+0x13b7/0x18c0<br /> RSP: 0018:ffffc9000acc79e0 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88825e41b980<br /> RDX: 0000000000000000 RSI: ffff88825e41b980 RDI: 0000000000000002<br /> RBP: ffff888179f68000 R08: ffffffff82087ca7 R09: 0000000000000000<br /> R10: 0000000000000001 R11: ffffed102f3ed026 R12: ffff888179f68130<br /> R13: ffff888179f68110 R14: dffffc0000000000 R15: ffff888179f68118<br /> FS: 00007f450a073740(0000) GS:ffff88882fc00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007ffe96f2efd8 CR3: 000000025c8ad000 CR4: 00000000000006e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> dquot_load_quota_sb+0xd53/0x1060<br /> dquot_resume+0x172/0x230<br /> ext4_reconfigure+0x1dc6/0x27b0<br /> reconfigure_super+0x515/0xa90<br /> __x64_sys_fsconfig+0xb19/0xd20<br /> do_syscall_64+0x39/0xb0<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Above issue may happens as follows:<br /> ProcessA ProcessB ProcessC<br /> sys_fsconfig<br /> vfs_fsconfig_locked<br /> reconfigure_super<br /> ext4_remount<br /> dquot_suspend -&gt; suspend all type quota<br /> <br /> sys_fsconfig<br /> vfs_fsconfig_locked<br /> reconfigure_super<br /> ext4_remount<br /> dquot_resume<br /> ret = dquot_load_quota_sb<br /> add_dquot_ref<br /> do_open -&gt; open file O_RDWR<br /> vfs_open<br /> do_dentry_open<br /> get_write_access<br /> atomic_inc_unless_negative(&amp;inode-&gt;i_writecount)<br /> ext4_file_open<br /> dquot_file_open<br /> dquot_initialize<br /> __dquot_initialize<br /> dqget<br /> atomic_inc(&amp;dquot-&gt;dq_count);<br /> <br /> __dquot_initialize<br /> __dquot_initialize<br /> dqget<br /> if (!test_bit(DQ_ACTIVE_B, &amp;dquot-&gt;dq_flags))<br /> ext4_acquire_dquot<br /> -&gt; Return error DQ_ACTIVE_B flag isn&amp;#39;t set<br /> dquot_disable<br /> invalidate_dquots<br /> if (atomic_read(&amp;dquot-&gt;dq_count))<br /> dqgrab<br /> WARN_ON_ONCE(!test_bit(DQ_ACTIVE_B, &amp;dquot-&gt;dq_flags))<br /> -&gt; Trigger warning<br /> <br /> In the above scenario, &amp;#39;dquot-&gt;dq_flags&amp;#39; has no DQ_ACTIVE_B is normal when<br /> dqgrab().<br /> To solve above issue just replace the dqgrab() use in invalidate_dquots() with<br /> atomic_inc(&amp;dquot-&gt;dq_count).