Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: Fix system crash due to lack of free space in LFS<br /> <br /> When f2fs tries to checkpoint during foreground gc in LFS mode, system<br /> crash occurs due to lack of free space if the amount of dirty node and<br /> dentry pages generated by data migration exceeds free space.<br /> The reproduction sequence is as follows.<br /> <br /> - 20GiB capacity block device (null_blk)<br /> - format and mount with LFS mode<br /> - create a file and write 20,000MiB<br /> - 4k random write on full range of the file<br /> <br /> RIP: 0010:new_curseg+0x48a/0x510 [f2fs]<br /> Code: 55 e7 f5 89 c0 48 0f af c3 48 8b 5d c0 48 c1 e8 20 83 c0 01 89 43 6c 48 83 c4 28 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0b f0 41 80 4f 48 04 45 85 f6 0f 84 ba fd ff ff e9 ef fe ff ff<br /> RSP: 0018:ffff977bc397b218 EFLAGS: 00010246<br /> RAX: 00000000000027b9 RBX: 0000000000000000 RCX: 00000000000027c0<br /> RDX: 0000000000000000 RSI: 00000000000027b9 RDI: ffff8c25ab4e74f8<br /> RBP: ffff977bc397b268 R08: 00000000000027b9 R09: ffff8c29e4a34b40<br /> R10: 0000000000000001 R11: ffff977bc397b0d8 R12: 0000000000000000<br /> R13: ffff8c25b4dd81a0 R14: 0000000000000000 R15: ffff8c2f667f9000<br /> FS: 0000000000000000(0000) GS:ffff8c344ec80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000c00055d000 CR3: 0000000e30810003 CR4: 00000000003706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> allocate_segment_by_default+0x9c/0x110 [f2fs]<br /> f2fs_allocate_data_block+0x243/0xa30 [f2fs]<br /> ? __mod_lruvec_page_state+0xa0/0x150<br /> do_write_page+0x80/0x160 [f2fs]<br /> f2fs_do_write_node_page+0x32/0x50 [f2fs]<br /> __write_node_page+0x339/0x730 [f2fs]<br /> f2fs_sync_node_pages+0x5a6/0x780 [f2fs]<br /> block_operations+0x257/0x340 [f2fs]<br /> f2fs_write_checkpoint+0x102/0x1050 [f2fs]<br /> f2fs_gc+0x27c/0x630 [f2fs]<br /> ? folio_mark_dirty+0x36/0x70<br /> f2fs_balance_fs+0x16f/0x180 [f2fs]<br /> <br /> This patch adds checking whether free sections are enough before checkpoint<br /> during gc.<br /> <br /> [Jaegeuk Kim: code clean-up]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: j1939: prevent deadlock by moving j1939_sk_errqueue()<br /> <br /> This commit addresses a deadlock situation that can occur in certain<br /> scenarios, such as when running data TP/ETP transfer and subscribing to<br /> the error queue while receiving a net down event. The deadlock involves<br /> locks in the following order:<br /> <br /> 3<br /> j1939_session_list_lock -&gt; active_session_list_lock<br /> j1939_session_activate<br /> ...<br /> j1939_sk_queue_activate_next -&gt; sk_session_queue_lock<br /> ...<br /> j1939_xtp_rx_eoma_one<br /> <br /> 2<br /> j1939_sk_queue_drop_all -&gt; sk_session_queue_lock<br /> ...<br /> j1939_sk_netdev_event_netdown -&gt; j1939_socks_lock<br /> j1939_netdev_notify<br /> <br /> 1<br /> j1939_sk_errqueue -&gt; j1939_socks_lock<br /> __j1939_session_cancel -&gt; active_session_list_lock<br /> j1939_tp_rxtimer<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> lock(&amp;priv-&gt;active_session_list_lock);<br /> lock(&amp;jsk-&gt;sk_session_queue_lock);<br /> lock(&amp;priv-&gt;active_session_list_lock);<br /> lock(&amp;priv-&gt;j1939_socks_lock);<br /> <br /> The solution implemented in this commit is to move the<br /> j1939_sk_errqueue() call out of the active_session_list_lock context,<br /> thus preventing the deadlock situation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: turn quotas off if mount failed after enabling quotas<br /> <br /> Yi found during a review of the patch "ext4: don&amp;#39;t BUG on inconsistent<br /> journal feature" that when ext4_mark_recovery_complete() returns an error<br /> value, the error handling path does not turn off the enabled quotas,<br /> which triggers the following kmemleak:<br /> <br /> ================================================================<br /> unreferenced object 0xffff8cf68678e7c0 (size 64):<br /> comm "mount", pid 746, jiffies 4294871231 (age 11.540s)<br /> hex dump (first 32 bytes):<br /> 00 90 ef 82 f6 8c ff ff 00 00 00 00 41 01 00 00 ............A...<br /> c7 00 00 00 bd 00 00 00 0a 00 00 00 48 00 00 00 ............H...<br /> backtrace:<br /> [] __kmem_cache_alloc_node+0x4d4/0x880<br /> [] kmalloc_trace+0x39/0x140<br /> [] v2_read_file_info+0x18a/0x3a0<br /> [] dquot_load_quota_sb+0x2ed/0x770<br /> [] dquot_load_quota_inode+0xc6/0x1c0<br /> [] ext4_enable_quotas+0x17e/0x3a0 [ext4]<br /> [] __ext4_fill_super+0x3448/0x3910 [ext4]<br /> [] ext4_fill_super+0x13d/0x340 [ext4]<br /> [] get_tree_bdev+0x1dc/0x370<br /> [] ext4_get_tree+0x1d/0x30 [ext4]<br /> [] vfs_get_tree+0x31/0x160<br /> [] do_new_mount+0x1d5/0x480<br /> [] path_mount+0x22e/0xbe0<br /> [] do_mount+0x95/0xc0<br /> [] __x64_sys_mount+0xc4/0x160<br /> [] do_syscall_64+0x3f/0x90<br /> ================================================================<br /> <br /> To solve this problem, we add a "failed_mount10" tag, and call<br /> ext4_quota_off_umount() in this tag to release the enabled qoutas.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: core: Fix target_cmd_counter leak<br /> <br /> The target_cmd_counter struct allocated via target_alloc_cmd_counter() is<br /> never freed, resulting in leaks across various transport types, e.g.:<br /> <br /> unreferenced object 0xffff88801f920120 (size 96):<br /> comm "sh", pid 102, jiffies 4294892535 (age 713.412s)<br /> hex dump (first 32 bytes):<br /> 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 38 01 92 1f 80 88 ff ff ........8.......<br /> backtrace:<br /> [] kmalloc_trace+0x11/0x20<br /> [] target_alloc_cmd_counter+0x17/0x90 [target_core_mod]<br /> [] target_setup_session+0x2d/0x140 [target_core_mod]<br /> [] tcm_loop_tpg_nexus_store+0x19b/0x350 [tcm_loop]<br /> [] configfs_write_iter+0xb1/0x120<br /> [] vfs_write+0x2e4/0x3c0<br /> [] ksys_write+0x80/0xb0<br /> [] do_syscall_64+0x42/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> <br /> Free the structure alongside the corresponding iscsit_conn / se_sess<br /> parent.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: core: remove unnecessary frame_sz check in bpf_xdp_adjust_tail()<br /> <br /> Syzkaller reported the following issue:<br /> =======================================<br /> Too BIG xdp-&gt;frame_sz = 131072<br /> WARNING: CPU: 0 PID: 5020 at net/core/filter.c:4121<br /> ____bpf_xdp_adjust_tail net/core/filter.c:4121 [inline]<br /> WARNING: CPU: 0 PID: 5020 at net/core/filter.c:4121<br /> bpf_xdp_adjust_tail+0x466/0xa10 net/core/filter.c:4103<br /> ...<br /> Call Trace:<br /> <br /> bpf_prog_4add87e5301a4105+0x1a/0x1c<br /> __bpf_prog_run include/linux/filter.h:600 [inline]<br /> bpf_prog_run_xdp include/linux/filter.h:775 [inline]<br /> bpf_prog_run_generic_xdp+0x57e/0x11e0 net/core/dev.c:4721<br /> netif_receive_generic_xdp net/core/dev.c:4807 [inline]<br /> do_xdp_generic+0x35c/0x770 net/core/dev.c:4866<br /> tun_get_user+0x2340/0x3ca0 drivers/net/tun.c:1919<br /> tun_chr_write_iter+0xe8/0x210 drivers/net/tun.c:2043<br /> call_write_iter include/linux/fs.h:1871 [inline]<br /> new_sync_write fs/read_write.c:491 [inline]<br /> vfs_write+0x650/0xe40 fs/read_write.c:584<br /> ksys_write+0x12f/0x250 fs/read_write.c:637<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> xdp-&gt;frame_sz &gt; PAGE_SIZE check was introduced in commit c8741e2bfe87<br /> ("xdp: Allow bpf_xdp_adjust_tail() to grow packet size"). But Jesper<br /> Dangaard Brouer noted that after introducing the<br /> xdp_init_buff() which all XDP driver use - it&amp;#39;s safe to remove this<br /> check. The original intend was to catch cases where XDP drivers have<br /> not been updated to use xdp.frame_sz, but that is not longer a concern<br /> (since xdp_init_buff).<br /> <br /> Running the initial syzkaller repro it was discovered that the<br /> contiguous physical memory allocation is used for both xdp paths in<br /> tun_get_user(), e.g. tun_build_skb() and tun_alloc_skb(). It was also<br /> stated by Jesper Dangaard Brouer that XDP can<br /> work on higher order pages, as long as this is contiguous physical<br /> memory (e.g. a page).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sfc: fix crash when reading stats while NIC is resetting<br /> <br /> efx_net_stats() (.ndo_get_stats64) can be called during an ethtool<br /> selftest, during which time nic_data-&gt;mc_stats is NULL as the NIC has<br /> been fini&amp;#39;d. In this case do not attempt to fetch the latest stats<br /> from the hardware, else we will crash on a NULL dereference:<br /> BUG: kernel NULL pointer dereference, address: 0000000000000038<br /> RIP efx_nic_update_stats<br /> abridged calltrace:<br /> efx_ef10_update_stats_pf<br /> efx_net_stats<br /> dev_get_stats<br /> dev_seq_printf_stats<br /> Skipping the read is safe, we will simply give out stale stats.<br /> To ensure that the free in efx_ef10_fini_nic() does not race against<br /> efx_ef10_update_stats_pf(), which could cause a TOCTTOU bug, take the<br /> efx-&gt;stats_lock in fini_nic (it is already held across update_stats).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binder: fix UAF of alloc-&gt;vma in race with munmap()<br /> <br /> [ cmllamas: clean forward port from commit 015ac18be7de ("binder: fix<br /> UAF of alloc-&gt;vma in race with munmap()") in 5.10 stable. It is needed<br /> in mainline after the revert of commit a43cfc87caaf ("android: binder:<br /> stop saving a pointer to the VMA") as pointed out by Liam. The commit<br /> log and tags have been tweaked to reflect this. ]<br /> <br /> In commit 720c24192404 ("ANDROID: binder: change down_write to<br /> down_read") binder assumed the mmap read lock is sufficient to protect<br /> alloc-&gt;vma inside binder_update_page_range(). This used to be accurate<br /> until commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in<br /> munmap"), which now downgrades the mmap_lock after detaching the vma<br /> from the rbtree in munmap(). Then it proceeds to teardown and free the<br /> vma with only the read lock held.<br /> <br /> This means that accesses to alloc-&gt;vma in binder_update_page_range() now<br /> will race with vm_area_free() in munmap() and can cause a UAF as shown<br /> in the following KASAN trace:<br /> <br /> ==================================================================<br /> BUG: KASAN: use-after-free in vm_insert_page+0x7c/0x1f0<br /> Read of size 8 at addr ffff16204ad00600 by task server/558<br /> <br /> CPU: 3 PID: 558 Comm: server Not tainted 5.10.150-00001-gdc8dcf942daa #1<br /> Hardware name: linux,dummy-virt (DT)<br /> Call trace:<br /> dump_backtrace+0x0/0x2a0<br /> show_stack+0x18/0x2c<br /> dump_stack+0xf8/0x164<br /> print_address_description.constprop.0+0x9c/0x538<br /> kasan_report+0x120/0x200<br /> __asan_load8+0xa0/0xc4<br /> vm_insert_page+0x7c/0x1f0<br /> binder_update_page_range+0x278/0x50c<br /> binder_alloc_new_buf+0x3f0/0xba0<br /> binder_transaction+0x64c/0x3040<br /> binder_thread_write+0x924/0x2020<br /> binder_ioctl+0x1610/0x2e5c<br /> __arm64_sys_ioctl+0xd4/0x120<br /> el0_svc_common.constprop.0+0xac/0x270<br /> do_el0_svc+0x38/0xa0<br /> el0_svc+0x1c/0x2c<br /> el0_sync_handler+0xe8/0x114<br /> el0_sync+0x180/0x1c0<br /> <br /> Allocated by task 559:<br /> kasan_save_stack+0x38/0x6c<br /> __kasan_kmalloc.constprop.0+0xe4/0xf0<br /> kasan_slab_alloc+0x18/0x2c<br /> kmem_cache_alloc+0x1b0/0x2d0<br /> vm_area_alloc+0x28/0x94<br /> mmap_region+0x378/0x920<br /> do_mmap+0x3f0/0x600<br /> vm_mmap_pgoff+0x150/0x17c<br /> ksys_mmap_pgoff+0x284/0x2dc<br /> __arm64_sys_mmap+0x84/0xa4<br /> el0_svc_common.constprop.0+0xac/0x270<br /> do_el0_svc+0x38/0xa0<br /> el0_svc+0x1c/0x2c<br /> el0_sync_handler+0xe8/0x114<br /> el0_sync+0x180/0x1c0<br /> <br /> Freed by task 560:<br /> kasan_save_stack+0x38/0x6c<br /> kasan_set_track+0x28/0x40<br /> kasan_set_free_info+0x24/0x4c<br /> __kasan_slab_free+0x100/0x164<br /> kasan_slab_free+0x14/0x20<br /> kmem_cache_free+0xc4/0x34c<br /> vm_area_free+0x1c/0x2c<br /> remove_vma+0x7c/0x94<br /> __do_munmap+0x358/0x710<br /> __vm_munmap+0xbc/0x130<br /> __arm64_sys_munmap+0x4c/0x64<br /> el0_svc_common.constprop.0+0xac/0x270<br /> do_el0_svc+0x38/0xa0<br /> el0_svc+0x1c/0x2c<br /> el0_sync_handler+0xe8/0x114<br /> el0_sync+0x180/0x1c0<br /> <br /> [...]<br /> ==================================================================<br /> <br /> To prevent the race above, revert back to taking the mmap write lock<br /> inside binder_update_page_range(). One might expect an increase of mmap<br /> lock contention. However, binder already serializes these calls via top<br /> level alloc-&gt;mutex. Also, there was no performance impact shown when<br /> running the binder benchmark tests.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: don&amp;#39;t free qgroup space unless specified<br /> <br /> Boris noticed in his simple quotas testing that he was getting a leak<br /> with Sweet Tea&amp;#39;s change to subvol create that stopped doing a<br /> transaction commit. This was just a side effect of that change.<br /> <br /> In the delayed inode code we have an optimization that will free extra<br /> reservations if we think we can pack a dir item into an already modified<br /> leaf. Previously this wouldn&amp;#39;t be triggered in the subvolume create<br /> case because we&amp;#39;d commit the transaction, it was still possible but<br /> much harder to trigger. It could actually be triggered if we did a<br /> mkdir &amp;&amp; subvol create with qgroups enabled.<br /> <br /> This occurs because in btrfs_insert_delayed_dir_index(), which gets<br /> called when we&amp;#39;re adding the dir item, we do the following:<br /> <br /> btrfs_block_rsv_release(fs_info, trans-&gt;block_rsv, bytes, NULL);<br /> <br /> if we&amp;#39;re able to skip reserving space.<br /> <br /> The problem here is that trans-&gt;block_rsv points at the temporary block<br /> rsv for the subvolume create, which has qgroup reservations in the block<br /> rsv.<br /> <br /> This is a problem because btrfs_block_rsv_release() will do the<br /> following:<br /> <br /> if (block_rsv-&gt;qgroup_rsv_reserved &gt;= block_rsv-&gt;qgroup_rsv_size) {<br /> qgroup_to_release = block_rsv-&gt;qgroup_rsv_reserved -<br /> block_rsv-&gt;qgroup_rsv_size;<br /> block_rsv-&gt;qgroup_rsv_reserved = block_rsv-&gt;qgroup_rsv_size;<br /> }<br /> <br /> The temporary block rsv just has -&gt;qgroup_rsv_reserved set,<br /> -&gt;qgroup_rsv_size == 0. The optimization in<br /> btrfs_insert_delayed_dir_index() sets -&gt;qgroup_rsv_reserved = 0. Then<br /> later on when we call btrfs_subvolume_release_metadata() which has<br /> <br /> btrfs_block_rsv_release(fs_info, rsv, (u64)-1, &amp;qgroup_to_release);<br /> btrfs_qgroup_convert_reserved_meta(root, qgroup_to_release);<br /> <br /> qgroup_to_release is set to 0, and we do not convert the reserved<br /> metadata space.<br /> <br /> The problem here is that the block rsv code has been unconditionally<br /> messing with -&gt;qgroup_rsv_reserved, because the main place this is used<br /> is delalloc, and any time we call btrfs_block_rsv_release() we do it<br /> with qgroup_to_release set, and thus do the proper accounting.<br /> <br /> The subvolume code is the only other code that uses the qgroup<br /> reservation stuff, but it&amp;#39;s intermingled with the above optimization,<br /> and thus was getting its reservation freed out from underneath it and<br /> thus leaking the reserved space.<br /> <br /> The solution is to simply not mess with the qgroup reservations if we<br /> don&amp;#39;t have qgroup_to_release set. This works with the existing code as<br /> anything that messes with the delalloc reservations always have<br /> qgroup_to_release set. This fixes the leak that Boris was observing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: mtu3: fix kernel panic at qmu transfer done irq handler<br /> <br /> When handle qmu transfer irq, it will unlock @mtu-&gt;lock before give back<br /> request, if another thread handle disconnect event at the same time, and<br /> try to disable ep, it may lock @mtu-&gt;lock and free qmu ring, then qmu<br /> irq hanlder may get a NULL gpd, avoid the KE by checking gpd&amp;#39;s value before<br /> handling it.<br /> <br /> e.g.<br /> qmu done irq on cpu0 thread running on cpu1<br /> <br /> qmu_done_tx()<br /> handle gpd [0]<br /> mtu3_requ_complete() mtu3_gadget_ep_disable()<br /> unlock @mtu-&gt;lock<br /> give back request lock @mtu-&gt;lock<br /> mtu3_ep_disable()<br /> mtu3_gpd_ring_free()<br /> unlock @mtu-&gt;lock<br /> lock @mtu-&gt;lock<br /> get next gpd [1]<br /> <br /> [1]: goto [0] to handle next gpd, and next gpd may be NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: Add missing hw_ops-&gt;get_ring_selector() for IPQ5018<br /> <br /> During sending data after clients connected, hw_ops-&gt;get_ring_selector()<br /> will be called. But for IPQ5018, this member isn&amp;#39;t set, and the<br /> following NULL pointer exception will be occurred:<br /> <br /> [ 38.840478] 8

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gtp: Fix use-after-free in __gtp_encap_destroy().<br /> <br /> syzkaller reported use-after-free in __gtp_encap_destroy(). [0]<br /> <br /> It shows the same process freed sk and touched it illegally.<br /> <br /> Commit e198987e7dd7 ("gtp: fix suspicious RCU usage") added lock_sock()<br /> and release_sock() in __gtp_encap_destroy() to protect sk-&gt;sk_user_data,<br /> but release_sock() is called after sock_put() releases the last refcnt.<br /> <br /> [0]:<br /> BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:96 [inline]<br /> BUG: KASAN: slab-use-after-free in atomic_try_cmpxchg_acquire include/linux/atomic/atomic-instrumented.h:541 [inline]<br /> BUG: KASAN: slab-use-after-free in queued_spin_lock include/asm-generic/qspinlock.h:111 [inline]<br /> BUG: KASAN: slab-use-after-free in do_raw_spin_lock include/linux/spinlock.h:186 [inline]<br /> BUG: KASAN: slab-use-after-free in __raw_spin_lock_bh include/linux/spinlock_api_smp.h:127 [inline]<br /> BUG: KASAN: slab-use-after-free in _raw_spin_lock_bh+0x75/0xe0 kernel/locking/spinlock.c:178<br /> Write of size 4 at addr ffff88800dbef398 by task syz-executor.2/2401<br /> <br /> CPU: 1 PID: 2401 Comm: syz-executor.2 Not tainted 6.4.0-rc5-01219-gfa0e21fa4443 #2<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 lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x72/0xa0 lib/dump_stack.c:106<br /> print_address_description mm/kasan/report.c:351 [inline]<br /> print_report+0xcc/0x620 mm/kasan/report.c:462<br /> kasan_report+0xb2/0xe0 mm/kasan/report.c:572<br /> check_region_inline mm/kasan/generic.c:181 [inline]<br /> kasan_check_range+0x39/0x1c0 mm/kasan/generic.c:187<br /> instrument_atomic_read_write include/linux/instrumented.h:96 [inline]<br /> atomic_try_cmpxchg_acquire include/linux/atomic/atomic-instrumented.h:541 [inline]<br /> queued_spin_lock include/asm-generic/qspinlock.h:111 [inline]<br /> do_raw_spin_lock include/linux/spinlock.h:186 [inline]<br /> __raw_spin_lock_bh include/linux/spinlock_api_smp.h:127 [inline]<br /> _raw_spin_lock_bh+0x75/0xe0 kernel/locking/spinlock.c:178<br /> spin_lock_bh include/linux/spinlock.h:355 [inline]<br /> release_sock+0x1f/0x1a0 net/core/sock.c:3526<br /> gtp_encap_disable_sock drivers/net/gtp.c:651 [inline]<br /> gtp_encap_disable+0xb9/0x220 drivers/net/gtp.c:664<br /> gtp_dev_uninit+0x19/0x50 drivers/net/gtp.c:728<br /> unregister_netdevice_many_notify+0x97e/0x1520 net/core/dev.c:10841<br /> rtnl_delete_link net/core/rtnetlink.c:3216 [inline]<br /> rtnl_dellink+0x3c0/0xb30 net/core/rtnetlink.c:3268<br /> rtnetlink_rcv_msg+0x450/0xb10 net/core/rtnetlink.c:6423<br /> netlink_rcv_skb+0x15d/0x450 net/netlink/af_netlink.c:2548<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]<br /> netlink_unicast+0x700/0x930 net/netlink/af_netlink.c:1365<br /> netlink_sendmsg+0x91c/0xe30 net/netlink/af_netlink.c:1913<br /> sock_sendmsg_nosec net/socket.c:724 [inline]<br /> sock_sendmsg+0x1b7/0x200 net/socket.c:747<br /> ____sys_sendmsg+0x75a/0x990 net/socket.c:2493<br /> ___sys_sendmsg+0x11d/0x1c0 net/socket.c:2547<br /> __sys_sendmsg+0xfe/0x1d0 net/socket.c:2576<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3f/0x90 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> RIP: 0033:0x7f1168b1fe5d<br /> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48<br /> RSP: 002b:00007f1167edccc8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 00000000004bbf80 RCX: 00007f1168b1fe5d<br /> RDX: 0000000000000000 RSI: 00000000200002c0 RDI: 0000000000000003<br /> RBP: 00000000004bbf80 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 000000000000000b R14: 00007f1168b80530 R15: 0000000000000000<br /> <br /> <br /> Allocated by task 1483:<br /> kasan_save_stack+0x22/0x50 mm/kasan/common.c:45<br /> kasan_set_track+0x25/0x30 mm/kasan/common.c:52<br /> __kasan_slab_alloc+0x<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mediatek: vcodec: fix resource leaks in vdec_msg_queue_init()<br /> <br /> If we encounter any error in the vdec_msg_queue_init() then we need<br /> to set "msg_queue-&gt;wdma_addr.size = 0;". Normally, this is done<br /> inside the vdec_msg_queue_deinit() function. However, if the<br /> first call to allocate &amp;msg_queue-&gt;wdma_addr fails, then the<br /> vdec_msg_queue_deinit() function is a no-op. For that situation, just<br /> set the size to zero explicitly and return.<br /> <br /> There were two other error paths which did not clean up before returning.<br /> Change those error paths to goto mem_alloc_err.