Vulnerabilities

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.

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.

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.

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.

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.

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.

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

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: validate the extent length for uncompressed pclusters<br /> <br /> syzkaller reported a KASAN use-after-free:<br /> https://syzkaller.appspot.com/bug?extid=2ae90e873e97f1faf6f2<br /> <br /> The referenced fuzzed image actually has two issues:<br /> - m_pa == 0 as a non-inlined pcluster;<br /> - The logical length is longer than its physical length.<br /> <br /> The first issue has already been addressed. This patch addresses<br /> the second issue by checking the extent length validity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfs: Fix OOB Write in hfs_asc2mac<br /> <br /> Syzbot reported a OOB Write bug:<br /> <br /> loop0: detected capacity change from 0 to 64<br /> ==================================================================<br /> BUG: KASAN: slab-out-of-bounds in hfs_asc2mac+0x467/0x9a0<br /> fs/hfs/trans.c:133<br /> Write of size 1 at addr ffff88801848314e by task syz-executor391/3632<br /> <br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106<br /> print_address_description+0x74/0x340 mm/kasan/report.c:284<br /> print_report+0x107/0x1f0 mm/kasan/report.c:395<br /> kasan_report+0xcd/0x100 mm/kasan/report.c:495<br /> hfs_asc2mac+0x467/0x9a0 fs/hfs/trans.c:133<br /> hfs_cat_build_key+0x92/0x170 fs/hfs/catalog.c:28<br /> hfs_lookup+0x1ab/0x2c0 fs/hfs/dir.c:31<br /> lookup_open fs/namei.c:3391 [inline]<br /> open_last_lookups fs/namei.c:3481 [inline]<br /> path_openat+0x10e6/0x2df0 fs/namei.c:3710<br /> do_filp_open+0x264/0x4f0 fs/namei.c:3740<br /> <br /> If in-&gt;len is much larger than HFS_NAMELEN(31) which is the maximum<br /> length of an HFS filename, a OOB write could occur in hfs_asc2mac(). In<br /> that case, when the dst reaches the boundary, the srclen is still<br /> greater than 0, which causes a OOB write.<br /> Fix this by adding a check on dstlen in while() before writing to dst<br /> address.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipc: mqueue: fix possible memory leak in init_mqueue_fs()<br /> <br /> commit db7cfc380900 ("ipc: Free mq_sysctls if ipc namespace creation<br /> failed")<br /> <br /> Here&amp;#39;s a similar memory leak to the one fixed by the patch above.<br /> retire_mq_sysctls need to be called when init_mqueue_fs fails after<br /> setup_mq_sysctls.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> acct: fix potential integer overflow in encode_comp_t()<br /> <br /> The integer overflow is descripted with following codes:<br /> &gt; 317 static comp_t encode_comp_t(u64 value)<br /> &gt; 318 {<br /> &gt; 319 int exp, rnd;<br /> ......<br /> &gt; 341 exp 343 return exp;<br /> &gt; 344 }<br /> <br /> Currently comp_t is defined as type of &amp;#39;__u16&amp;#39;, but the variable &amp;#39;exp&amp;#39; is<br /> type of &amp;#39;int&amp;#39;, so overflow would happen when variable &amp;#39;exp&amp;#39; in line 343 is<br /> greater than 65535.