Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> apparmor: fix a memleak in multi_transaction_new()<br /> <br /> In multi_transaction_new(), the variable t is not freed or passed out<br /> on the failure of copy_from_user(t-&gt;data, buf, size), which could lead<br /> to a memleak.<br /> <br /> Fix this bug by adding a put_multi_transaction(t) in the error path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udf: Avoid double brelse() in udf_rename()<br /> <br /> syzbot reported a warning like below [1]:<br /> <br /> VFS: brelse: Trying to free free buffer<br /> WARNING: CPU: 2 PID: 7301 at fs/buffer.c:1145 __brelse+0x67/0xa0<br /> ...<br /> Call Trace:<br /> <br /> invalidate_bh_lru+0x99/0x150<br /> smp_call_function_many_cond+0xe2a/0x10c0<br /> ? generic_remap_file_range_prep+0x50/0x50<br /> ? __brelse+0xa0/0xa0<br /> ? __mutex_lock+0x21c/0x12d0<br /> ? smp_call_on_cpu+0x250/0x250<br /> ? rcu_read_lock_sched_held+0xb/0x60<br /> ? lock_release+0x587/0x810<br /> ? __brelse+0xa0/0xa0<br /> ? generic_remap_file_range_prep+0x50/0x50<br /> on_each_cpu_cond_mask+0x3c/0x80<br /> blkdev_flush_mapping+0x13a/0x2f0<br /> blkdev_put_whole+0xd3/0xf0<br /> blkdev_put+0x222/0x760<br /> deactivate_locked_super+0x96/0x160<br /> deactivate_super+0xda/0x100<br /> cleanup_mnt+0x222/0x3d0<br /> task_work_run+0x149/0x240<br /> ? task_work_cancel+0x30/0x30<br /> do_exit+0xb29/0x2a40<br /> ? reacquire_held_locks+0x4a0/0x4a0<br /> ? do_raw_spin_lock+0x12a/0x2b0<br /> ? mm_update_next_owner+0x7c0/0x7c0<br /> ? rwlock_bug.part.0+0x90/0x90<br /> ? zap_other_threads+0x234/0x2d0<br /> do_group_exit+0xd0/0x2a0<br /> __x64_sys_exit_group+0x3a/0x50<br /> do_syscall_64+0x34/0xb0<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> The cause of the issue is that brelse() is called on both ofibh.sbh<br /> and ofibh.ebh by udf_find_entry() when it returns NULL. However,<br /> brelse() is called by udf_rename(), too. So, b_count on buffer_head<br /> becomes unbalanced.<br /> <br /> This patch fixes the issue by not calling brelse() by udf_rename()<br /> when udf_find_entry() returns NULL.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-pci: fix mempool alloc size<br /> <br /> Convert the max size to bytes to match the units of the divisor that<br /> calculates the worst-case number of PRP entries.<br /> <br /> The result is used to determine how many PRP Lists are required. The<br /> code was previously rounding this to 1 list, but we can require 2 in the<br /> worst case. In that scenario, the driver would corrupt memory beyond the<br /> size provided by the mempool.<br /> <br /> While unlikely to occur (you&amp;#39;d need a 4MB in exactly 127 phys segments<br /> on a queue that doesn&amp;#39;t support SGLs), this memory corruption has been<br /> observed by kfence.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: camss: Clean up received buffers on failed start of streaming<br /> <br /> It is required to return the received buffers, if streaming can not be<br /> started. For instance media_pipeline_start() may fail with EPIPE, if<br /> a link validation between entities is not passed, and in such a case<br /> a user gets a kernel warning:<br /> <br /> WARNING: CPU: 1 PID: 520 at drivers/media/common/videobuf2/videobuf2-core.c:1592 vb2_start_streaming+0xec/0x160<br /> <br /> Call trace:<br /> vb2_start_streaming+0xec/0x160<br /> vb2_core_streamon+0x9c/0x1a0<br /> vb2_ioctl_streamon+0x68/0xbc<br /> v4l_streamon+0x30/0x3c<br /> __video_do_ioctl+0x184/0x3e0<br /> video_usercopy+0x37c/0x7b0<br /> video_ioctl2+0x24/0x40<br /> v4l2_ioctl+0x4c/0x70<br /> <br /> The fix is to correct the error path in video_start_streaming() of camss.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: vt6655: fix potential memory leak<br /> <br /> In function device_init_td0_ring, memory is allocated for member<br /> td_info of priv-&gt;apTD0Rings[i], with i increasing from 0. In case of<br /> allocation failure, the memory is freed in reversed order, with i<br /> decreasing to 0. However, the case i=0 is left out and thus memory is<br /> leaked.<br /> <br /> Modify the memory freeing loop to include the case i=0.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: i2c: ov5648: Free V4L2 fwnode data on unbind<br /> <br /> The V4L2 fwnode data structure doesn&amp;#39;t get freed on unbind, which leads to<br /> a memleak.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix PCI device refcount leak in amdgpu_atrm_get_bios()<br /> <br /> As comment of pci_get_class() says, it returns a pci_device with its<br /> refcount increased and decreased the refcount for the input parameter<br /> @from if it is not NULL.<br /> <br /> If we break the loop in amdgpu_atrm_get_bios() with &amp;#39;pdev&amp;#39; not NULL, we<br /> need to call pci_dev_put() to decrease the refcount. Add the missing<br /> pci_dev_put() to avoid refcount leak.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/xen: Fix memory leak in xen_init_lock_cpu()<br /> <br /> In xen_init_lock_cpu(), the @name has allocated new string by kasprintf(),<br /> if bind_ipi_to_irqhandler() fails, it should be freed, otherwise may lead<br /> to a memory leak issue, fix it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Avoid UBSAN error on true_sectors_per_clst()<br /> <br /> syzbot reported UBSAN error as below:<br /> <br /> [ 76.901829][ T6677] ================================================================================<br /> [ 76.903908][ T6677] UBSAN: shift-out-of-bounds in fs/ntfs3/super.c:675:13<br /> [ 76.905363][ T6677] shift exponent -247 is negative<br /> <br /> This patch avoid this error.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: Fix pcluster memleak when its block address is zero<br /> <br /> syzkaller reported a memleak:<br /> https://syzkaller.appspot.com/bug?id=62f37ff612f0021641eda5b17f056f1668aa9aed<br /> <br /> unreferenced object 0xffff88811009c7f8 (size 136):<br /> ...<br /> backtrace:<br /> [] z_erofs_do_read_page+0x99b/0x1740<br /> [] z_erofs_readahead+0x24e/0x580<br /> [] read_pages+0x86/0x3d0<br /> ...<br /> <br /> syzkaller constructed a case: in z_erofs_register_pcluster(),<br /> ztailpacking = false and map-&gt;m_pa = zero. This makes pcl-&gt;obj.index be<br /> zero although pcl is not a inline pcluster.<br /> <br /> Then following path adds refcount for grp, but the refcount won&amp;#39;t be put<br /> because pcl is inline.<br /> <br /> z_erofs_readahead()<br /> z_erofs_do_read_page() # for another page<br /> z_erofs_collector_begin()<br /> erofs_find_workgroup()<br /> erofs_workgroup_get()<br /> <br /> Since it&amp;#39;s illegal for the block address of a non-inlined pcluster to<br /> be zero, add check here to avoid registering the pcluster which would<br /> be leaked.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Fix hard lockup when reading the rx_monitor from debugfs<br /> <br /> During I/O and simultaneous cat of /sys/kernel/debug/lpfc/fnX/rx_monitor, a<br /> hard lockup similar to the call trace below may occur.<br /> <br /> The spin_lock_bh in lpfc_rx_monitor_report is not protecting from timer<br /> interrupts as expected, so change the strength of the spin lock to _irq.<br /> <br /> Kernel panic - not syncing: Hard LOCKUP<br /> CPU: 3 PID: 110402 Comm: cat Kdump: loaded<br /> <br /> exception RIP: native_queued_spin_lock_slowpath+91<br /> <br /> [IRQ stack]<br /> native_queued_spin_lock_slowpath at ffffffffb814e30b<br /> _raw_spin_lock at ffffffffb89a667a<br /> lpfc_rx_monitor_record at ffffffffc0a73a36 [lpfc]<br /> lpfc_cmf_timer at ffffffffc0abbc67 [lpfc]<br /> __hrtimer_run_queues at ffffffffb8184250<br /> hrtimer_interrupt at ffffffffb8184ab0<br /> smp_apic_timer_interrupt at ffffffffb8a026ba<br /> apic_timer_interrupt at ffffffffb8a01c4f<br /> [End of IRQ stack]<br /> <br /> apic_timer_interrupt at ffffffffb8a01c4f<br /> lpfc_rx_monitor_report at ffffffffc0a73c80 [lpfc]<br /> lpfc_rx_monitor_read at ffffffffc0addde1 [lpfc]<br /> full_proxy_read at ffffffffb83e7fc3<br /> vfs_read at ffffffffb833fe71<br /> ksys_read at ffffffffb83402af<br /> do_syscall_64 at ffffffffb800430b<br /> entry_SYSCALL_64_after_hwframe at ffffffffb8a000ad

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: media: tegra-video: fix device_node use after free<br /> <br /> At probe time this code path is followed:<br /> <br /> * tegra_csi_init<br /> * tegra_csi_channels_alloc<br /> * for_each_child_of_node(node, channel) -- iterates over channels<br /> * automatically gets &amp;#39;channel&amp;#39;<br /> * tegra_csi_channel_alloc()<br /> * saves into chan-&gt;of_node a pointer to the channel OF node<br /> * automatically gets and puts &amp;#39;channel&amp;#39;<br /> * now the node saved in chan-&gt;of_node has refcount 0, can disappear<br /> * tegra_csi_channels_init<br /> * iterates over channels<br /> * tegra_csi_channel_init -- uses chan-&gt;of_node<br /> <br /> After that, chan-&gt;of_node keeps storing the node until the device is<br /> removed.<br /> <br /> of_node_get() the node and of_node_put() it during teardown to avoid any<br /> risk.