Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: solo6x10: fix possible memory leak in solo_sysfs_init()<br /> <br /> If device_register() returns error in solo_sysfs_init(), the<br /> name allocated by dev_set_name() need be freed. As comment of<br /> device_register() says, it should use put_device() to give up<br /> the reference in the error path. So fix this by calling<br /> put_device(), then the name can be freed in kobject_cleanup().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: i2c: hi846: Fix memory leak in hi846_parse_dt()<br /> <br /> If any of the checks related to the supported link frequencies fail, then<br /> the V4L2 fwnode resources don&amp;#39;t get released before returning, which leads<br /> to a memleak. Fix this by properly freeing the V4L2 fwnode data in a<br /> designated label.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm thin: Fix ABBA deadlock between shrink_slab and dm_pool_abort_metadata<br /> <br /> Following concurrent processes:<br /> <br /> P1(drop cache) P2(kworker)<br /> drop_caches_sysctl_handler<br /> drop_slab<br /> shrink_slab<br /> down_read(&amp;shrinker_rwsem) - LOCK A<br /> do_shrink_slab<br /> super_cache_scan<br /> prune_icache_sb<br /> dispose_list<br /> evict<br /> ext4_evict_inode<br /> ext4_clear_inode<br /> ext4_discard_preallocations<br /> ext4_mb_load_buddy_gfp<br /> ext4_mb_init_cache<br /> ext4_read_block_bitmap_nowait<br /> ext4_read_bh_nowait<br /> submit_bh<br /> dm_submit_bio<br /> do_worker<br /> process_deferred_bios<br /> commit<br /> metadata_operation_failed<br /> dm_pool_abort_metadata<br /> down_write(&amp;pmd-&gt;root_lock) - LOCK B<br /> __destroy_persistent_data_objects<br /> dm_block_manager_destroy<br /> dm_bufio_client_destroy<br /> unregister_shrinker<br /> down_write(&amp;shrinker_rwsem)<br /> thin_map |<br /> dm_thin_find_block ↓<br /> down_read(&amp;pmd-&gt;root_lock) --&gt; ABBA deadlock<br /> <br /> , which triggers hung task:<br /> <br /> [ 76.974820] INFO: task kworker/u4:3:63 blocked for more than 15 seconds.<br /> [ 76.976019] Not tainted 6.1.0-rc4-00011-g8f17dd350364-dirty #910<br /> [ 76.978521] task:kworker/u4:3 state:D stack:0 pid:63 ppid:2<br /> [ 76.978534] Workqueue: dm-thin do_worker<br /> [ 76.978552] Call Trace:<br /> [ 76.978564] __schedule+0x6ba/0x10f0<br /> [ 76.978582] schedule+0x9d/0x1e0<br /> [ 76.978588] rwsem_down_write_slowpath+0x587/0xdf0<br /> [ 76.978600] down_write+0xec/0x110<br /> [ 76.978607] unregister_shrinker+0x2c/0xf0<br /> [ 76.978616] dm_bufio_client_destroy+0x116/0x3d0<br /> [ 76.978625] dm_block_manager_destroy+0x19/0x40<br /> [ 76.978629] __destroy_persistent_data_objects+0x5e/0x70<br /> [ 76.978636] dm_pool_abort_metadata+0x8e/0x100<br /> [ 76.978643] metadata_operation_failed+0x86/0x110<br /> [ 76.978649] commit+0x6a/0x230<br /> [ 76.978655] do_worker+0xc6e/0xd90<br /> [ 76.978702] process_one_work+0x269/0x630<br /> [ 76.978714] worker_thread+0x266/0x630<br /> [ 76.978730] kthread+0x151/0x1b0<br /> [ 76.978772] INFO: task test.sh:2646 blocked for more than 15 seconds.<br /> [ 76.979756] Not tainted 6.1.0-rc4-00011-g8f17dd350364-dirty #910<br /> [ 76.982111] task:test.sh state:D stack:0 pid:2646 ppid:2459<br /> [ 76.982128] Call Trace:<br /> [ 76.982139] __schedule+0x6ba/0x10f0<br /> [ 76.982155] schedule+0x9d/0x1e0<br /> [ 76.982159] rwsem_down_read_slowpath+0x4f4/0x910<br /> [ 76.982173] down_read+0x84/0x170<br /> [ 76.982177] dm_thin_find_block+0x4c/0xd0<br /> [ 76.982183] thin_map+0x201/0x3d0<br /> [ 76.982188] __map_bio+0x5b/0x350<br /> [ 76.982195] dm_submit_bio+0x2b6/0x930<br /> [ 76.982202] __submit_bio+0x123/0x2d0<br /> [ 76.982209] submit_bio_noacct_nocheck+0x101/0x3e0<br /> [ 76.982222] submit_bio_noacct+0x389/0x770<br /> [ 76.982227] submit_bio+0x50/0xc0<br /> [ 76.982232] submit_bh_wbc+0x15e/0x230<br /> [ 76.982238] submit_bh+0x14/0x20<br /> [ 76.982241] ext4_read_bh_nowait+0xc5/0x130<br /> [ 76.982247] ext4_read_block_bitmap_nowait+0x340/0xc60<br /> [ 76.982254] ext4_mb_init_cache+0x1ce/0xdc0<br /> [ 76.982259] ext4_mb_load_buddy_gfp+0x987/0xfa0<br /> [ 76.982263] ext4_discard_preallocations+0x45d/0x830<br /> [ 76.982274] ext4_clear_inode+0x48/0xf0<br /> [ 76.982280] ext4_evict_inode+0xcf/0xc70<br /> [ 76.982285] evict+0x119/0x2b0<br /> [ 76.982290] dispose_list+0x43/0xa0<br /> [ 76.982294] prune_icache_sb+0x64/0x90<br /> [ 76.982298] super_cache_scan+0x155/0x210<br /> [ 76.982303] do_shrink_slab+0x19e/0x4e0<br /> [ 76.982310] shrink_slab+0x2bd/0x450<br /> [ 76.982317] drop_slab+0xcc/0x1a0<br /> [ 76.982323] drop_caches_sysctl_handler+0xb7/0xe0<br /> [ 76.982327] proc_sys_call_handler+0x1bc/0x300<br /> [ 76.982331] proc_sys_write+0x17/0x20<br /> [ 76.982334] vfs_write+0x3d3/0x570<br /> [ 76.982342] ksys_write+0x73/0x160<br /> [ 76.982347] __x64_sys_write+0x1e/0x30<br /> [ 76.982352] do_syscall_64+0x35/0x80<br /> [ 76.982357] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Funct<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: host: xhci: Fix potential memory leak in xhci_alloc_stream_info()<br /> <br /> xhci_alloc_stream_info() allocates stream context array for stream_info<br /> -&gt;stream_ctx_array with xhci_alloc_stream_ctx(). When some error occurs,<br /> stream_info-&gt;stream_ctx_array is not released, which will lead to a<br /> memory leak.<br /> <br /> We can fix it by releasing the stream_info-&gt;stream_ctx_array with<br /> xhci_free_stream_ctx() on the error path to avoid the potential memory<br /> leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vme: Fix error not catched in fake_init()<br /> <br /> In fake_init(), __root_device_register() is possible to fail but it&amp;#39;s<br /> ignored, which can cause unregistering vme_root fail when exit.<br /> <br /> general protection fault,<br /> probably for non-canonical address 0xdffffc000000008c<br /> KASAN: null-ptr-deref in range [0x0000000000000460-0x0000000000000467]<br /> RIP: 0010:root_device_unregister+0x26/0x60<br /> Call Trace:<br /> <br /> __x64_sys_delete_module+0x34f/0x540<br /> do_syscall_64+0x38/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Return error when __root_device_register() fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: OMAP2+: omap4-common: Fix refcount leak bug<br /> <br /> In omap4_sram_init(), of_find_compatible_node() will return a node<br /> pointer with refcount incremented. We should use of_node_put() when<br /> it is not used anymore.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: qcom-adm: fix wrong sizeof config in slave_config<br /> <br /> Fix broken slave_config function that uncorrectly compare the<br /> peripheral_size with the size of the config pointer instead of the size<br /> of the config struct. This cause the crci value to be ignored and cause<br /> a kernel panic on any slave that use adm driver.<br /> <br /> To fix this, compare to the size of the struct and NOT the size of the<br /> pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: ti: k3-udma: Reset UDMA_CHAN_RT byte counters to prevent overflow<br /> <br /> UDMA_CHAN_RT_*BCNT_REG stores the real-time channel bytecount statistics.<br /> These registers are 32-bit hardware counters and the driver uses these<br /> counters to monitor the operational progress status for a channel, when<br /> transferring more than 4GB of data it was observed that these counters<br /> overflow and completion calculation of a operation gets affected and the<br /> transfer hangs indefinitely.<br /> <br /> This commit adds changes to decrease the byte count for every complete<br /> transaction so that these registers never overflow and the proper byte<br /> count statistics is maintained for ongoing transaction by the RT counters.<br /> <br /> Earlier uc-&gt;bcnt used to maintain a count of the completed bytes at driver<br /> side, since the RT counters maintain the statistics of current transaction<br /> now, the maintenance of uc-&gt;bcnt is not necessary.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: si470x: Fix use-after-free in si470x_int_in_callback()<br /> <br /> syzbot reported use-after-free in si470x_int_in_callback() [1]. This<br /> indicates that urb-&gt;context, which contains struct si470x_device<br /> object, is freed when si470x_int_in_callback() is called.<br /> <br /> The cause of this issue is that si470x_int_in_callback() is called for<br /> freed urb.<br /> <br /> si470x_usb_driver_probe() calls si470x_start_usb(), which then calls<br /> usb_submit_urb() and si470x_start(). If si470x_start_usb() fails,<br /> si470x_usb_driver_probe() doesn&amp;#39;t kill urb, but it just frees struct<br /> si470x_device object, as depicted below:<br /> <br /> si470x_usb_driver_probe()<br /> ...<br /> si470x_start_usb()<br /> ...<br /> usb_submit_urb()<br /> retval = si470x_start()<br /> return retval<br /> if (retval

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Fix mr-&gt;map double free<br /> <br /> rxe_mr_cleanup() which tries to free mr-&gt;map again will be called when<br /> rxe_mr_init_user() fails:<br /> <br /> CPU: 0 PID: 4917 Comm: rdma_flush_serv Kdump: loaded Not tainted 6.1.0-rc1-roce-flush+ #25<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x45/0x5d<br /> panic+0x19e/0x349<br /> end_report.part.0+0x54/0x7c<br /> kasan_report.cold+0xa/0xf<br /> rxe_mr_cleanup+0x9d/0xf0 [rdma_rxe]<br /> __rxe_cleanup+0x10a/0x1e0 [rdma_rxe]<br /> rxe_reg_user_mr+0xb7/0xd0 [rdma_rxe]<br /> ib_uverbs_reg_mr+0x26a/0x480 [ib_uverbs]<br /> ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x1a2/0x250 [ib_uverbs]<br /> ib_uverbs_cmd_verbs+0x1397/0x15a0 [ib_uverbs]<br /> <br /> This issue was firstly exposed since commit b18c7da63fcb ("RDMA/rxe: Fix<br /> memory leak in error path code") and then we fixed it in commit<br /> 8ff5f5d9d8cf ("RDMA/rxe: Prevent double freeing rxe_map_set()") but this<br /> fix was reverted together at last by commit 1e75550648da (Revert<br /> "RDMA/rxe: Create duplicate mapping tables for FMRs")<br /> <br /> Simply let rxe_mr_cleanup() always handle freeing the mr-&gt;map once it is<br /> successfully allocated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> r6040: Fix kmemleak in probe and remove<br /> <br /> There is a memory leaks reported by kmemleak:<br /> <br /> unreferenced object 0xffff888116111000 (size 2048):<br /> comm "modprobe", pid 817, jiffies 4294759745 (age 76.502s)<br /> hex dump (first 32 bytes):<br /> 00 c4 0a 04 81 88 ff ff 08 10 11 16 81 88 ff ff ................<br /> 08 10 11 16 81 88 ff ff 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] kmalloc_trace+0x22/0x60<br /> [] phy_device_create+0x4e/0x90<br /> [] get_phy_device+0xd2/0x220<br /> [] mdiobus_scan+0xa4/0x2e0<br /> [] __mdiobus_register+0x482/0x8b0<br /> [] r6040_init_one+0x714/0xd2c [r6040]<br /> ...<br /> <br /> The problem occurs in probe process as follows:<br /> r6040_init_one:<br /> mdiobus_register<br /> mdiobus_scan

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Fix repeated calls to sock_put() when msg has more_data<br /> <br /> In tcp_bpf_send_verdict() redirection, the eval variable is assigned to<br /> __SK_REDIRECT after the apply_bytes data is sent, if msg has more_data,<br /> sock_put() will be called multiple times.<br /> <br /> We should reset the eval variable to __SK_NONE every time more_data<br /> starts.<br /> <br /> This causes:<br /> <br /> IPv4: Attempt to release TCP socket in state 1 00000000b4c925d7<br /> ------------[ cut here ]------------<br /> refcount_t: addition on 0; use-after-free.<br /> WARNING: CPU: 5 PID: 4482 at lib/refcount.c:25 refcount_warn_saturate+0x7d/0x110<br /> Modules linked in:<br /> CPU: 5 PID: 4482 Comm: sockhash_bypass Kdump: loaded Not tainted 6.0.0 #1<br /> Hardware name: Red Hat KVM, BIOS 1.11.0-2.el7 04/01/2014<br /> Call Trace:<br /> <br /> __tcp_transmit_skb+0xa1b/0xb90<br /> ? __alloc_skb+0x8c/0x1a0<br /> ? __kmalloc_node_track_caller+0x184/0x320<br /> tcp_write_xmit+0x22a/0x1110<br /> __tcp_push_pending_frames+0x32/0xf0<br /> do_tcp_sendpages+0x62d/0x640<br /> tcp_bpf_push+0xae/0x2c0<br /> tcp_bpf_sendmsg_redir+0x260/0x410<br /> ? preempt_count_add+0x70/0xa0<br /> tcp_bpf_send_verdict+0x386/0x4b0<br /> tcp_bpf_sendmsg+0x21b/0x3b0<br /> sock_sendmsg+0x58/0x70<br /> __sys_sendto+0xfa/0x170<br /> ? xfd_validate_state+0x1d/0x80<br /> ? switch_fpu_return+0x59/0xe0<br /> __x64_sys_sendto+0x24/0x30<br /> do_syscall_64+0x37/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd