Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: lpass: Fix for KASAN use_after_free out of bounds<br /> <br /> When we run syzkaller we get below Out of Bounds error.<br /> <br /> "KASAN: slab-out-of-bounds Read in regcache_flat_read"<br /> <br /> Below is the backtrace of the issue:<br /> <br /> BUG: KASAN: slab-out-of-bounds in regcache_flat_read+0x10c/0x110<br /> Read of size 4 at addr ffffff8088fbf714 by task syz-executor.4/14144<br /> CPU: 6 PID: 14144 Comm: syz-executor.4 Tainted: G W<br /> Hardware name: Qualcomm Technologies, Inc. sc7280 CRD platform (rev5+) (DT)<br /> Call trace:<br /> dump_backtrace+0x0/0x4ec<br /> show_stack+0x34/0x50<br /> dump_stack_lvl+0xdc/0x11c<br /> print_address_description+0x30/0x2d8<br /> kasan_report+0x178/0x1e4<br /> __asan_report_load4_noabort+0x44/0x50<br /> regcache_flat_read+0x10c/0x110<br /> regcache_read+0xf8/0x5a0<br /> _regmap_read+0x45c/0x86c<br /> _regmap_update_bits+0x128/0x290<br /> regmap_update_bits_base+0xc0/0x15c<br /> snd_soc_component_update_bits+0xa8/0x22c<br /> snd_soc_component_write_field+0x68/0xd4<br /> tx_macro_put_dec_enum+0x1d0/0x268<br /> snd_ctl_elem_write+0x288/0x474<br /> <br /> By Error checking and checking valid values issue gets rectifies.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-tcp: don&amp;#39;t access released socket during error recovery<br /> <br /> While the error recovery work is temporarily failing reconnect attempts,<br /> running the &amp;#39;nvme list&amp;#39; command causes a kernel NULL pointer dereference<br /> by calling getsockname() with a released socket.<br /> <br /> During error recovery work, the nvme tcp socket is released and a new one<br /> created, so it is not safe to access the socket without proper check.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Make bpf_refcount_acquire fallible for non-owning refs<br /> <br /> This patch fixes an incorrect assumption made in the original<br /> bpf_refcount series [0], specifically that the BPF program calling<br /> bpf_refcount_acquire on some node can always guarantee that the node is<br /> alive. In that series, the patch adding failure behavior to rbtree_add<br /> and list_push_{front, back} breaks this assumption for non-owning<br /> references.<br /> <br /> Consider the following program:<br /> <br /> n = bpf_kptr_xchg(&amp;mapval, NULL);<br /> /* skip error checking */<br /> <br /> bpf_spin_lock(&amp;l);<br /> if(bpf_rbtree_add(&amp;t, &amp;n-&gt;rb, less)) {<br /> bpf_refcount_acquire(n);<br /> /* Failed to add, do something else with the node */<br /> }<br /> bpf_spin_unlock(&amp;l);<br /> <br /> It&amp;#39;s incorrect to assume that bpf_refcount_acquire will always succeed in this<br /> scenario. bpf_refcount_acquire is being called in a critical section<br /> here, but the lock being held is associated with rbtree t, which isn&amp;#39;t<br /> necessarily the lock associated with the tree that the node is already<br /> in. So after bpf_rbtree_add fails to add the node and calls bpf_obj_drop<br /> in it, the program has no ownership of the node&amp;#39;s lifetime. Therefore<br /> the node&amp;#39;s refcount can be decr&amp;#39;d to 0 at any time after the failing<br /> rbtree_add. If this happens before the refcount_acquire above, the node<br /> might be free&amp;#39;d, and regardless refcount_acquire will be incrementing a<br /> 0 refcount.<br /> <br /> Later patches in the series exercise this scenario, resulting in the<br /> expected complaint from the kernel (without this patch&amp;#39;s changes):<br /> <br /> refcount_t: addition on 0; use-after-free.<br /> WARNING: CPU: 1 PID: 207 at lib/refcount.c:25 refcount_warn_saturate+0xbc/0x110<br /> Modules linked in: bpf_testmod(O)<br /> CPU: 1 PID: 207 Comm: test_progs Tainted: G O 6.3.0-rc7-02231-g723de1a718a2-dirty #371<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:refcount_warn_saturate+0xbc/0x110<br /> Code: 6f 64 f6 02 01 e8 84 a3 5c ff 0f 0b eb 9d 80 3d 5e 64 f6 02 00 75 94 48 c7 c7 e0 13 d2 82 c6 05 4e 64 f6 02 01 e8 64 a3 5c ff 0b e9 7a ff ff ff 80 3d 38 64 f6 02 00 0f 85 6d ff ff ff 48 c7<br /> RSP: 0018:ffff88810b9179b0 EFLAGS: 00010082<br /> RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000000<br /> RDX: 0000000000000202 RSI: 0000000000000008 RDI: ffffffff857c3680<br /> RBP: ffff88810027d3c0 R08: ffffffff8125f2a4 R09: ffff88810b9176e7<br /> R10: ffffed1021722edc R11: 746e756f63666572 R12: ffff88810027d388<br /> R13: ffff88810027d3c0 R14: ffffc900005fe030 R15: ffffc900005fe048<br /> FS: 00007fee0584a700(0000) GS:ffff88811b280000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00005634a96f6c58 CR3: 0000000108ce9002 CR4: 0000000000770ee0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> bpf_refcount_acquire_impl+0xb5/0xc0<br /> <br /> (rest of output snipped)<br /> <br /> The patch addresses this by changing bpf_refcount_acquire_impl to use<br /> refcount_inc_not_zero instead of refcount_inc and marking<br /> bpf_refcount_acquire KF_RET_NULL.<br /> <br /> For owning references, though, we know the above scenario is not possible<br /> and thus that bpf_refcount_acquire will always succeed. Some verifier<br /> bookkeeping is added to track "is input owning ref?" for bpf_refcount_acquire<br /> calls and return false from is_kfunc_ret_null for bpf_refcount_acquire on<br /> owning refs despite it being marked KF_RET_NULL.<br /> <br /> Existing selftests using bpf_refcount_acquire are modified where<br /> necessary to NULL-check its return value.<br /> <br /> [0]: https://lore.kernel.org/bpf/20230415201811.343116-1-davemarchevsky@fb.com/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: dell-sysman: Fix reference leak<br /> <br /> If a duplicate attribute is found using kset_find_obj(),<br /> a reference to that attribute is returned. This means<br /> that we need to dispose it accordingly. Use kobject_put()<br /> to dispose the duplicate attribute in such a case.<br /> <br /> Compile-tested only.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Take RTNL lock when needed before calling xdp_set_features()<br /> <br /> Hold RTNL lock when calling xdp_set_features() with a registered netdev,<br /> as the call triggers the netdev notifiers. This could happen when<br /> switching from uplink rep to nic profile for example.<br /> <br /> This resolves the following call trace:<br /> <br /> RTNL: assertion failed at net/core/dev.c (1953)<br /> WARNING: CPU: 6 PID: 112670 at net/core/dev.c:1953 call_netdevice_notifiers_info+0x7c/0x80<br /> Modules linked in: sch_mqprio sch_mqprio_lib act_tunnel_key act_mirred act_skbedit cls_matchall nfnetlink_cttimeout act_gact cls_flower sch_ingress bonding ib_umad ip_gre rdma_ucm mlx5_vfio_pci ipip tunnel4 ip6_gre gre mlx5_ib vfio_pci vfio_pci_core vfio_iommu_type1 ib_uverbs vfio mlx5_core ib_ipoib geneve nf_tables ip6_tunnel tunnel6 iptable_raw openvswitch nsh rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay zram zsmalloc fuse [last unloaded: ib_uverbs]<br /> CPU: 6 PID: 112670 Comm: devlink Not tainted 6.4.0-rc7_for_upstream_min_debug_2023_06_28_17_02 #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:call_netdevice_notifiers_info+0x7c/0x80<br /> Code: 90 ff 80 3d 2d 6b f7 00 00 75 c5 ba a1 07 00 00 48 c7 c6 e4 ce 0b 82 48 c7 c7 c8 f4 04 82 c6 05 11 6b f7 00 01 e8 a4 7c 8e ff 0b eb a2 0f 1f 44 00 00 55 48 89 e5 41 54 48 83 e4 f0 48 83 ec<br /> RSP: 0018:ffff8882a21c3948 EFLAGS: 00010282<br /> RAX: 0000000000000000 RBX: ffffffff82e6f880 RCX: 0000000000000027<br /> RDX: ffff88885f99b5c8 RSI: 0000000000000001 RDI: ffff88885f99b5c0<br /> RBP: 0000000000000028 R08: ffff88887ffabaa8 R09: 0000000000000003<br /> R10: ffff88887fecbac0 R11: ffff88887ff7bac0 R12: ffff8882a21c3968<br /> R13: ffff88811c018940 R14: 0000000000000000 R15: ffff8881274401a0<br /> FS: 00007fe141c81800(0000) GS:ffff88885f980000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f787c28b948 CR3: 000000014bcf3005 CR4: 0000000000370ea0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? __warn+0x79/0x120<br /> ? call_netdevice_notifiers_info+0x7c/0x80<br /> ? report_bug+0x17c/0x190<br /> ? handle_bug+0x3c/0x60<br /> ? exc_invalid_op+0x14/0x70<br /> ? asm_exc_invalid_op+0x16/0x20<br /> ? call_netdevice_notifiers_info+0x7c/0x80<br /> ? call_netdevice_notifiers_info+0x7c/0x80<br /> call_netdevice_notifiers+0x2e/0x50<br /> mlx5e_set_xdp_feature+0x21/0x50 [mlx5_core]<br /> mlx5e_nic_init+0xf1/0x1a0 [mlx5_core]<br /> mlx5e_netdev_init_profile+0x76/0x110 [mlx5_core]<br /> mlx5e_netdev_attach_profile+0x1f/0x90 [mlx5_core]<br /> mlx5e_netdev_change_profile+0x92/0x160 [mlx5_core]<br /> mlx5e_netdev_attach_nic_profile+0x1b/0x30 [mlx5_core]<br /> mlx5e_vport_rep_unload+0xaa/0xc0 [mlx5_core]<br /> __esw_offloads_unload_rep+0x52/0x60 [mlx5_core]<br /> mlx5_esw_offloads_rep_unload+0x52/0x70 [mlx5_core]<br /> esw_offloads_unload_rep+0x34/0x70 [mlx5_core]<br /> esw_offloads_disable+0x2b/0x90 [mlx5_core]<br /> mlx5_eswitch_disable_locked+0x1b9/0x210 [mlx5_core]<br /> mlx5_devlink_eswitch_mode_set+0xf5/0x630 [mlx5_core]<br /> ? devlink_get_from_attrs_lock+0x9e/0x110<br /> devlink_nl_cmd_eswitch_set_doit+0x60/0xe0<br /> genl_family_rcv_msg_doit.isra.0+0xc2/0x110<br /> genl_rcv_msg+0x17d/0x2b0<br /> ? devlink_get_from_attrs_lock+0x110/0x110<br /> ? devlink_nl_cmd_eswitch_get_doit+0x290/0x290<br /> ? devlink_pernet_pre_exit+0xf0/0xf0<br /> ? genl_family_rcv_msg_doit.isra.0+0x110/0x110<br /> netlink_rcv_skb+0x54/0x100<br /> genl_rcv+0x24/0x40<br /> netlink_unicast+0x1f6/0x2c0<br /> netlink_sendmsg+0x232/0x4a0<br /> sock_sendmsg+0x38/0x60<br /> ? _copy_from_user+0x2a/0x60<br /> __sys_sendto+0x110/0x160<br /> ? __count_memcg_events+0x48/0x90<br /> ? handle_mm_fault+0x161/0x260<br /> ? do_user_addr_fault+0x278/0x6e0<br /> __x64_sys_sendto+0x20/0x30<br /> do_syscall_64+0x3d/0x90<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> RIP: 0033<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/qaic: Fix a leak in map_user_pages()<br /> <br /> If get_user_pages_fast() allocates some pages but not as many as we<br /> wanted, then the current code leaks those pages. Call put_page() on<br /> the pages before returning.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, arm64: Fixed a BTI error on returning to patched function<br /> <br /> When BPF_TRAMP_F_CALL_ORIG is set, BPF trampoline uses BLR to jump<br /> back to the instruction next to call site to call the patched function.<br /> For BTI-enabled kernel, the instruction next to call site is usually<br /> PACIASP, in this case, it&amp;#39;s safe to jump back with BLR. But when<br /> the call site is not followed by a PACIASP or bti, a BTI exception<br /> is triggered.<br /> <br /> Here is a fault log:<br /> <br /> Unhandled 64-bit el1h sync exception on CPU0, ESR 0x0000000034000002 -- BTI<br /> CPU: 0 PID: 263 Comm: test_progs Tainted: GF<br /> Hardware name: linux,dummy-virt (DT)<br /> pstate: 40400805 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=-c)<br /> pc : bpf_fentry_test1+0xc/0x30<br /> lr : bpf_trampoline_6442573892_0+0x48/0x1000<br /> sp : ffff80000c0c3a50<br /> x29: ffff80000c0c3a90 x28: ffff0000c2e6c080 x27: 0000000000000000<br /> x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000050<br /> x23: 0000000000000000 x22: 0000ffffcfd2a7f0 x21: 000000000000000a<br /> x20: 0000ffffcfd2a7f0 x19: 0000000000000000 x18: 0000000000000000<br /> x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffcfd2a7f0<br /> x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> x11: 0000000000000000 x10: ffff80000914f5e4 x9 : ffff8000082a1528<br /> x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0101010101010101<br /> x5 : 0000000000000000 x4 : 00000000fffffff2 x3 : 0000000000000001<br /> x2 : ffff8001f4b82000 x1 : 0000000000000000 x0 : 0000000000000001<br /> Kernel panic - not syncing: Unhandled exception<br /> CPU: 0 PID: 263 Comm: test_progs Tainted: GF<br /> Hardware name: linux,dummy-virt (DT)<br /> Call trace:<br /> dump_backtrace+0xec/0x144<br /> show_stack+0x24/0x7c<br /> dump_stack_lvl+0x8c/0xb8<br /> dump_stack+0x18/0x34<br /> panic+0x1cc/0x3ec<br /> __el0_error_handler_common+0x0/0x130<br /> el1h_64_sync_handler+0x60/0xd0<br /> el1h_64_sync+0x78/0x7c<br /> bpf_fentry_test1+0xc/0x30<br /> bpf_fentry_test1+0xc/0x30<br /> bpf_prog_test_run_tracing+0xdc/0x2a0<br /> __sys_bpf+0x438/0x22a0<br /> __arm64_sys_bpf+0x30/0x54<br /> invoke_syscall+0x78/0x110<br /> el0_svc_common.constprop.0+0x6c/0x1d0<br /> do_el0_svc+0x38/0xe0<br /> el0_svc+0x30/0xd0<br /> el0t_64_sync_handler+0x1ac/0x1b0<br /> el0t_64_sync+0x1a0/0x1a4<br /> Kernel Offset: disabled<br /> CPU features: 0x0000,00034c24,f994fdab<br /> Memory Limit: none<br /> <br /> And the instruction next to call site of bpf_fentry_test1 is ADD,<br /> not PACIASP:<br /> <br /> :<br /> bti c<br /> nop<br /> nop<br /> add w0, w0, #0x1<br /> paciasp<br /> <br /> For BPF prog, JIT always puts a PACIASP after call site for BTI-enabled<br /> kernel, so there is no problem. To fix it, replace BLR with RET to bypass<br /> the branch target check.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: microchip: fix potential UAF in auxdev release callback<br /> <br /> Similar to commit 1c11289b34ab ("peci: cpu: Fix use-after-free in<br /> adev_release()"), the auxiliary device is not torn down in the correct<br /> order. If auxiliary_device_add() fails, the release callback will be<br /> called twice, resulting in a UAF. Due to timing, the auxdev code in this<br /> driver "took inspiration" from the aforementioned commit, and thus its<br /> bugs too!<br /> <br /> Moving auxiliary_device_uninit() to the unregister callback instead<br /> avoids the issue.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: i2c: ov772x: Fix memleak in ov772x_probe()<br /> <br /> A memory leak was reported when testing ov772x with bpf mock device:<br /> <br /> AssertionError: unreferenced object 0xffff888109afa7a8 (size 8):<br /> comm "python3", pid 279, jiffies 4294805921 (age 20.681s)<br /> hex dump (first 8 bytes):<br /> 80 22 88 15 81 88 ff ff ."......<br /> backtrace:<br /> [] __kmalloc_node+0x44/0x1b0<br /> [] kvmalloc_node+0x34/0x180<br /> [] v4l2_ctrl_handler_init_class+0x11d/0x180 [videodev]<br /> [] ov772x_probe+0x1c3/0x68c [ov772x]<br /> [] i2c_device_probe+0x28d/0x680<br /> [] really_probe+0x17c/0x3f0<br /> [] __driver_probe_device+0xe3/0x170<br /> [] driver_probe_device+0x49/0x120<br /> [] __device_attach_driver+0xf7/0x150<br /> [] bus_for_each_drv+0x114/0x180<br /> [] __device_attach+0x1e5/0x2d0<br /> [] bus_probe_device+0x126/0x140<br /> [] device_add+0x810/0x1130<br /> [] i2c_new_client_device+0x359/0x4f0<br /> [] of_i2c_register_device+0xf1/0x110<br /> [] of_i2c_notify+0x100/0x160<br /> unreferenced object 0xffff888119825c00 (size 256):<br /> comm "python3", pid 279, jiffies 4294805921 (age 20.681s)<br /> hex dump (first 32 bytes):<br /> 00 b4 a5 17 81 88 ff ff 00 5e 82 19 81 88 ff ff .........^......<br /> 10 5c 82 19 81 88 ff ff 10 5c 82 19 81 88 ff ff .\.......\......<br /> backtrace:<br /> [] __kmalloc_node+0x44/0x1b0<br /> [] kvmalloc_node+0x34/0x180<br /> [] v4l2_ctrl_new.cold+0x19b/0x86f [videodev]<br /> [] v4l2_ctrl_new_std+0x16f/0x210 [videodev]<br /> [] ov772x_probe+0x1fa/0x68c [ov772x]<br /> [] i2c_device_probe+0x28d/0x680<br /> [] really_probe+0x17c/0x3f0<br /> [] __driver_probe_device+0xe3/0x170<br /> [] driver_probe_device+0x49/0x120<br /> [] __device_attach_driver+0xf7/0x150<br /> [] bus_for_each_drv+0x114/0x180<br /> [] __device_attach+0x1e5/0x2d0<br /> [] bus_probe_device+0x126/0x140<br /> [] device_add+0x810/0x1130<br /> [] i2c_new_client_device+0x359/0x4f0<br /> [] of_i2c_register_device+0xf1/0x110<br /> <br /> The reason is that if priv-&gt;hdl.error is set, ov772x_probe() jumps to the<br /> error_mutex_destroy without doing v4l2_ctrl_handler_free(), and all<br /> resources allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std()<br /> are leaked.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommufd: Fix unpinning of pages when an access is present<br /> <br /> syzkaller found that the calculation of batch_last_index should use<br /> &amp;#39;start_index&amp;#39; since at input to this function the batch is either empty or<br /> it has already been adjusted to cross any accesses so it will start at the<br /> point we are unmapping from.<br /> <br /> Getting this wrong causes the unmap to run over the end of the pages<br /> which corrupts pages that were never mapped. In most cases this triggers<br /> the num pinned debugging:<br /> <br /> WARNING: CPU: 0 PID: 557 at drivers/iommu/iommufd/pages.c:294 __iopt_area_unfill_domain+0x152/0x560<br /> Modules linked in:<br /> CPU: 0 PID: 557 Comm: repro Not tainted 6.3.0-rc2-eeac8ede1755 #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:__iopt_area_unfill_domain+0x152/0x560<br /> Code: d2 0f ff 44 8b 64 24 54 48 8b 44 24 48 31 ff 44 89 e6 48 89 44 24 38 e8 fc d3 0f ff 45 85 e4 0f 85 eb 01 00 00 e8 0e d2 0f ff 0b e8 07 d2 0f ff 48 8b 44 24 38 89 5c 24 58 89 18 8b 44 24 54<br /> RSP: 0018:ffffc9000108baf0 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 00000000ffffffff RCX: ffffffff821e3f85<br /> RDX: 0000000000000000 RSI: ffff88800faf0000 RDI: 0000000000000002<br /> RBP: ffffc9000108bd18 R08: 000000000003ca25 R09: 0000000000000014<br /> R10: 000000000003ca00 R11: 0000000000000024 R12: 0000000000000004<br /> R13: 0000000000000801 R14: 00000000000007ff R15: 0000000000000800<br /> FS: 00007f3499ce1740(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000020000243 CR3: 00000000179c2001 CR4: 0000000000770ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> iopt_area_unfill_domain+0x32/0x40<br /> iopt_table_remove_domain+0x23f/0x4c0<br /> iommufd_device_selftest_detach+0x3a/0x90<br /> iommufd_selftest_destroy+0x55/0x70<br /> iommufd_object_destroy_user+0xce/0x130<br /> iommufd_destroy+0xa2/0xc0<br /> iommufd_fops_ioctl+0x206/0x330<br /> __x64_sys_ioctl+0x10e/0x160<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> Also add some useful WARN_ON sanity checks.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: conntrack: fix wrong ct-&gt;timeout value<br /> <br /> (struct nf_conn)-&gt;timeout is an interval before the conntrack<br /> confirmed. After confirmed, it becomes a timestamp.<br /> <br /> It is observed that timeout of an unconfirmed conntrack:<br /> - Set by calling ctnetlink_change_timeout(). As a result,<br /> `nfct_time_stamp` was wrongly added to `ct-&gt;timeout` twice.<br /> - Get by calling ctnetlink_dump_timeout(). As a result,<br /> `nfct_time_stamp` was wrongly subtracted.<br /> <br /> Call Trace:<br /> <br /> dump_stack_lvl<br /> ctnetlink_dump_timeout<br /> __ctnetlink_glue_build<br /> ctnetlink_glue_build<br /> __nfqnl_enqueue_packet<br /> nf_queue<br /> nf_hook_slow<br /> ip_mc_output<br /> ? __pfx_ip_finish_output<br /> ip_send_skb<br /> ? __pfx_dst_output<br /> udp_send_skb<br /> udp_sendmsg<br /> ? __pfx_ip_generic_getfrag<br /> sock_sendmsg<br /> <br /> Separate the 2 cases in:<br /> - Setting `ct-&gt;timeout` in __nf_ct_set_timeout().<br /> - Getting `ct-&gt;timeout` in ctnetlink_dump_timeout().<br /> <br /> Pablo appends:<br /> <br /> Update ctnetlink to set up the timeout _after_ the IPS_CONFIRMED flag is<br /> set on, otherwise conntrack creation via ctnetlink breaks.<br /> <br /> Note that the problem described in this patch occurs since the<br /> introduction of the nfnetlink_queue conntrack support, select a<br /> sufficiently old Fixes: tag for -stable kernel to pick up this fix.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/swap: fix swap_info_struct race between swapoff and get_swap_pages()<br /> <br /> The si-&gt;lock must be held when deleting the si from the available list. <br /> Otherwise, another thread can re-add the si to the available list, which<br /> can lead to memory corruption. The only place we have found where this<br /> happens is in the swapoff path. This case can be described as below:<br /> <br /> core 0 core 1<br /> swapoff<br /> <br /> del_from_avail_list(si) waiting<br /> <br /> try lock si-&gt;lock acquire swap_avail_lock<br /> and re-add si into<br /> swap_avail_head<br /> <br /> acquire si-&gt;lock but missing si already being added again, and continuing<br /> to clear SWP_WRITEOK, etc.<br /> <br /> It can be easily found that a massive warning messages can be triggered<br /> inside get_swap_pages() by some special cases, for example, we call<br /> madvise(MADV_PAGEOUT) on blocks of touched memory concurrently, meanwhile,<br /> run much swapon-swapoff operations (e.g. stress-ng-swap).<br /> <br /> However, in the worst case, panic can be caused by the above scene. In<br /> swapoff(), the memory used by si could be kept in swap_info[] after<br /> turning off a swap. This means memory corruption will not be caused<br /> immediately until allocated and reset for a new swap in the swapon path. <br /> A panic message caused: (with CONFIG_PLIST_DEBUG enabled)<br /> <br /> ------------[ cut here ]------------<br /> top: 00000000e58a3003, n: 0000000013e75cda, p: 000000008cd4451a<br /> prev: 0000000035b1e58a, n: 000000008cd4451a, p: 000000002150ee8d<br /> next: 000000008cd4451a, n: 000000008cd4451a, p: 000000008cd4451a<br /> WARNING: CPU: 21 PID: 1843 at lib/plist.c:60 plist_check_prev_next_node+0x50/0x70<br /> Modules linked in: rfkill(E) crct10dif_ce(E)...<br /> CPU: 21 PID: 1843 Comm: stress-ng Kdump: ... 5.10.134+<br /> Hardware name: Alibaba Cloud ECS, BIOS 0.0.0 02/06/2015<br /> pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--)<br /> pc : plist_check_prev_next_node+0x50/0x70<br /> lr : plist_check_prev_next_node+0x50/0x70<br /> sp : ffff0018009d3c30<br /> x29: ffff0018009d3c40 x28: ffff800011b32a98<br /> x27: 0000000000000000 x26: ffff001803908000<br /> x25: ffff8000128ea088 x24: ffff800011b32a48<br /> x23: 0000000000000028 x22: ffff001800875c00<br /> x21: ffff800010f9e520 x20: ffff001800875c00<br /> x19: ffff001800fdc6e0 x18: 0000000000000030<br /> x17: 0000000000000000 x16: 0000000000000000<br /> x15: 0736076307640766 x14: 0730073007380731<br /> x13: 0736076307640766 x12: 0730073007380731<br /> x11: 000000000004058d x10: 0000000085a85b76<br /> x9 : ffff8000101436e4 x8 : ffff800011c8ce08<br /> x7 : 0000000000000000 x6 : 0000000000000001<br /> x5 : ffff0017df9ed338 x4 : 0000000000000001<br /> x3 : ffff8017ce62a000 x2 : ffff0017df9ed340<br /> x1 : 0000000000000000 x0 : 0000000000000000<br /> Call trace:<br /> plist_check_prev_next_node+0x50/0x70<br /> plist_check_head+0x80/0xf0<br /> plist_add+0x28/0x140<br /> add_to_avail_list+0x9c/0xf0<br /> _enable_swap_info+0x78/0xb4<br /> __do_sys_swapon+0x918/0xa10<br /> __arm64_sys_swapon+0x20/0x30<br /> el0_svc_common+0x8c/0x220<br /> do_el0_svc+0x2c/0x90<br /> el0_svc+0x1c/0x30<br /> el0_sync_handler+0xa8/0xb0<br /> el0_sync+0x148/0x180<br /> irq event stamp: 2082270<br /> <br /> Now, si-&gt;lock locked before calling &amp;#39;del_from_avail_list()&amp;#39; to make sure<br /> other thread see the si had been deleted and SWP_WRITEOK cleared together,<br /> will not reinsert again.<br /> <br /> This problem exists in versions after stable 5.10.y.