Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: seqiv - Handle EBUSY correctly<br /> <br /> As it is seqiv only handles the special return value of EINPROGERSS,<br /> which means that in all other cases it will free data related to the<br /> request.<br /> <br /> However, as the caller of seqiv may specify MAY_BACKLOG, we also need<br /> to expect EBUSY and treat it in the same way. Otherwise backlogged<br /> requests will trigger a use-after-free.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dcb: choose correct policy to parse DCB_ATTR_BCN<br /> <br /> The dcbnl_bcn_setcfg uses erroneous policy to parse tb[DCB_ATTR_BCN],<br /> which is introduced in commit 859ee3c43812 ("DCB: Add support for DCB<br /> BCN"). Please see the comment in below code<br /> <br /> static int dcbnl_bcn_setcfg(...)<br /> {<br /> ...<br /> ret = nla_parse_nested_deprecated(..., dcbnl_pfc_up_nest, .. )<br /> // !!! dcbnl_pfc_up_nest for attributes<br /> // DCB_PFC_UP_ATTR_0 to DCB_PFC_UP_ATTR_ALL in enum dcbnl_pfc_up_attrs<br /> ...<br /> for (i = DCB_BCN_ATTR_RP_0; i

*** 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 /> mm/mempolicy: fix memory leak in set_mempolicy_home_node system call<br /> <br /> When encountering any vma in the range with policy other than MPOL_BIND or<br /> MPOL_PREFERRED_MANY, an error is returned without issuing a mpol_put on<br /> the policy just allocated with mpol_dup().<br /> <br /> This allows arbitrary users to leak kernel memory.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> integrity: Fix memory leakage in keyring allocation error path<br /> <br /> Key restriction is allocated in integrity_init_keyring(). However, if<br /> keyring allocation failed, it is not freed, causing memory leaks.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: sched: fix memory leak in tcindex_set_parms<br /> <br /> Syzkaller reports a memory leak as follows:<br /> ====================================<br /> BUG: memory leak<br /> unreferenced object 0xffff88810c287f00 (size 256):<br /> comm "syz-executor105", pid 3600, jiffies 4294943292 (age 12.990s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046<br /> [] kmalloc include/linux/slab.h:576 [inline]<br /> [] kmalloc_array include/linux/slab.h:627 [inline]<br /> [] kcalloc include/linux/slab.h:659 [inline]<br /> [] tcf_exts_init include/net/pkt_cls.h:250 [inline]<br /> [] tcindex_set_parms+0xa7/0xbe0 net/sched/cls_tcindex.c:342<br /> [] tcindex_change+0xdf/0x120 net/sched/cls_tcindex.c:553<br /> [] tc_new_tfilter+0x4f2/0x1100 net/sched/cls_api.c:2147<br /> [] rtnetlink_rcv_msg+0x4dc/0x5d0 net/core/rtnetlink.c:6082<br /> [] netlink_rcv_skb+0x87/0x1d0 net/netlink/af_netlink.c:2540<br /> [] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]<br /> [] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345<br /> [] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921<br /> [] sock_sendmsg_nosec net/socket.c:714 [inline]<br /> [] sock_sendmsg+0x56/0x80 net/socket.c:734<br /> [] ____sys_sendmsg+0x178/0x410 net/socket.c:2482<br /> [] ___sys_sendmsg+0xa8/0x110 net/socket.c:2536<br /> [] __sys_sendmmsg+0x105/0x330 net/socket.c:2622<br /> [] __do_sys_sendmmsg net/socket.c:2651 [inline]<br /> [] __se_sys_sendmmsg net/socket.c:2648 [inline]<br /> [] __x64_sys_sendmmsg+0x24/0x30 net/socket.c:2648<br /> [] do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> [] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> ====================================<br /> <br /> Kernel uses tcindex_change() to change an existing<br /> filter properties.<br /> <br /> Yet the problem is that, during the process of changing,<br /> if `old_r` is retrieved from `p-&gt;perfect`, then<br /> kernel uses tcindex_alloc_perfect_hash() to newly<br /> allocate filter results, uses tcindex_filter_result_init()<br /> to clear the old filter result, without destroying<br /> its tcf_exts structure, which triggers the above memory leak.<br /> <br /> To be more specific, there are only two source for the `old_r`,<br /> according to the tcindex_lookup(). `old_r` is retrieved from<br /> `p-&gt;perfect`, or `old_r` is retrieved from `p-&gt;h`.<br /> <br /> * If `old_r` is retrieved from `p-&gt;perfect`, kernel uses<br /> tcindex_alloc_perfect_hash() to newly allocate the<br /> filter results. Then `r` is assigned with `cp-&gt;perfect + handle`,<br /> which is newly allocated. So condition `old_r &amp;&amp; old_r != r` is<br /> true in this situation, and kernel uses tcindex_filter_result_init()<br /> to clear the old filter result, without destroying<br /> its tcf_exts structure<br /> <br /> * If `old_r` is retrieved from `p-&gt;h`, then `p-&gt;perfect` is NULL<br /> according to the tcindex_lookup(). Considering that `cp-&gt;h`<br /> is directly copied from `p-&gt;h` and `p-&gt;perfect` is NULL,<br /> `r` is assigned with `tcindex_lookup(cp, handle)`, whose value<br /> should be the same as `old_r`, so condition `old_r &amp;&amp; old_r != r`<br /> is false in this situation, kernel ignores using<br /> tcindex_filter_result_init() to clear the old filter result.<br /> <br /> So only when `old_r` is retrieved from `p-&gt;perfect` does kernel use<br /> tcindex_filter_result_init() to clear the old filter result, which<br /> triggers the above memory leak.<br /> <br /> Considering that there already exists a tc_filter_wq workqueue<br /> to destroy the old tcindex_d<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: ismt: Fix an out-of-bounds bug in ismt_access()<br /> <br /> When the driver does not check the data from the user, the variable<br /> &amp;#39;data-&gt;block[0]&amp;#39; may be very large to cause an out-of-bounds bug.<br /> <br /> The following log can reveal it:<br /> <br /> [ 33.995542] i2c i2c-1: ioctl, cmd=0x720, arg=0x7ffcb3dc3a20<br /> [ 33.995978] ismt_smbus 0000:00:05.0: I2C_SMBUS_BLOCK_DATA: WRITE<br /> [ 33.996475] ==================================================================<br /> [ 33.996995] BUG: KASAN: out-of-bounds in ismt_access.cold+0x374/0x214b<br /> [ 33.997473] Read of size 18446744073709551615 at addr ffff88810efcfdb1 by task ismt_poc/485<br /> [ 33.999450] Call Trace:<br /> [ 34.001849] memcpy+0x20/0x60<br /> [ 34.002077] ismt_access.cold+0x374/0x214b<br /> [ 34.003382] __i2c_smbus_xfer+0x44f/0xfb0<br /> [ 34.004007] i2c_smbus_xfer+0x10a/0x390<br /> [ 34.004291] i2cdev_ioctl_smbus+0x2c8/0x710<br /> [ 34.005196] i2cdev_ioctl+0x5ec/0x74c<br /> <br /> Fix this bug by checking the size of &amp;#39;data-&gt;block[0]&amp;#39; first.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: SDMA update use unlocked iterator<br /> <br /> SDMA update page table may be called from unlocked context, this<br /> generate below warning. Use unlocked iterator to handle this case.<br /> <br /> WARNING: CPU: 0 PID: 1475 at<br /> drivers/dma-buf/dma-resv.c:483 dma_resv_iter_next<br /> Call Trace:<br /> dma_resv_iter_first+0x43/0xa0<br /> amdgpu_vm_sdma_update+0x69/0x2d0 [amdgpu]<br /> amdgpu_vm_ptes_update+0x29c/0x870 [amdgpu]<br /> amdgpu_vm_update_range+0x2f6/0x6c0 [amdgpu]<br /> svm_range_unmap_from_gpus+0x115/0x300 [amdgpu]<br /> svm_range_cpu_invalidate_pagetables+0x510/0x5e0 [amdgpu]<br /> __mmu_notifier_invalidate_range_start+0x1d3/0x230<br /> unmap_vmas+0x140/0x150<br /> unmap_region+0xa8/0x110

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mediatek: mt8183: fix refcount leak in mt8183_mt6358_ts3a227_max98357_dev_probe()<br /> <br /> The node returned by of_parse_phandle() with refcount incremented,<br /> of_node_put() needs be called when finish using it. So add it in the<br /> error path in mt8183_mt6358_ts3a227_max98357_dev_probe().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mediatek: vcodec: Can&amp;#39;t set dst buffer to done when lat decode error<br /> <br /> Core thread will call v4l2_m2m_buf_done to set dst buffer done for<br /> lat architecture. If lat call v4l2_m2m_buf_done_and_job_finish to<br /> free dst buffer when lat decode error, core thread will access kernel<br /> NULL pointer dereference, then crash.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme: fix multipath crash caused by flush request when blktrace is enabled<br /> <br /> The flush request initialized by blk_kick_flush has NULL bio,<br /> and it may be dealt with nvme_end_req during io completion.<br /> When blktrace is enabled, nvme_trace_bio_complete with multipath<br /> activated trying to access NULL pointer bio from flush request<br /> results in the following crash:<br /> <br /> [ 2517.831677] BUG: kernel NULL pointer dereference, address: 000000000000001a<br /> [ 2517.835213] #PF: supervisor read access in kernel mode<br /> [ 2517.838724] #PF: error_code(0x0000) - not-present page<br /> [ 2517.842222] PGD 7b2d51067 P4D 0<br /> [ 2517.845684] Oops: 0000 [#1] SMP NOPTI<br /> [ 2517.849125] CPU: 2 PID: 732 Comm: kworker/2:1H Kdump: loaded Tainted: G S 5.15.67-0.cl9.x86_64 #1<br /> [ 2517.852723] Hardware name: XFUSION 2288H V6/BC13MBSBC, BIOS 1.13 07/27/2022<br /> [ 2517.856358] Workqueue: nvme_tcp_wq nvme_tcp_io_work [nvme_tcp]<br /> [ 2517.859993] RIP: 0010:blk_add_trace_bio_complete+0x6/0x30<br /> [ 2517.863628] Code: 1f 44 00 00 48 8b 46 08 31 c9 ba 04 00 10 00 48 8b 80 50 03 00 00 48 8b 78 50 e9 e5 fe ff ff 0f 1f 44 00 00 41 54 49 89 f4 55 b6 7a 1a 48 89 d5 e8 3e 1c 2b 00 48 89 ee 4c 89 e7 5d 89 c1 ba<br /> [ 2517.871269] RSP: 0018:ff7f6a008d9dbcd0 EFLAGS: 00010286<br /> [ 2517.875081] RAX: ff3d5b4be00b1d50 RBX: 0000000002040002 RCX: ff3d5b0a270f2000<br /> [ 2517.878966] RDX: 0000000000000000 RSI: ff3d5b0b021fb9f8 RDI: 0000000000000000<br /> [ 2517.882849] RBP: ff3d5b0b96a6fa00 R08: 0000000000000001 R09: 0000000000000000<br /> [ 2517.886718] R10: 000000000000000c R11: 000000000000000c R12: ff3d5b0b021fb9f8<br /> [ 2517.890575] R13: 0000000002000000 R14: ff3d5b0b021fb1b0 R15: 0000000000000018<br /> [ 2517.894434] FS: 0000000000000000(0000) GS:ff3d5b42bfc80000(0000) knlGS:0000000000000000<br /> [ 2517.898299] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 2517.902157] CR2: 000000000000001a CR3: 00000004f023e005 CR4: 0000000000771ee0<br /> [ 2517.906053] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 2517.909930] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 2517.913761] PKRU: 55555554<br /> [ 2517.917558] Call Trace:<br /> [ 2517.921294] <br /> [ 2517.924982] nvme_complete_rq+0x1c3/0x1e0 [nvme_core]<br /> [ 2517.928715] nvme_tcp_recv_pdu+0x4d7/0x540 [nvme_tcp]<br /> [ 2517.932442] nvme_tcp_recv_skb+0x4f/0x240 [nvme_tcp]<br /> [ 2517.936137] ? nvme_tcp_recv_pdu+0x540/0x540 [nvme_tcp]<br /> [ 2517.939830] tcp_read_sock+0x9c/0x260<br /> [ 2517.943486] nvme_tcp_try_recv+0x65/0xa0 [nvme_tcp]<br /> [ 2517.947173] nvme_tcp_io_work+0x64/0x90 [nvme_tcp]<br /> [ 2517.950834] process_one_work+0x1e8/0x390<br /> [ 2517.954473] worker_thread+0x53/0x3c0<br /> [ 2517.958069] ? process_one_work+0x390/0x390<br /> [ 2517.961655] kthread+0x10c/0x130<br /> [ 2517.965211] ? set_kthread_struct+0x40/0x40<br /> [ 2517.968760] ret_from_fork+0x1f/0x30<br /> [ 2517.972285] <br /> <br /> To avoid this situation, add a NULL check for req-&gt;bio before<br /> calling trace_block_bio_complete.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hinic: fix the issue of CMDQ memory leaks<br /> <br /> When hinic_set_cmdq_depth() fails in hinic_init_cmdqs(), the cmdq memory is<br /> not released correctly. Fix it.