Vulnerabilidades

*** 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 /> 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 /> 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 /> drm/amdgpu: drop gfx_v11_0_cp_ecc_error_irq_funcs<br /> <br /> The gfx.cp_ecc_error_irq is retired in gfx11. In gfx_v11_0_hw_fini still<br /> use amdgpu_irq_put to disable this interrupt, which caused the call trace<br /> in this function.<br /> <br /> [ 102.873958] Call Trace:<br /> [ 102.873959] <br /> [ 102.873961] gfx_v11_0_hw_fini+0x23/0x1e0 [amdgpu]<br /> [ 102.874019] gfx_v11_0_suspend+0xe/0x20 [amdgpu]<br /> [ 102.874072] amdgpu_device_ip_suspend_phase2+0x240/0x460 [amdgpu]<br /> [ 102.874122] amdgpu_device_ip_suspend+0x3d/0x80 [amdgpu]<br /> [ 102.874172] amdgpu_device_pre_asic_reset+0xd9/0x490 [amdgpu]<br /> [ 102.874223] amdgpu_device_gpu_recover.cold+0x548/0xce6 [amdgpu]<br /> [ 102.874321] amdgpu_debugfs_reset_work+0x4c/0x70 [amdgpu]<br /> [ 102.874375] process_one_work+0x21f/0x3f0<br /> [ 102.874377] worker_thread+0x200/0x3e0<br /> [ 102.874378] ? process_one_work+0x3f0/0x3f0<br /> [ 102.874379] kthread+0xfd/0x130<br /> [ 102.874380] ? kthread_complete_and_exit+0x20/0x20<br /> [ 102.874381] ret_from_fork+0x22/0x30<br /> <br /> v2:<br /> - Handle umc and gfx ras cases in separated patch<br /> - Retired the gfx_v11_0_cp_ecc_error_irq_funcs in gfx11<br /> <br /> v3:<br /> - Improve the subject and code comments<br /> - Add judgment on gfx11 in the function of amdgpu_gfx_ras_late_init<br /> <br /> v4:<br /> - Drop the define of CP_ME1_PIPE_INST_ADDR_INTERVAL and<br /> SET_ECC_ME_PIPE_STATE which using in gfx_v11_0_set_cp_ecc_error_state<br /> - Check cp_ecc_error_irq.funcs rather than ip version for a more<br /> sustainable life<br /> <br /> v5:<br /> - Simplify judgment conditions

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

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: sch_fq: fix integer overflow of "credit"<br /> <br /> if sch_fq is configured with "initial quantum" having values greater than<br /> INT_MAX, the first assignment of "credit" does signed integer overflow to<br /> a very negative value.<br /> In this situation, the syzkaller script provided by Cristoph triggers the<br /> CPU soft-lockup warning even with few sockets. It&amp;#39;s not an infinite loop,<br /> but "credit" wasn&amp;#39;t probably meant to be minus 2Gb for each new flow.<br /> Capping "initial quantum" to INT_MAX proved to fix the issue.<br /> <br /> v2: validation of "initial quantum" is done in fq_policy, instead of open<br /> coding in fq_change() _ suggested by Jakub Kicinski

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/gvt: fix vgpu debugfs clean in remove<br /> <br /> Check carefully on root debugfs available when destroying vgpu,<br /> e.g in remove case drm minor&amp;#39;s debugfs root might already be destroyed,<br /> which led to kernel oops like below.<br /> <br /> Console: switching to colour dummy device 80x25<br /> i915 0000:00:02.0: MDEV: Unregistering<br /> intel_vgpu_mdev b1338b2d-a709-4c23-b766-cc436c36cdf0: Removing from iommu group 14<br /> BUG: kernel NULL pointer dereference, address: 0000000000000150<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP<br /> CPU: 3 PID: 1046 Comm: driverctl Not tainted 6.1.0-rc2+ #6<br /> Hardware name: HP HP ProDesk 600 G3 MT/829D, BIOS P02 Ver. 02.44 09/13/2022<br /> RIP: 0010:__lock_acquire+0x5e2/0x1f90<br /> Code: 87 ad 09 00 00 39 05 e1 1e cc 02 0f 82 f1 09 00 00 ba 01 00 00 00 48 83 c4 48 89 d0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 45 31 ff 81 3f 60 9e c2 b6 45 0f 45 f8 83 fe 01 0f 87 55 fa ff ff 89 f0<br /> RSP: 0018:ffff9f770274f948 EFLAGS: 00010046<br /> RAX: 0000000000000003 RBX: 0000000000000000 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000150<br /> RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000<br /> R10: ffff8895d1173300 R11: 0000000000000001 R12: 0000000000000000<br /> R13: 0000000000000150 R14: 0000000000000000 R15: 0000000000000000<br /> FS: 00007fc9b2ba0740(0000) GS:ffff889cdfcc0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000150 CR3: 000000010fd93005 CR4: 00000000003706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> lock_acquire+0xbf/0x2b0<br /> ? simple_recursive_removal+0xa5/0x2b0<br /> ? lock_release+0x13d/0x2d0<br /> down_write+0x2a/0xd0<br /> ? simple_recursive_removal+0xa5/0x2b0<br /> simple_recursive_removal+0xa5/0x2b0<br /> ? start_creating.part.0+0x110/0x110<br /> ? _raw_spin_unlock+0x29/0x40<br /> debugfs_remove+0x40/0x60<br /> intel_gvt_debugfs_remove_vgpu+0x15/0x30 [kvmgt]<br /> intel_gvt_destroy_vgpu+0x60/0x100 [kvmgt]<br /> intel_vgpu_release_dev+0xe/0x20 [kvmgt]<br /> device_release+0x30/0x80<br /> kobject_put+0x79/0x1b0<br /> device_release_driver_internal+0x1b8/0x230<br /> bus_remove_device+0xec/0x160<br /> device_del+0x189/0x400<br /> ? up_write+0x9c/0x1b0<br /> ? mdev_device_remove_common+0x60/0x60 [mdev]<br /> mdev_device_remove_common+0x22/0x60 [mdev]<br /> mdev_device_remove_cb+0x17/0x20 [mdev]<br /> device_for_each_child+0x56/0x80<br /> mdev_unregister_parent+0x5a/0x81 [mdev]<br /> intel_gvt_clean_device+0x2d/0xe0 [kvmgt]<br /> intel_gvt_driver_remove+0x2e/0xb0 [i915]<br /> i915_driver_remove+0xac/0x100 [i915]<br /> i915_pci_remove+0x1a/0x30 [i915]<br /> pci_device_remove+0x31/0xa0<br /> device_release_driver_internal+0x1b8/0x230<br /> unbind_store+0xd8/0x100<br /> kernfs_fop_write_iter+0x156/0x210<br /> vfs_write+0x236/0x4a0<br /> ksys_write+0x61/0xd0<br /> do_syscall_64+0x55/0x80<br /> ? find_held_lock+0x2b/0x80<br /> ? lock_release+0x13d/0x2d0<br /> ? up_read+0x17/0x20<br /> ? lock_is_held_type+0xe3/0x140<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? lockdep_hardirqs_on+0x7d/0x100<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> RIP: 0033:0x7fc9b2c9e0c4<br /> Code: 15 71 7d 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 80 3d 3d 05 0e 00 00 74 13 b8 01 00 00 00 0f 05 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 48 89 54 24 18 48<br /> RSP: 002b:00007ffec29c81c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc9b2c9e0c4<br /> RDX: 000000000000000d RSI: 0000559f8b5f48a0 RDI: 0000000000000001<br /> RBP: 0000559f8b5f48a0 R08: 0000559f8b5f3540 R09: 00007fc9b2d76d30<br /> R10: 0000000000000000 R11: 0000000000000202 R12: 000000000000000d<br /> R13: 00007fc9b2d77780 R14: 000000000000000d R15: 00007fc9b2d72a00<br /> <br /> Modules linked in: sunrpc intel_rapl_msr intel_rapl_common intel_pmc_core_pltdrv intel_pmc_core intel_tcc_cooling x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel ee1004 igbvf rapl vfat fat intel_cstate intel_uncore pktcdvd i2c_i801 pcspkr wmi_bmof i2c_smbus acpi_pad vfio_pci vfio_pci_core vfio_virqfd zram fuse dm<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix possible double unlock when moving a directory

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: hisi_sas: Grab sas_dev lock when traversing the members of sas_dev.list<br /> <br /> When freeing slots in function slot_complete_v3_hw(), it is possible that<br /> sas_dev.list is being traversed elsewhere, and it may trigger a NULL<br /> pointer exception, such as follows:<br /> <br /> ==&gt;cq thread ==&gt;scsi_eh_6<br /> <br /> ==&gt;scsi_error_handler()<br /> ==&gt;sas_eh_handle_sas_errors()<br /> ==&gt;sas_scsi_find_task()<br /> ==&gt;lldd_abort_task()<br /> ==&gt;slot_complete_v3_hw() ==&gt;hisi_sas_abort_task()<br /> ==&gt;hisi_sas_slot_task_free() ==&gt;dereg_device_v3_hw()<br /> ==&gt;list_del_init() ==&gt;list_for_each_entry_safe()<br /> <br /> [ 7165.434918] sas: Enter sas_scsi_recover_host busy: 32 failed: 32<br /> [ 7165.434926] sas: trying to find task 0x00000000769b5ba5<br /> [ 7165.434927] sas: sas_scsi_find_task: aborting task 0x00000000769b5ba5<br /> [ 7165.434940] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000769b5ba5) aborted<br /> [ 7165.434964] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000c9f7aa07) ignored<br /> [ 7165.434965] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000e2a1cf01) ignored<br /> [ 7165.434968] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> [ 7165.434972] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(0000000022d52d93) ignored<br /> [ 7165.434975] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(0000000066a7516c) ignored<br /> [ 7165.434976] Mem abort info:<br /> [ 7165.434982] ESR = 0x96000004<br /> [ 7165.434991] Exception class = DABT (current EL), IL = 32 bits<br /> [ 7165.434992] SET = 0, FnV = 0<br /> [ 7165.434993] EA = 0, S1PTW = 0<br /> [ 7165.434994] Data abort info:<br /> [ 7165.434994] ISV = 0, ISS = 0x00000004<br /> [ 7165.434995] CM = 0, WnR = 0<br /> [ 7165.434997] user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000f29543f2<br /> [ 7165.434998] [0000000000000000] pgd=0000000000000000<br /> [ 7165.435003] Internal error: Oops: 96000004 [#1] SMP<br /> [ 7165.439863] Process scsi_eh_6 (pid: 4109, stack limit = 0x00000000c43818d5)<br /> [ 7165.468862] pstate: 00c00009 (nzcv daif +PAN +UAO)<br /> [ 7165.473637] pc : dereg_device_v3_hw+0x68/0xa8 [hisi_sas_v3_hw]<br /> [ 7165.479443] lr : dereg_device_v3_hw+0x2c/0xa8 [hisi_sas_v3_hw]<br /> [ 7165.485247] sp : ffff00001d623bc0<br /> [ 7165.488546] x29: ffff00001d623bc0 x28: ffffa027d03b9508<br /> [ 7165.493835] x27: ffff80278ed50af0 x26: ffffa027dd31e0a8<br /> [ 7165.499123] x25: ffffa027d9b27f88 x24: ffffa027d9b209f8<br /> [ 7165.504411] x23: ffffa027c45b0d60 x22: ffff80278ec07c00<br /> [ 7165.509700] x21: 0000000000000008 x20: ffffa027d9b209f8<br /> [ 7165.514988] x19: ffffa027d9b27f88 x18: ffffffffffffffff<br /> [ 7165.520276] x17: 0000000000000000 x16: 0000000000000000<br /> [ 7165.525564] x15: ffff0000091d9708 x14: ffff0000093b7dc8<br /> [ 7165.530852] x13: ffff0000093b7a23 x12: 6e7265746e692067<br /> [ 7165.536140] x11: 0000000000000000 x10: 0000000000000bb0<br /> [ 7165.541429] x9 : ffff00001d6238f0 x8 : ffffa027d877af00<br /> [ 7165.546718] x7 : ffffa027d6329600 x6 : ffff7e809f58ca00<br /> [ 7165.552006] x5 : 0000000000001f8a x4 : 000000000000088e<br /> [ 7165.557295] x3 : ffffa027d9b27fa8 x2 : 0000000000000000<br /> [ 7165.562583] x1 : 0000000000000000 x0 : 000000003000188e<br /> [ 7165.567872] Call trace:<br /> [ 7165.570309] dereg_device_v3_hw+0x68/0xa8 [hisi_sas_v3_hw]<br /> [ 7165.575775] hisi_sas_abort_task+0x248/0x358 [hisi_sas_main]<br /> [ 7165.581415] sas_eh_handle_sas_errors+0x258/0x8e0 [libsas]<br /> [ 7165.586876] sas_scsi_recover_host+0x134/0x458 [libsas]<br /> [ 7165.592082] scsi_error_handler+0xb4/0x488<br /> [ 7165.596163] kthread+0x134/0x138<br /> [ 7165.599380] ret_from_fork+0x10/0x18<br /> [ 7165.602940] Code: d5033e9f b9000040 aa0103e2 eb03003f (f9400021)<br /> [ 7165.609004] kernel fault(0x1) notification starting on CPU 75<br /> [ 7165.700728] ---[ end trace fc042cbbea224efc ]---<br /> [ 7165.705326] Kernel panic - not syncing: Fatal exception<br /> <br /> To fix the issue, grab sas_dev lock when traversing the members of<br /> sas_dev.list in dereg_device_v3_hw() and hisi_sas_release_tasks() to avoid<br /> concurrency of adding and deleting member. When <br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: dlm: fix use after free in midcomms commit<br /> <br /> While working on processing dlm message in softirq context I experienced<br /> the following KASAN use-after-free warning:<br /> <br /> [ 151.760477] ==================================================================<br /> [ 151.761803] BUG: KASAN: use-after-free in dlm_midcomms_commit_mhandle+0x19d/0x4b0<br /> [ 151.763414] Read of size 4 at addr ffff88811a980c60 by task lock_torture/1347<br /> <br /> [ 151.765284] CPU: 7 PID: 1347 Comm: lock_torture Not tainted 6.1.0-rc4+ #2828<br /> [ 151.766778] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-3.module+el8.7.0+16134+e5908aa2 04/01/2014<br /> [ 151.768726] Call Trace:<br /> [ 151.769277] <br /> [ 151.769748] dump_stack_lvl+0x5b/0x86<br /> [ 151.770556] print_report+0x180/0x4c8<br /> [ 151.771378] ? kasan_complete_mode_report_info+0x7c/0x1e0<br /> [ 151.772241] ? dlm_midcomms_commit_mhandle+0x19d/0x4b0<br /> [ 151.773069] kasan_report+0x93/0x1a0<br /> [ 151.773668] ? dlm_midcomms_commit_mhandle+0x19d/0x4b0<br /> [ 151.774514] __asan_load4+0x7e/0xa0<br /> [ 151.775089] dlm_midcomms_commit_mhandle+0x19d/0x4b0<br /> [ 151.775890] ? create_message.isra.29.constprop.64+0x57/0xc0<br /> [ 151.776770] send_common+0x19f/0x1b0<br /> [ 151.777342] ? remove_from_waiters+0x60/0x60<br /> [ 151.778017] ? lock_downgrade+0x410/0x410<br /> [ 151.778648] ? __this_cpu_preempt_check+0x13/0x20<br /> [ 151.779421] ? rcu_lockdep_current_cpu_online+0x88/0xc0<br /> [ 151.780292] _convert_lock+0x46/0x150<br /> [ 151.780893] convert_lock+0x7b/0xc0<br /> [ 151.781459] dlm_lock+0x3ac/0x580<br /> [ 151.781993] ? 0xffffffffc0540000<br /> [ 151.782522] ? torture_stop+0x120/0x120 [dlm_locktorture]<br /> [ 151.783379] ? dlm_scan_rsbs+0xa70/0xa70<br /> [ 151.784003] ? preempt_count_sub+0xd6/0x130<br /> [ 151.784661] ? is_module_address+0x47/0x70<br /> [ 151.785309] ? torture_stop+0x120/0x120 [dlm_locktorture]<br /> [ 151.786166] ? 0xffffffffc0540000<br /> [ 151.786693] ? lockdep_init_map_type+0xc3/0x360<br /> [ 151.787414] ? 0xffffffffc0540000<br /> [ 151.787947] torture_dlm_lock_sync.isra.3+0xe9/0x150 [dlm_locktorture]<br /> [ 151.789004] ? torture_stop+0x120/0x120 [dlm_locktorture]<br /> [ 151.789858] ? 0xffffffffc0540000<br /> [ 151.790392] ? lock_torture_cleanup+0x20/0x20 [dlm_locktorture]<br /> [ 151.791347] ? delay_tsc+0x94/0xc0<br /> [ 151.791898] torture_ex_iter+0xc3/0xea [dlm_locktorture]<br /> [ 151.792735] ? torture_start+0x30/0x30 [dlm_locktorture]<br /> [ 151.793606] lock_torture+0x177/0x270 [dlm_locktorture]<br /> [ 151.794448] ? torture_dlm_lock_sync.isra.3+0x150/0x150 [dlm_locktorture]<br /> [ 151.795539] ? lock_torture_stats+0x80/0x80 [dlm_locktorture]<br /> [ 151.796476] ? do_raw_spin_lock+0x11e/0x1e0<br /> [ 151.797152] ? mark_held_locks+0x34/0xb0<br /> [ 151.797784] ? _raw_spin_unlock_irqrestore+0x30/0x70<br /> [ 151.798581] ? __kthread_parkme+0x79/0x110<br /> [ 151.799246] ? trace_preempt_on+0x2a/0xf0<br /> [ 151.799902] ? __kthread_parkme+0x79/0x110<br /> [ 151.800579] ? preempt_count_sub+0xd6/0x130<br /> [ 151.801271] ? __kasan_check_read+0x11/0x20<br /> [ 151.801963] ? __kthread_parkme+0xec/0x110<br /> [ 151.802630] ? lock_torture_stats+0x80/0x80 [dlm_locktorture]<br /> [ 151.803569] kthread+0x192/0x1d0<br /> [ 151.804104] ? kthread_complete_and_exit+0x30/0x30<br /> [ 151.804881] ret_from_fork+0x1f/0x30<br /> [ 151.805480] <br /> <br /> [ 151.806111] Allocated by task 1347:<br /> [ 151.806681] kasan_save_stack+0x26/0x50<br /> [ 151.807308] kasan_set_track+0x25/0x30<br /> [ 151.807920] kasan_save_alloc_info+0x1e/0x30<br /> [ 151.808609] __kasan_slab_alloc+0x63/0x80<br /> [ 151.809263] kmem_cache_alloc+0x1ad/0x830<br /> [ 151.809916] dlm_allocate_mhandle+0x17/0x20<br /> [ 151.810590] dlm_midcomms_get_mhandle+0x96/0x260<br /> [ 151.811344] _create_message+0x95/0x180<br /> [ 151.811994] create_message.isra.29.constprop.64+0x57/0xc0<br /> [ 151.812880] send_common+0x129/0x1b0<br /> [ 151.813467] _convert_lock+0x46/0x150<br /> [ 151.814074] convert_lock+0x7b/0xc0<br /> [ 151.814648] dlm_lock+0x3ac/0x580<br /> [ 151.815199] torture_dlm_lock_sync.isra.3+0xe9/0x150 [dlm_locktorture]<br /> [ 151.816258] torture_ex_iter+0xc3/0xea [dlm_locktorture]<br /> [ 151.817129] lock_t<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: aspeed: socinfo: Add kfree for kstrdup<br /> <br /> Add kfree() in the later error handling in order to avoid memory leak.