Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mt76: mt7921: fix kernel panic by accessing unallocated eeprom.data<br /> <br /> The MT7921 driver no longer uses eeprom.data, but the relevant code has not<br /> been removed completely since<br /> commit 16d98b548365 ("mt76: mt7921: rely on mcu_get_nic_capability").<br /> This could result in potential invalid memory access.<br /> <br /> To fix the kernel panic issue in mt7921, it is necessary to avoid accessing<br /> unallocated eeprom.data which can lead to invalid memory access.<br /> <br /> Furthermore, it is possible to entirely eliminate the<br /> mt7921_mcu_parse_eeprom function and solely depend on<br /> mt7921_mcu_parse_response to divide the RxD header.<br /> <br /> [2.702735] BUG: kernel NULL pointer dereference, address: 0000000000000550<br /> [2.702740] #PF: supervisor write access in kernel mode<br /> [2.702741] #PF: error_code(0x0002) - not-present page<br /> [2.702743] PGD 0 P4D 0<br /> [2.702747] Oops: 0002 [#1] PREEMPT SMP NOPTI<br /> [2.702755] RIP: 0010:mt7921_mcu_parse_response+0x147/0x170 [mt7921_common]<br /> [2.702758] RSP: 0018:ffffae7c00fef828 EFLAGS: 00010286<br /> [2.702760] RAX: ffffa367f57be024 RBX: ffffa367cc7bf500 RCX: 0000000000000000<br /> [2.702762] RDX: 0000000000000550 RSI: 0000000000000000 RDI: ffffa367cc7bf500<br /> [2.702763] RBP: ffffae7c00fef840 R08: ffffa367cb167000 R09: 0000000000000005<br /> [2.702764] R10: 0000000000000000 R11: ffffffffc04702e4 R12: ffffa367e8329f40<br /> [2.702766] R13: 0000000000000000 R14: 0000000000000001 R15: ffffa367e8329f40<br /> [2.702768] FS: 000079ee6cf20c40(0000) GS:ffffa36b2f940000(0000) knlGS:0000000000000000<br /> [2.702769] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [2.702775] CR2: 0000000000000550 CR3: 00000001233c6004 CR4: 0000000000770ee0<br /> [2.702776] PKRU: 55555554<br /> [2.702777] Call Trace:<br /> [2.702782] mt76_mcu_skb_send_and_get_msg+0xc3/0x11e [mt76 ]<br /> [2.702785] mt7921_run_firmware+0x241/0x853 [mt7921_common ]<br /> [2.702789] mt7921e_mcu_init+0x2b/0x56 [mt7921e ]<br /> [2.702792] mt7921_register_device+0x2eb/0x5a5 [mt7921_common ]<br /> [2.702795] ? mt7921_irq_tasklet+0x1d4/0x1d4 [mt7921e ]<br /> [2.702797] mt7921_pci_probe+0x2d6/0x319 [mt7921e ]<br /> [2.702799] pci_device_probe+0x9f/0x12a

*** 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 /> drm/msm/dsi: Add missing check for alloc_ordered_workqueue<br /> <br /> Add check for the return value of alloc_ordered_workqueue as it may return<br /> NULL pointer and cause NULL pointer dereference.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/517646/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: Fix function prototype mismatch for ext4_feat_ktype<br /> <br /> With clang&amp;#39;s kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),<br /> indirect call targets are validated against the expected function<br /> pointer prototype to make sure the call target is valid to help mitigate<br /> ROP attacks. If they are not identical, there is a failure at run time,<br /> which manifests as either a kernel panic or thread getting killed.<br /> <br /> ext4_feat_ktype was setting the "release" handler to "kfree", which<br /> doesn&amp;#39;t have a matching function prototype. Add a simple wrapper<br /> with the correct prototype.<br /> <br /> This was found as a result of Clang&amp;#39;s new -Wcast-function-type-strict<br /> flag, which is more sensitive than the simpler -Wcast-function-type,<br /> which only checks for type width mismatches.<br /> <br /> Note that this code is only reached when ext4 is a loadable module and<br /> it is being unloaded:<br /> <br /> CFI failure at kobject_put+0xbb/0x1b0 (target: kfree+0x0/0x180; expected type: 0x7c4aa698)<br /> ...<br /> RIP: 0010:kobject_put+0xbb/0x1b0<br /> ...<br /> Call Trace:<br /> <br /> ext4_exit_sysfs+0x14/0x60 [ext4]<br /> cleanup_module+0x67/0xedb [ext4]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: imx: Don&amp;#39;t skip cleanup in remove&amp;#39;s error path<br /> <br /> Returning early in a platform driver&amp;#39;s remove callback is wrong. In this<br /> case the dma resources are not released in the error path. this is never<br /> retried later and so this is a permanent leak. To fix this, only skip<br /> hardware disabling if waking the device fails.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mwifiex: Fix OOB and integer underflow when rx packets<br /> <br /> Make sure mwifiex_process_mgmt_packet,<br /> mwifiex_process_sta_rx_packet and mwifiex_process_uap_rx_packet,<br /> mwifiex_uap_queue_bridged_pkt and mwifiex_process_rx_packet<br /> not out-of-bounds access the skb-&gt;data buffer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: drop redundant sched job cleanup when cs is aborted<br /> <br /> Once command submission failed due to userptr invalidation in<br /> amdgpu_cs_submit, legacy code will perform cleanup of scheduler<br /> job. However, it&amp;#39;s not needed at all, as former commit has integrated<br /> job cleanup stuff into amdgpu_job_free. Otherwise, because of double<br /> free, a NULL pointer dereference will occur in such scenario.<br /> <br /> Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2457

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: fix invalid drv_sta_pre_rcu_remove calls for non-uploaded sta<br /> <br /> Avoid potential data corruption issues caused by uninitialized driver<br /> private data structures.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix warning in cifs_smb3_do_mount()<br /> <br /> This fixes the following warning reported by kernel test robot<br /> <br /> fs/smb/client/cifsfs.c:982 cifs_smb3_do_mount() warn: possible<br /> memory leak of &amp;#39;cifs_sb&amp;#39;

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid potential memory corruption in __update_iostat_latency()<br /> <br /> Add iotype sanity check to avoid potential memory corruption.<br /> This is to fix the compile error below:<br /> <br /> fs/f2fs/iostat.c:231 __update_iostat_latency() error: buffer overflow<br /> &amp;#39;io_lat-&gt;peak_lat[type]&amp;#39; 3 type;<br /> 216 struct f2fs_sb_info *sbi = iostat_ctx-&gt;sbi;<br /> 217 struct iostat_lat_info *io_lat = sbi-&gt;iostat_io_lat;<br /> 218 unsigned long flags;<br /> 219<br /> 220 if (!sbi-&gt;iostat_enable)<br /> 221 return;<br /> 222<br /> 223 ts_diff = jiffies - iostat_ctx-&gt;submit_ts;<br /> 224 if (page_type &gt;= META_FLUSH)<br /> ^^^^^^^^^^<br /> <br /> 225 page_type = META;<br /> 226<br /> 227 spin_lock_irqsave(&amp;sbi-&gt;iostat_lat_lock, flags);<br /> @228 io_lat-&gt;sum_lat[type][page_type] += ts_diff;<br /> ^^^^^^^^^<br /> Mixup between META_FLUSH and NR_PAGE_TYPE leads to memory corruption.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/fair: Don&amp;#39;t balance task to its current running CPU<br /> <br /> We&amp;#39;ve run into the case that the balancer tries to balance a migration<br /> disabled task and trigger the warning in set_task_cpu() like below:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 7 PID: 0 at kernel/sched/core.c:3115 set_task_cpu+0x188/0x240<br /> Modules linked in: hclgevf xt_CHECKSUM ipt_REJECT nf_reject_ipv4 <br /> CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G O 6.1.0-rc4+ #1<br /> Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V5.B221.01 12/09/2021<br /> pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : set_task_cpu+0x188/0x240<br /> lr : load_balance+0x5d0/0xc60<br /> sp : ffff80000803bc70<br /> x29: ffff80000803bc70 x28: ffff004089e190e8 x27: ffff004089e19040<br /> x26: ffff007effcabc38 x25: 0000000000000000 x24: 0000000000000001<br /> x23: ffff80000803be84 x22: 000000000000000c x21: ffffb093e79e2a78<br /> x20: 000000000000000c x19: ffff004089e19040 x18: 0000000000000000<br /> x17: 0000000000001fad x16: 0000000000000030 x15: 0000000000000000<br /> x14: 0000000000000003 x13: 0000000000000000 x12: 0000000000000000<br /> x11: 0000000000000001 x10: 0000000000000400 x9 : ffffb093e4cee530<br /> x8 : 00000000fffffffe x7 : 0000000000ce168a x6 : 000000000000013e<br /> x5 : 00000000ffffffe1 x4 : 0000000000000001 x3 : 0000000000000b2a<br /> x2 : 0000000000000b2a x1 : ffffb093e6d6c510 x0 : 0000000000000001<br /> Call trace:<br /> set_task_cpu+0x188/0x240<br /> load_balance+0x5d0/0xc60<br /> rebalance_domains+0x26c/0x380<br /> _nohz_idle_balance.isra.0+0x1e0/0x370<br /> run_rebalance_domains+0x6c/0x80<br /> __do_softirq+0x128/0x3d8<br /> ____do_softirq+0x18/0x24<br /> call_on_irq_stack+0x2c/0x38<br /> do_softirq_own_stack+0x24/0x3c<br /> __irq_exit_rcu+0xcc/0xf4<br /> irq_exit_rcu+0x18/0x24<br /> el1_interrupt+0x4c/0xe4<br /> el1h_64_irq_handler+0x18/0x2c<br /> el1h_64_irq+0x74/0x78<br /> arch_cpu_idle+0x18/0x4c<br /> default_idle_call+0x58/0x194<br /> do_idle+0x244/0x2b0<br /> cpu_startup_entry+0x30/0x3c<br /> secondary_start_kernel+0x14c/0x190<br /> __secondary_switched+0xb0/0xb4<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Further investigation shows that the warning is superfluous, the migration<br /> disabled task is just going to be migrated to its current running CPU.<br /> This is because that on load balance if the dst_cpu is not allowed by the<br /> task, we&amp;#39;ll re-select a new_dst_cpu as a candidate. If no task can be<br /> balanced to dst_cpu we&amp;#39;ll try to balance the task to the new_dst_cpu<br /> instead. In this case when the migration disabled task is not on CPU it<br /> only allows to run on its current CPU, load balance will select its<br /> current CPU as new_dst_cpu and later triggers the warning above.<br /> <br /> The new_dst_cpu is chosen from the env-&gt;dst_grpmask. Currently it<br /> contains CPUs in sched_group_span() and if we have overlapped groups it&amp;#39;s<br /> possible to run into this case. This patch makes env-&gt;dst_grpmask of<br /> group_balance_mask() which exclude any CPUs from the busiest group and<br /> solve the issue. For balancing in a domain with no overlapped groups<br /> the behaviour keeps same as before.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: efi: Make efi_rt_lock a raw_spinlock<br /> <br /> Running a rt-kernel base on 6.2.0-rc3-rt1 on an Ampere Altra outputs<br /> the following:<br /> BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 9, name: kworker/u320:0<br /> preempt_count: 2, expected: 0<br /> RCU nest depth: 0, expected: 0<br /> 3 locks held by kworker/u320:0/9:<br /> #0: ffff3fff8c27d128 ((wq_completion)efi_rts_wq){+.+.}-{0:0}, at: process_one_work (./include/linux/atomic/atomic-long.h:41)<br /> #1: ffff80000861bdd0 ((work_completion)(&amp;efi_rts_work.work)){+.+.}-{0:0}, at: process_one_work (./include/linux/atomic/atomic-long.h:41)<br /> #2: ffffdf7e1ed3e460 (efi_rt_lock){+.+.}-{3:3}, at: efi_call_rts (drivers/firmware/efi/runtime-wrappers.c:101)<br /> Preemption disabled at:<br /> efi_virtmap_load (./arch/arm64/include/asm/mmu_context.h:248)<br /> CPU: 0 PID: 9 Comm: kworker/u320:0 Tainted: G W 6.2.0-rc3-rt1<br /> Hardware name: WIWYNN Mt.Jade Server System B81.03001.0005/Mt.Jade Motherboard, BIOS 1.08.20220218 (SCP: 1.08.20220218) 2022/02/18<br /> Workqueue: efi_rts_wq efi_call_rts<br /> Call trace:<br /> dump_backtrace (arch/arm64/kernel/stacktrace.c:158)<br /> show_stack (arch/arm64/kernel/stacktrace.c:165)<br /> dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4))<br /> dump_stack (lib/dump_stack.c:114)<br /> __might_resched (kernel/sched/core.c:10134)<br /> rt_spin_lock (kernel/locking/rtmutex.c:1769 (discriminator 4))<br /> efi_call_rts (drivers/firmware/efi/runtime-wrappers.c:101)<br /> [...]<br /> <br /> This seems to come from commit ff7a167961d1 ("arm64: efi: Execute<br /> runtime services from a dedicated stack") which adds a spinlock. This<br /> spinlock is taken through:<br /> efi_call_rts()<br /> \-efi_call_virt()<br /> \-efi_call_virt_pointer()<br /> \-arch_efi_call_virt_setup()<br /> <br /> Make &amp;#39;efi_rt_lock&amp;#39; a raw_spinlock to avoid being preempted.<br /> <br /> [ardb: The EFI runtime services are called with a different set of<br /> translation tables, and are permitted to use the SIMD registers.<br /> The context switch code preserves/restores neither, and so EFI<br /> calls must be made with preemption disabled, rather than only<br /> disabling migration.]