Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Fix null-ptr-deref on inode-&gt;i_op in ntfs_lookup()<br /> <br /> Syzbot reported a null-ptr-deref bug:<br /> <br /> ntfs3: loop0: Different NTFS&amp;#39; sector size (1024) and media sector size<br /> (512)<br /> ntfs3: loop0: Mark volume as dirty due to NTFS errors<br /> general protection fault, probably for non-canonical address<br /> 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]<br /> RIP: 0010:d_flags_for_inode fs/dcache.c:1980 [inline]<br /> RIP: 0010:__d_add+0x5ce/0x800 fs/dcache.c:2796<br /> Call Trace:<br /> <br /> d_splice_alias+0x122/0x3b0 fs/dcache.c:3191<br /> lookup_open fs/namei.c:3391 [inline]<br /> open_last_lookups fs/namei.c:3481 [inline]<br /> path_openat+0x10e6/0x2df0 fs/namei.c:3688<br /> do_filp_open+0x264/0x4f0 fs/namei.c:3718<br /> do_sys_openat2+0x124/0x4e0 fs/open.c:1310<br /> do_sys_open fs/open.c:1326 [inline]<br /> __do_sys_open fs/open.c:1334 [inline]<br /> __se_sys_open fs/open.c:1330 [inline]<br /> __x64_sys_open+0x221/0x270 fs/open.c:1330<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> If the MFT record of ntfs inode is not a base record, inode-&gt;i_op can be<br /> NULL. And a null-ptr-deref may happen:<br /> <br /> ntfs_lookup()<br /> dir_search_u() # inode-&gt;i_op is set to NULL<br /> d_splice_alias()<br /> __d_add()<br /> d_flags_for_inode() # inode-&gt;i_op-&gt;get_link null-ptr-deref<br /> <br /> Fix this by adding a Check on inode-&gt;i_op before calling the<br /> d_splice_alias() function.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udf: Do not update file length for failed writes to inline files<br /> <br /> When write to inline file fails (or happens only partly), we still<br /> updated length of inline data as if the whole write succeeded. Fix the<br /> update of length of inline data to happen only if the write succeeds.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: check send stream number after wait_for_sndbuf<br /> <br /> This patch fixes a corner case where the asoc out stream count may change<br /> after wait_for_sndbuf.<br /> <br /> When the main thread in the client starts a connection, if its out stream<br /> count is set to N while the in stream count in the server is set to N - 2,<br /> another thread in the client keeps sending the msgs with stream number<br /> N - 1, and waits for sndbuf before processing INIT_ACK.<br /> <br /> However, after processing INIT_ACK, the out stream count in the client is<br /> shrunk to N - 2, the same to the in stream count in the server. The crash<br /> occurs when the thread waiting for sndbuf is awake and sends the msg in a<br /> non-existing stream(N - 1), the call trace is as below:<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]<br /> Call Trace:<br /> <br /> sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1114 [inline]<br /> sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1777 [inline]<br /> sctp_side_effects net/sctp/sm_sideeffect.c:1199 [inline]<br /> sctp_do_sm+0x197d/0x5310 net/sctp/sm_sideeffect.c:1170<br /> sctp_primitive_SEND+0x9f/0xc0 net/sctp/primitive.c:163<br /> sctp_sendmsg_to_asoc+0x10eb/0x1a30 net/sctp/socket.c:1868<br /> sctp_sendmsg+0x8d4/0x1d90 net/sctp/socket.c:2026<br /> inet_sendmsg+0x9d/0xe0 net/ipv4/af_inet.c:825<br /> sock_sendmsg_nosec net/socket.c:722 [inline]<br /> sock_sendmsg+0xde/0x190 net/socket.c:745<br /> <br /> The fix is to add an unlikely check for the send stream number after the<br /> thread wakes up from the wait_for_sndbuf.

*** 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 /> drivers: staging: rtl8723bs: Fix locking in _rtw_join_timeout_handler()<br /> <br /> Commit 041879b12ddb ("drivers: staging: rtl8192bs: Fix deadlock in<br /> rtw_joinbss_event_prehandle()") besides fixing the deadlock also<br /> modified _rtw_join_timeout_handler() to use spin_[un]lock_irq()<br /> instead of spin_[un]lock_bh().<br /> <br /> _rtw_join_timeout_handler() calls rtw_do_join() which takes<br /> pmlmepriv-&gt;scanned_queue.lock using spin_[un]lock_bh(). This<br /> spin_unlock_bh() call re-enables softirqs which triggers an oops in<br /> kernel/softirq.c: __local_bh_enable_ip() when it calls<br /> lockdep_assert_irqs_enabled():<br /> <br /> [ 244.506087] WARNING: CPU: 2 PID: 0 at kernel/softirq.c:376 __local_bh_enable_ip+0xa6/0x100<br /> ...<br /> [ 244.509022] Call Trace:<br /> [ 244.509048] <br /> [ 244.509100] _rtw_join_timeout_handler+0x134/0x170 [r8723bs]<br /> [ 244.509468] ? __pfx__rtw_join_timeout_handler+0x10/0x10 [r8723bs]<br /> [ 244.509772] ? __pfx__rtw_join_timeout_handler+0x10/0x10 [r8723bs]<br /> [ 244.510076] call_timer_fn+0x95/0x2a0<br /> [ 244.510200] __run_timers.part.0+0x1da/0x2d0<br /> <br /> This oops is causd by the switch to spin_[un]lock_irq() which disables<br /> the IRQs for the entire duration of _rtw_join_timeout_handler().<br /> <br /> Disabling the IRQs is not necessary since all code taking this lock<br /> runs from either user contexts or from softirqs, switch back to<br /> spin_[un]lock_bh() to fix this.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Fix use-after-free KFENCE violation during sysfs firmware write<br /> <br /> During the sysfs firmware write process, a use-after-free read warning is<br /> logged from the lpfc_wr_object() routine:<br /> <br /> BUG: KFENCE: use-after-free read in lpfc_wr_object+0x235/0x310 [lpfc]<br /> Use-after-free read at 0x0000000000cf164d (in kfence-#111):<br /> lpfc_wr_object+0x235/0x310 [lpfc]<br /> lpfc_write_firmware.cold+0x206/0x30d [lpfc]<br /> lpfc_sli4_request_firmware_update+0xa6/0x100 [lpfc]<br /> lpfc_request_firmware_upgrade_store+0x66/0xb0 [lpfc]<br /> kernfs_fop_write_iter+0x121/0x1b0<br /> new_sync_write+0x11c/0x1b0<br /> vfs_write+0x1ef/0x280<br /> ksys_write+0x5f/0xe0<br /> do_syscall_64+0x59/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> The driver accessed wr_object pointer data, which was initialized into<br /> mailbox payload memory, after the mailbox object was released back to the<br /> mailbox pool.<br /> <br /> Fix by moving the mailbox free calls to the end of the routine ensuring<br /> that we don&amp;#39;t reference internal mailbox memory after release.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dpu: check for null return of devm_kzalloc() in dpu_writeback_init()<br /> <br /> Because of the possilble failure of devm_kzalloc(), dpu_wb_conn might<br /> be NULL and will cause null pointer dereference later.<br /> <br /> Therefore, it might be better to check it and directly return -ENOMEM.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/512277/<br /> [DB: fixed typo in commit message]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: add bounds checking in get_max_inline_xattr_value_size()<br /> <br /> Normally the extended attributes in the inode body would have been<br /> checked when the inode is first opened, but if someone is writing to<br /> the block device while the file system is mounted, it&amp;#39;s possible for<br /> the inode table to get corrupted. Add bounds checking to avoid<br /> reading beyond the end of allocated memory if this happens.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Return the firmware result upon destroying QP/RQ<br /> <br /> Previously when destroying a QP/RQ, the result of the firmware<br /> destruction function was ignored and upper layers weren&amp;#39;t informed<br /> about the failure.<br /> Which in turn could lead to various problems since when upper layer<br /> isn&amp;#39;t aware of the failure it continues its operation thinking that the<br /> related QP/RQ was successfully destroyed while it actually wasn&amp;#39;t,<br /> which could lead to the below kernel WARN.<br /> <br /> Currently, we return the correct firmware destruction status to upper<br /> layers which in case of the RQ would be mlx5_ib_destroy_wq() which<br /> was already capable of handling RQ destruction failure or in case of<br /> a QP to destroy_qp_common(), which now would actually warn upon qp<br /> destruction failure.<br /> <br /> WARNING: CPU: 3 PID: 995 at drivers/infiniband/core/rdma_core.c:940 uverbs_destroy_ufile_hw+0xcb/0xe0 [ib_uverbs]<br /> Modules linked in: xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_umad ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core overlay mlx5_core fuse<br /> CPU: 3 PID: 995 Comm: python3 Not tainted 5.16.0-rc5+ #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:uverbs_destroy_ufile_hw+0xcb/0xe0 [ib_uverbs]<br /> Code: 41 5c 41 5d 41 5e e9 44 34 f0 e0 48 89 df e8 4c 77 ff ff 49 8b 86 10 01 00 00 48 85 c0 74 a1 4c 89 e7 ff d0 eb 9a 0f 0b eb c1 0b be 04 00 00 00 48 89 df e8 b6 f6 ff ff e9 75 ff ff ff 90 0f<br /> RSP: 0018:ffff8881533e3e78 EFLAGS: 00010287<br /> RAX: ffff88811b2cf3e0 RBX: ffff888106209700 RCX: 0000000000000000<br /> RDX: ffff888106209780 RSI: ffff8881533e3d30 RDI: ffff888109b101a0<br /> RBP: 0000000000000001 R08: ffff888127cb381c R09: 0de9890000000009<br /> R10: ffff888127cb3800 R11: 0000000000000000 R12: ffff888106209780<br /> R13: ffff888106209750 R14: ffff888100f20660 R15: 0000000000000000<br /> FS: 00007f8be353b740(0000) GS:ffff88852c980000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f8bd5b117c0 CR3: 000000012cd8a004 CR4: 0000000000370ea0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ib_uverbs_close+0x1a/0x90 [ib_uverbs]<br /> __fput+0x82/0x230<br /> task_work_run+0x59/0x90<br /> exit_to_user_mode_prepare+0x138/0x140<br /> syscall_exit_to_user_mode+0x1d/0x50<br /> ? __x64_sys_close+0xe/0x40<br /> do_syscall_64+0x4a/0x90<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7f8be3ae0abb<br /> Code: 03 00 00 00 0f 05 48 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 83 43 f9 ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 3d 00 f0 ff ff 77 35 44 89 c7 89 44 24 0c e8 c1 43 f9 ff 8b 44<br /> RSP: 002b:00007ffdb51909c0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003<br /> RAX: 0000000000000000 RBX: 0000557bb7f7c020 RCX: 00007f8be3ae0abb<br /> RDX: 0000557bb7c74010 RSI: 0000557bb7f14ca0 RDI: 0000000000000005<br /> RBP: 0000557bb7fbd598 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000293 R12: 0000557bb7fbd5b8<br /> R13: 0000557bb7fbd5a8 R14: 0000000000001000 R15: 0000557bb7f7c020<br />

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: cdns3: Put the cdns set active part outside the spin lock<br /> <br /> The device may be scheduled during the resume process,<br /> so this cannot appear in atomic operations. Since<br /> pm_runtime_set_active will resume suppliers, put set<br /> active outside the spin lock, which is only used to<br /> protect the struct cdns data structure, otherwise the<br /> kernel will report the following warning:<br /> <br /> BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1163<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 651, name: sh<br /> preempt_count: 1, expected: 0<br /> RCU nest depth: 0, expected: 0<br /> CPU: 0 PID: 651 Comm: sh Tainted: G WC 6.1.20 #1<br /> Hardware name: Freescale i.MX8QM MEK (DT)<br /> Call trace:<br /> dump_backtrace.part.0+0xe0/0xf0<br /> show_stack+0x18/0x30<br /> dump_stack_lvl+0x64/0x80<br /> dump_stack+0x1c/0x38<br /> __might_resched+0x1fc/0x240<br /> __might_sleep+0x68/0xc0<br /> __pm_runtime_resume+0x9c/0xe0<br /> rpm_get_suppliers+0x68/0x1b0<br /> __pm_runtime_set_status+0x298/0x560<br /> cdns_resume+0xb0/0x1c0<br /> cdns3_controller_resume.isra.0+0x1e0/0x250<br /> cdns3_plat_resume+0x28/0x40

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/client: Fix memory leak in drm_client_modeset_probe<br /> <br /> When a new mode is set to modeset-&gt;mode, the previous mode should be freed.<br /> This fixes the following kmemleak report:<br /> <br /> drm_mode_duplicate+0x45/0x220 [drm]<br /> drm_client_modeset_probe+0x944/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

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ena: fix shift-out-of-bounds in exponential backoff<br /> <br /> The ENA adapters on our instances occasionally reset. Once recently<br /> logged a UBSAN failure to console in the process:<br /> <br /> UBSAN: shift-out-of-bounds in build/linux/drivers/net/ethernet/amazon/ena/ena_com.c:540:13<br /> shift exponent 32 is too large for 32-bit type &amp;#39;unsigned int&amp;#39;<br /> CPU: 28 PID: 70012 Comm: kworker/u72:2 Kdump: loaded not tainted 5.15.117<br /> Hardware name: Amazon EC2 c5d.9xlarge/, BIOS 1.0 10/16/2017<br /> Workqueue: ena ena_fw_reset_device [ena]<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x4a/0x63<br /> dump_stack+0x10/0x16<br /> ubsan_epilogue+0x9/0x36<br /> __ubsan_handle_shift_out_of_bounds.cold+0x61/0x10e<br /> ? __const_udelay+0x43/0x50<br /> ena_delay_exponential_backoff_us.cold+0x16/0x1e [ena]<br /> wait_for_reset_state+0x54/0xa0 [ena]<br /> ena_com_dev_reset+0xc8/0x110 [ena]<br /> ena_down+0x3fe/0x480 [ena]<br /> ena_destroy_device+0xeb/0xf0 [ena]<br /> ena_fw_reset_device+0x30/0x50 [ena]<br /> process_one_work+0x22b/0x3d0<br /> worker_thread+0x4d/0x3f0<br /> ? process_one_work+0x3d0/0x3d0<br /> kthread+0x12a/0x150<br /> ? set_kthread_struct+0x50/0x50<br /> ret_from_fork+0x22/0x30<br /> <br /> <br /> Apparently, the reset delays are getting so large they can trigger a<br /> UBSAN panic.<br /> <br /> Looking at the code, the current timeout is capped at 5000us. Using a<br /> base value of 100us, the current code will overflow after (1