Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: cpumap: Fix memory leak in cpu_map_update_elem<br /> <br /> Syzkaller reported a memory leak as follows:<br /> <br /> BUG: memory leak<br /> unreferenced object 0xff110001198ef748 (size 192):<br /> comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 4a 19 00 00 80 ad e3 e4 fe ff c0 00 ....J...........<br /> 00 b2 d3 0c 01 00 11 ff 28 f5 8e 19 01 00 11 ff ........(.......<br /> backtrace:<br /> [] __cpu_map_entry_alloc+0xf7/0xb00<br /> [] cpu_map_update_elem+0x2fe/0x3d0<br /> [] bpf_map_update_value.isra.0+0x2bd/0x520<br /> [] map_update_elem+0x4cb/0x720<br /> [] __se_sys_bpf+0x8c3/0xb90<br /> [] do_syscall_64+0x30/0x40<br /> [] entry_SYSCALL_64_after_hwframe+0x61/0xc6<br /> <br /> BUG: memory leak<br /> unreferenced object 0xff110001198ef528 (size 192):<br /> comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s)<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 /> [] __cpu_map_entry_alloc+0x260/0xb00<br /> [] cpu_map_update_elem+0x2fe/0x3d0<br /> [] bpf_map_update_value.isra.0+0x2bd/0x520<br /> [] map_update_elem+0x4cb/0x720<br /> [] __se_sys_bpf+0x8c3/0xb90<br /> [] do_syscall_64+0x30/0x40<br /> [] entry_SYSCALL_64_after_hwframe+0x61/0xc6<br /> <br /> BUG: memory leak<br /> unreferenced object 0xff1100010fd93d68 (size 8):<br /> comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s)<br /> hex dump (first 8 bytes):<br /> 00 00 00 00 00 00 00 00 ........<br /> backtrace:<br /> [] kvmalloc_node+0x11e/0x170<br /> [] __cpu_map_entry_alloc+0x2f0/0xb00<br /> [] cpu_map_update_elem+0x2fe/0x3d0<br /> [] bpf_map_update_value.isra.0+0x2bd/0x520<br /> [] map_update_elem+0x4cb/0x720<br /> [] __se_sys_bpf+0x8c3/0xb90<br /> [] do_syscall_64+0x30/0x40<br /> [] entry_SYSCALL_64_after_hwframe+0x61/0xc6<br /> <br /> In the cpu_map_update_elem flow, when kthread_stop is called before<br /> calling the threadfn of rcpu-&gt;kthread, since the KTHREAD_SHOULD_STOP bit<br /> of kthread has been set by kthread_stop, the threadfn of rcpu-&gt;kthread<br /> will never be executed, and rcpu-&gt;refcnt will never be 0, which will<br /> lead to the allocated rcpu, rcpu-&gt;queue and rcpu-&gt;queue-&gt;queue cannot be<br /> released.<br /> <br /> Calling kthread_stop before executing kthread&amp;#39;s threadfn will return<br /> -EINTR. We can complete the release of memory resources in this state.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Block switchdev mode when ADQ is active and vice versa<br /> <br /> ADQ and switchdev are not supported simultaneously. Enabling both at the<br /> same time can result in nullptr dereference.<br /> <br /> To prevent this, check if ADQ is active when changing devlink mode to<br /> switchdev mode, and check if switchdev is active when enabling ADQ.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mfd: arizona: Use pm_runtime_resume_and_get() to prevent refcnt leak<br /> <br /> In arizona_clk32k_enable(), we should use pm_runtime_resume_and_get()<br /> as pm_runtime_get_sync() will increase the refcnt even when it<br /> returns an error.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/ttm: fix bulk_move corruption when adding a entry<br /> <br /> When the resource is the first in the bulk_move range, adding it again<br /> (thus moving it to the tail) will corrupt the list since the first<br /> pointer is not moved. This eventually lead to null pointer deref in<br /> ttm_lru_bulk_move_del()

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qrtr: Fix a refcount bug in qrtr_recvmsg()<br /> <br /> Syzbot reported a bug as following:<br /> <br /> refcount_t: addition on 0; use-after-free.<br /> ...<br /> RIP: 0010:refcount_warn_saturate+0x17c/0x1f0 lib/refcount.c:25<br /> ...<br /> Call Trace:<br /> <br /> __refcount_add include/linux/refcount.h:199 [inline]<br /> __refcount_inc include/linux/refcount.h:250 [inline]<br /> refcount_inc include/linux/refcount.h:267 [inline]<br /> kref_get include/linux/kref.h:45 [inline]<br /> qrtr_node_acquire net/qrtr/af_qrtr.c:202 [inline]<br /> qrtr_node_lookup net/qrtr/af_qrtr.c:398 [inline]<br /> qrtr_send_resume_tx net/qrtr/af_qrtr.c:1003 [inline]<br /> qrtr_recvmsg+0x85f/0x990 net/qrtr/af_qrtr.c:1070<br /> sock_recvmsg_nosec net/socket.c:1017 [inline]<br /> sock_recvmsg+0xe2/0x160 net/socket.c:1038<br /> qrtr_ns_worker+0x170/0x1700 net/qrtr/ns.c:688<br /> process_one_work+0x991/0x15c0 kernel/workqueue.c:2390<br /> worker_thread+0x669/0x1090 kernel/workqueue.c:2537<br /> <br /> It occurs in the concurrent scenario of qrtr_recvmsg() and<br /> qrtr_endpoint_unregister() as following:<br /> <br /> cpu0 cpu1<br /> qrtr_recvmsg qrtr_endpoint_unregister<br /> qrtr_send_resume_tx qrtr_node_release<br /> qrtr_node_lookup mutex_lock(&amp;qrtr_node_lock)<br /> spin_lock_irqsave(&amp;qrtr_nodes_lock, ) refcount_dec_and_test(&amp;node-&gt;ref) [node-&gt;ref == 0]<br /> radix_tree_lookup [node != NULL] __qrtr_node_release<br /> qrtr_node_acquire spin_lock_irqsave(&amp;qrtr_nodes_lock, )<br /> kref_get(&amp;node-&gt;ref) [WARNING] ...<br /> mutex_unlock(&amp;qrtr_node_lock)<br /> <br /> Use qrtr_node_lock to protect qrtr_node_lookup() implementation, this<br /> is actually improving the protection of node reference.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI/ASPM: Disable ASPM on MFD function removal to avoid use-after-free<br /> <br /> Struct pcie_link_state-&gt;downstream is a pointer to the pci_dev of function<br /> 0. Previously we retained that pointer when removing function 0, and<br /> subsequent ASPM policy changes dereferenced it, resulting in a<br /> use-after-free warning from KASAN, e.g.:<br /> <br /> # echo 1 &gt; /sys/bus/pci/devices/0000:03:00.0/remove<br /> # echo powersave &gt; /sys/module/pcie_aspm/parameters/policy<br /> <br /> BUG: KASAN: slab-use-after-free in pcie_config_aspm_link+0x42d/0x500<br /> Call Trace:<br /> kasan_report+0xae/0xe0<br /> pcie_config_aspm_link+0x42d/0x500<br /> pcie_aspm_set_policy+0x8e/0x1a0<br /> param_attr_store+0x162/0x2c0<br /> module_attr_store+0x3e/0x80<br /> <br /> PCIe spec r6.0, sec 7.5.3.7, recommends that software program the same ASPM<br /> Control value in all functions of multi-function devices.<br /> <br /> Disable ASPM and free the pcie_link_state when any child function is<br /> removed so we can discard the dangling pcie_link_state-&gt;downstream pointer<br /> and maintain the same ASPM Control configuration for all functions.<br /> <br /> [bhelgaas: commit log and comment]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ses: Don&amp;#39;t attach if enclosure has no components<br /> <br /> An enclosure with no components can&amp;#39;t usefully be operated by the driver<br /> (since effectively it has nothing to manage), so report the problem and<br /> don&amp;#39;t attach. Not attaching also fixes an oops which could occur if the<br /> driver tries to manage a zero component enclosure.<br /> <br /> [mkp: Switched to KERN_WARNING since this scenario is common]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firewire: net: fix use after free in fwnet_finish_incoming_packet()<br /> <br /> The netif_rx() function frees the skb so we can&amp;#39;t dereference it to<br /> save the skb-&gt;len.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: add vlan_get_protocol_and_depth() helper<br /> <br /> Before blamed commit, pskb_may_pull() was used instead<br /> of skb_header_pointer() in __vlan_get_protocol() and friends.<br /> <br /> Few callers depended on skb-&gt;head being populated with MAC header,<br /> syzbot caught one of them (skb_mac_gso_segment())<br /> <br /> Add vlan_get_protocol_and_depth() to make the intent clearer<br /> and use it where sensible.<br /> <br /> This is a more generic fix than commit e9d3f80935b6<br /> ("net/af_packet: make sure to pull mac header") which was<br /> dealing with a similar issue.<br /> <br /> kernel BUG at include/linux/skbuff.h:2655 !<br /> invalid opcode: 0000 [#1] SMP KASAN<br /> CPU: 0 PID: 1441 Comm: syz-executor199 Not tainted 6.1.24-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023<br /> RIP: 0010:__skb_pull include/linux/skbuff.h:2655 [inline]<br /> RIP: 0010:skb_mac_gso_segment+0x68f/0x6a0 net/core/gro.c:136<br /> Code: fd 48 8b 5c 24 10 44 89 6b 70 48 c7 c7 c0 ae 0d 86 44 89 e6 e8 a1 91 d0 00 48 c7 c7 00 af 0d 86 48 89 de 31 d2 e8 d1 4a e9 ff 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41<br /> RSP: 0018:ffffc90001bd7520 EFLAGS: 00010286<br /> RAX: ffffffff8469736a RBX: ffff88810f31dac0 RCX: ffff888115a18b00<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: ffffc90001bd75e8 R08: ffffffff84697183 R09: fffff5200037adf9<br /> R10: 0000000000000000 R11: dffffc0000000001 R12: 0000000000000012<br /> R13: 000000000000fee5 R14: 0000000000005865 R15: 000000000000fed7<br /> FS: 000055555633f300(0000) GS:ffff8881f6a00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000020000000 CR3: 0000000116fea000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> [] __skb_gso_segment+0x32d/0x4c0 net/core/dev.c:3419<br /> [] skb_gso_segment include/linux/netdevice.h:4819 [inline]<br /> [] validate_xmit_skb+0x3aa/0xee0 net/core/dev.c:3725<br /> [] __dev_queue_xmit+0x1332/0x3300 net/core/dev.c:4313<br /> [] dev_queue_xmit+0x17/0x20 include/linux/netdevice.h:3029<br /> [] packet_snd net/packet/af_packet.c:3111 [inline]<br /> [] packet_sendmsg+0x49d2/0x6470 net/packet/af_packet.c:3142<br /> [] sock_sendmsg_nosec net/socket.c:716 [inline]<br /> [] sock_sendmsg net/socket.c:736 [inline]<br /> [] __sys_sendto+0x472/0x5f0 net/socket.c:2139<br /> [] __do_sys_sendto net/socket.c:2151 [inline]<br /> [] __se_sys_sendto net/socket.c:2147 [inline]<br /> [] __x64_sys_sendto+0xe5/0x100 net/socket.c:2147<br /> [] do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> [] do_syscall_64+0x2f/0x50 arch/x86/entry/common.c:80<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> remoteproc: imx_dsp_rproc: Add custom memory copy implementation for i.MX DSP Cores<br /> <br /> The IRAM is part of the HiFi DSP.<br /> According to hardware specification only 32-bits write are allowed<br /> otherwise we get a Kernel panic.<br /> <br /> Therefore add a custom memory copy and memset functions to deal with<br /> the above restriction.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cassini: Fix a memory leak in the error handling path of cas_init_one()<br /> <br /> cas_saturn_firmware_init() allocates some memory using vmalloc(). This<br /> memory is freed in the .remove() function but not it the error handling<br /> path of the probe.<br /> <br /> Add the missing vfree() to avoid a memory leak, should an error occur.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: snic: Fix possible memory leak if device_add() fails<br /> <br /> If device_add() returns error, the name allocated by dev_set_name() needs<br /> be freed. As the comment of device_add() says, put_device() should be used<br /> to give up the reference in the error path. So fix this by calling<br /> put_device(), then the name can be freed in kobject_cleanp().