Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: core: Fix kernel panic when remove non-standard SDIO card<br /> <br /> SDIO tuple is only allocated for standard SDIO card, especially it causes<br /> memory corruption issues when the non-standard SDIO card has removed, which<br /> is because the card device&amp;#39;s reference counter does not increase for it at<br /> sdio_init_func(), but all SDIO card device reference counter gets decreased<br /> at sdio_release_func().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HSI: omap_ssi: Fix refcount leak in ssi_probe<br /> <br /> When returning or breaking early from a<br /> for_each_available_child_of_node() loop, we need to explicitly call<br /> of_node_put() on the child node to possibly release the node.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/chrome: cros_ec_typec: zero out stale pointers<br /> <br /> `cros_typec_get_switch_handles` allocates four pointers when obtaining<br /> type-c switch handles. These pointers are all freed if failing to obtain<br /> any of them; therefore, pointers in `port` become stale. The stale<br /> pointers eventually cause use-after-free or double free in later code<br /> paths. Zeroing out all pointer fields after freeing to eliminate these<br /> stale pointers.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix xid leak in cifs_copy_file_range()<br /> <br /> If the file is used by swap, before return -EOPNOTSUPP, should<br /> free the xid, otherwise, the xid will be leaked.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: ti: dra7-atl: Fix reference leak in of_dra7_atl_clk_probe<br /> <br /> pm_runtime_get_sync() will increment pm usage counter.<br /> Forgetting to putting operation will result in reference leak.<br /> Add missing pm_runtime_put_sync in some error paths.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: perf: marvell_cn10k: Fix hotplug callback leak in tad_pmu_init()<br /> <br /> tad_pmu_init() won&amp;#39;t remove the callback added by cpuhp_setup_state_multi()<br /> when platform_driver_register() failed. Remove the callback by<br /> cpuhp_remove_multi_state() in fail path.<br /> <br /> Similar to the handling of arm_ccn_init() in commit 26242b330093 ("bus:<br /> arm-ccn: Prevent hotplug callback leak")

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3: qcom: Fix memory leak in dwc3_qcom_interconnect_init<br /> <br /> of_icc_get() alloc resources for path handle, we should release it when not<br /> need anymore. Like the release in dwc3_qcom_interconnect_exit() function.<br /> Add icc_put() in error handling to fix this.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: cw2015: Fix potential null-ptr-deref in cw_bat_probe()<br /> <br /> cw_bat_probe() calls create_singlethread_workqueue() and not checked the<br /> ret value, which may return NULL. And a null-ptr-deref may happen:<br /> <br /> cw_bat_probe()<br /> create_singlethread_workqueue() # failed, cw_bat-&gt;wq is NULL<br /> queue_delayed_work()<br /> queue_delayed_work_on()<br /> __queue_delayed_work() # warning here, but continue<br /> __queue_work() # access wq-&gt;flags, null-ptr-deref<br /> <br /> Check the ret value and return -ENOMEM if it is NULL.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/kprobes: Fix null pointer reference in arch_prepare_kprobe()<br /> <br /> I found a null pointer reference in arch_prepare_kprobe():<br /> <br /> # echo &amp;#39;p cmdline_proc_show&amp;#39; &gt; kprobe_events<br /> # echo &amp;#39;p cmdline_proc_show+16&amp;#39; &gt;&gt; kprobe_events<br /> Kernel attempted to read user page (0) - exploit attempt? (uid: 0)<br /> BUG: Kernel NULL pointer dereference on read at 0x00000000<br /> Faulting instruction address: 0xc000000000050bfc<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV<br /> Modules linked in:<br /> CPU: 0 PID: 122 Comm: sh Not tainted 6.0.0-rc3-00007-gdcf8e5633e2e #10<br /> NIP: c000000000050bfc LR: c000000000050bec CTR: 0000000000005bdc<br /> REGS: c0000000348475b0 TRAP: 0300 Not tainted (6.0.0-rc3-00007-gdcf8e5633e2e)<br /> MSR: 9000000000009033 CR: 88002444 XER: 20040006<br /> CFAR: c00000000022d100 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 0<br /> ...<br /> NIP arch_prepare_kprobe+0x10c/0x2d0<br /> LR arch_prepare_kprobe+0xfc/0x2d0<br /> Call Trace:<br /> 0xc0000000012f77a0 (unreliable)<br /> register_kprobe+0x3c0/0x7a0<br /> __register_trace_kprobe+0x140/0x1a0<br /> __trace_kprobe_create+0x794/0x1040<br /> trace_probe_create+0xc4/0xe0<br /> create_or_delete_trace_kprobe+0x2c/0x80<br /> trace_parse_run_command+0xf0/0x210<br /> probes_write+0x20/0x40<br /> vfs_write+0xfc/0x450<br /> ksys_write+0x84/0x140<br /> system_call_exception+0x17c/0x3a0<br /> system_call_vectored_common+0xe8/0x278<br /> --- interrupt: 3000 at 0x7fffa5682de0<br /> NIP: 00007fffa5682de0 LR: 0000000000000000 CTR: 0000000000000000<br /> REGS: c000000034847e80 TRAP: 3000 Not tainted (6.0.0-rc3-00007-gdcf8e5633e2e)<br /> MSR: 900000000280f033 CR: 44002408 XER: 00000000<br /> <br /> The address being probed has some special:<br /> <br /> cmdline_proc_show: Probe based on ftrace<br /> cmdline_proc_show+16: Probe for the next instruction at the ftrace location<br /> <br /> The ftrace-based kprobe does not generate kprobe::ainsn::insn, it gets<br /> set to NULL. In arch_prepare_kprobe() it will check for:<br /> <br /> ...<br /> prev = get_kprobe(p-&gt;addr - 1);<br /> preempt_enable_no_resched();<br /> if (prev &amp;&amp; ppc_inst_prefixed(ppc_inst_read(prev-&gt;ainsn.insn))) {<br /> ...<br /> <br /> If prev is based on ftrace, &amp;#39;ppc_inst_read(prev-&gt;ainsn.insn)&amp;#39; will occur<br /> with a null pointer reference. At this point prev-&gt;addr will not be a<br /> prefixed instruction, so the check can be skipped.<br /> <br /> Check if prev is ftrace-based kprobe before reading &amp;#39;prev-&gt;ainsn.insn&amp;#39;<br /> to fix this problem.<br /> <br /> [mpe: Trim oops]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: Fix pci_device_is_present() for VFs by checking PF<br /> <br /> pci_device_is_present() previously didn&amp;#39;t work for VFs because it reads the<br /> Vendor and Device ID, which are 0xffff for VFs, which looks like they<br /> aren&amp;#39;t present. Check the PF instead.<br /> <br /> Wei Gong reported that if virtio I/O is in progress when the driver is<br /> unbound or "0" is written to /sys/.../sriov_numvfs, the virtio I/O<br /> operation hangs, which may result in output like this:<br /> <br /> task:bash state:D stack: 0 pid: 1773 ppid: 1241 flags:0x00004002<br /> Call Trace:<br /> schedule+0x4f/0xc0<br /> blk_mq_freeze_queue_wait+0x69/0xa0<br /> blk_mq_freeze_queue+0x1b/0x20<br /> blk_cleanup_queue+0x3d/0xd0<br /> virtblk_remove+0x3c/0xb0 [virtio_blk]<br /> virtio_dev_remove+0x4b/0x80<br /> ...<br /> device_unregister+0x1b/0x60<br /> unregister_virtio_device+0x18/0x30<br /> virtio_pci_remove+0x41/0x80<br /> pci_device_remove+0x3e/0xb0<br /> <br /> This happened because pci_device_is_present(VF) returned "false" in<br /> virtio_pci_remove(), so it called virtio_break_device(). The broken vq<br /> meant that vring_interrupt() skipped the vq.callback() that would have<br /> completed the virtio I/O operation via virtblk_done().<br /> <br /> [bhelgaas: commit log, simplify to always use pci_physfn(), add stable tag]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: qcom-hw: Fix memory leak in qcom_cpufreq_hw_read_lut()<br /> <br /> If "cpu_dev" fails to get opp table in qcom_cpufreq_hw_read_lut(),<br /> the program will return, resulting in "table" resource is not released.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RISC-V: kexec: Fix memory leak of fdt buffer<br /> <br /> This is reported by kmemleak detector:<br /> <br /> unreferenced object 0xff60000082864000 (size 9588):<br /> comm "kexec", pid 146, jiffies 4294900634 (age 64.788s)<br /> hex dump (first 32 bytes):<br /> d0 0d fe ed 00 00 12 ed 00 00 00 48 00 00 11 40 ...........H...@<br /> 00 00 00 28 00 00 00 11 00 00 00 02 00 00 00 00 ...(............<br /> backtrace:<br /> [] kmemleak_alloc+0x34/0x3e<br /> [] kmalloc_order+0x9c/0xc4<br /> [] kmalloc_order_trace+0x34/0xb6<br /> [] __kmalloc+0x5c2/0x62a<br /> [] kvmalloc_node+0x66/0xd6<br /> [] of_kexec_alloc_and_setup_fdt+0xa6/0x6ea<br /> [] elf_kexec_load+0x206/0x4ec<br /> [] kexec_image_load_default+0x40/0x4c<br /> [] sys_kexec_file_load+0x1c4/0x322<br /> [] ret_from_syscall+0x0/0x2<br /> <br /> In elf_kexec_load(), a buffer is allocated via kvmalloc() to store fdt.<br /> While it&amp;#39;s not freed back to system when kexec kernel is reloaded or<br /> unloaded. Then memory leak is caused. Fix it by introducing riscv<br /> specific function arch_kimage_file_post_load_cleanup(), and freeing the<br /> buffer there.