Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: Fix input error path memory access<br /> <br /> When there is a misconfiguration of input state slow path<br /> KASAN report error. Fix this error.<br /> west login:<br /> [ 52.987278] eth1: renamed from veth11<br /> [ 53.078814] eth1: renamed from veth21<br /> [ 53.181355] eth1: renamed from veth31<br /> [ 54.921702] ==================================================================<br /> [ 54.922602] BUG: KASAN: wild-memory-access in xfrmi_rcv_cb+0x2d/0x295<br /> [ 54.923393] Read of size 8 at addr 6b6b6b6b00000000 by task ping/512<br /> [ 54.924169]<br /> [ 54.924386] CPU: 0 PID: 512 Comm: ping Not tainted 6.9.0-08574-gcd29a4313a1b #25<br /> [ 54.925290] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 54.926401] Call Trace:<br /> [ 54.926731] <br /> [ 54.927009] dump_stack_lvl+0x2a/0x3b<br /> [ 54.927478] kasan_report+0x84/0xa6<br /> [ 54.927930] ? xfrmi_rcv_cb+0x2d/0x295<br /> [ 54.928410] xfrmi_rcv_cb+0x2d/0x295<br /> [ 54.928872] ? xfrm4_rcv_cb+0x3d/0x5e<br /> [ 54.929354] xfrm4_rcv_cb+0x46/0x5e<br /> [ 54.929804] xfrm_rcv_cb+0x7e/0xa1<br /> [ 54.930240] xfrm_input+0x1b3a/0x1b96<br /> [ 54.930715] ? xfrm_offload+0x41/0x41<br /> [ 54.931182] ? raw_rcv+0x292/0x292<br /> [ 54.931617] ? nf_conntrack_confirm+0xa2/0xa2<br /> [ 54.932158] ? skb_sec_path+0xd/0x3f<br /> [ 54.932610] ? xfrmi_input+0x90/0xce<br /> [ 54.933066] xfrm4_esp_rcv+0x33/0x54<br /> [ 54.933521] ip_protocol_deliver_rcu+0xd7/0x1b2<br /> [ 54.934089] ip_local_deliver_finish+0x110/0x120<br /> [ 54.934659] ? ip_protocol_deliver_rcu+0x1b2/0x1b2<br /> [ 54.935248] NF_HOOK.constprop.0+0xf8/0x138<br /> [ 54.935767] ? ip_sublist_rcv_finish+0x68/0x68<br /> [ 54.936317] ? secure_tcpv6_ts_off+0x23/0x168<br /> [ 54.936859] ? ip_protocol_deliver_rcu+0x1b2/0x1b2<br /> [ 54.937454] ? __xfrm_policy_check2.constprop.0+0x18d/0x18d<br /> [ 54.938135] NF_HOOK.constprop.0+0xf8/0x138<br /> [ 54.938663] ? ip_sublist_rcv_finish+0x68/0x68<br /> [ 54.939220] ? __xfrm_policy_check2.constprop.0+0x18d/0x18d<br /> [ 54.939904] ? ip_local_deliver_finish+0x120/0x120<br /> [ 54.940497] __netif_receive_skb_one_core+0xc9/0x107<br /> [ 54.941121] ? __netif_receive_skb_list_core+0x1c2/0x1c2<br /> [ 54.941771] ? blk_mq_start_stopped_hw_queues+0xc7/0xf9<br /> [ 54.942413] ? blk_mq_start_stopped_hw_queue+0x38/0x38<br /> [ 54.943044] ? virtqueue_get_buf_ctx+0x295/0x46b<br /> [ 54.943618] process_backlog+0xb3/0x187<br /> [ 54.944102] __napi_poll.constprop.0+0x57/0x1a7<br /> [ 54.944669] net_rx_action+0x1cb/0x380<br /> [ 54.945150] ? __napi_poll.constprop.0+0x1a7/0x1a7<br /> [ 54.945744] ? vring_new_virtqueue+0x17a/0x17a<br /> [ 54.946300] ? note_interrupt+0x2cd/0x367<br /> [ 54.946805] handle_softirqs+0x13c/0x2c9<br /> [ 54.947300] do_softirq+0x5f/0x7d<br /> [ 54.947727] <br /> [ 54.948014] <br /> [ 54.948300] __local_bh_enable_ip+0x48/0x62<br /> [ 54.948832] __neigh_event_send+0x3fd/0x4ca<br /> [ 54.949361] neigh_resolve_output+0x1e/0x210<br /> [ 54.949896] ip_finish_output2+0x4bf/0x4f0<br /> [ 54.950410] ? __ip_finish_output+0x171/0x1b8<br /> [ 54.950956] ip_send_skb+0x25/0x57<br /> [ 54.951390] raw_sendmsg+0xf95/0x10c0<br /> [ 54.951850] ? check_new_pages+0x45/0x71<br /> [ 54.952343] ? raw_hash_sk+0x21b/0x21b<br /> [ 54.952815] ? kernel_init_pages+0x42/0x51<br /> [ 54.953337] ? prep_new_page+0x44/0x51<br /> [ 54.953811] ? get_page_from_freelist+0x72b/0x915<br /> [ 54.954390] ? signal_pending_state+0x77/0x77<br /> [ 54.954936] ? preempt_count_sub+0x14/0xb3<br /> [ 54.955450] ? __might_resched+0x8a/0x240<br /> [ 54.955951] ? __might_sleep+0x25/0xa0<br /> [ 54.956424] ? first_zones_zonelist+0x2c/0x43<br /> [ 54.956977] ? __rcu_read_lock+0x2d/0x3a<br /> [ 54.957476] ? __pte_offset_map+0x32/0xa4<br /> [ 54.957980] ? __might_resched+0x8a/0x240<br /> [ 54.958483] ? __might_sleep+0x25/0xa0<br /> [ 54.958963] ? inet_send_prepare+0x54/0x54<br /> [ 54.959478] ? sock_sendmsg_nosec+0x42/0x6c<br /> [ 54.960000] sock_sendmsg_nosec+0x42/0x6c<br /> [ 54.960502] __sys_sendto+0x15d/0x1cc<br /> [ 54.960966] ? __x64_sys_getpeername+0x44/0x44<br /> [ 54.961522] ? __handle_mm_fault+0x679/0xae4<br /> [ 54.962068] ? find_vma+0x6b/0x<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: change DMA direction while mapping reinjected packets<br /> <br /> For fragmented packets, ath12k reassembles each fragment as a normal<br /> packet and then reinjects it into HW ring. In this case, the DMA<br /> direction should be DMA_TO_DEVICE, not DMA_FROM_DEVICE. Otherwise,<br /> an invalid payload may be reinjected into the HW and<br /> subsequently delivered to the host.<br /> <br /> Given that arbitrary memory can be allocated to the skb buffer,<br /> knowledge about the data contained in the reinjected buffer is lacking.<br /> Consequently, there’s a risk of private information being leaked.<br /> <br /> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00209-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: pci: ivtv: Add check for DMA map result<br /> <br /> In case DMA fails, &amp;#39;dma-&gt;SG_length&amp;#39; is 0. This value is later used to<br /> access &amp;#39;dma-&gt;SGarray[dma-&gt;SG_length - 1]&amp;#39;, which will cause out of<br /> bounds access.<br /> <br /> Add check to return early on invalid value. Adjust warnings accordingly.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he()<br /> <br /> Currently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in<br /> cfg80211_calculate_bitrate_he(), leading to below warning:<br /> <br /> kernel: invalid HE MCS: bw:6, ru:6<br /> kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211]<br /> <br /> Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxsw: spectrum_acl_erp: Fix object nesting warning<br /> <br /> ACLs in Spectrum-2 and newer ASICs can reside in the algorithmic TCAM<br /> (A-TCAM) or in the ordinary circuit TCAM (C-TCAM). The former can<br /> contain more ACLs (i.e., tc filters), but the number of masks in each<br /> region (i.e., tc chain) is limited.<br /> <br /> In order to mitigate the effects of the above limitation, the device<br /> allows filters to share a single mask if their masks only differ in up<br /> to 8 consecutive bits. For example, dst_ip/25 can be represented using<br /> dst_ip/24 with a delta of 1 bit. The C-TCAM does not have a limit on the<br /> number of masks being used (and therefore does not support mask<br /> aggregation), but can contain a limited number of filters.<br /> <br /> The driver uses the "objagg" library to perform the mask aggregation by<br /> passing it objects that consist of the filter&amp;#39;s mask and whether the<br /> filter is to be inserted into the A-TCAM or the C-TCAM since filters in<br /> different TCAMs cannot share a mask.<br /> <br /> The set of created objects is dependent on the insertion order of the<br /> filters and is not necessarily optimal. Therefore, the driver will<br /> periodically ask the library to compute a more optimal set ("hints") by<br /> looking at all the existing objects.<br /> <br /> When the library asks the driver whether two objects can be aggregated<br /> the driver only compares the provided masks and ignores the A-TCAM /<br /> C-TCAM indication. This is the right thing to do since the goal is to<br /> move as many filters as possible to the A-TCAM. The driver also forbids<br /> two identical masks from being aggregated since this can only happen if<br /> one was intentionally put in the C-TCAM to avoid a conflict in the<br /> A-TCAM.<br /> <br /> The above can result in the following set of hints:<br /> <br /> H1: {mask X, A-TCAM} -&gt; H2: {mask Y, A-TCAM} // X is Y + delta<br /> H3: {mask Y, C-TCAM} -&gt; H4: {mask Z, A-TCAM} // Y is Z + delta<br /> <br /> After getting the hints from the library the driver will start migrating<br /> filters from one region to another while consulting the computed hints<br /> and instructing the device to perform a lookup in both regions during<br /> the transition.<br /> <br /> Assuming a filter with mask X is being migrated into the A-TCAM in the<br /> new region, the hints lookup will return H1. Since H2 is the parent of<br /> H1, the library will try to find the object associated with it and<br /> create it if necessary in which case another hints lookup (recursive)<br /> will be performed. This hints lookup for {mask Y, A-TCAM} will either<br /> return H2 or H3 since the driver passes the library an object comparison<br /> function that ignores the A-TCAM / C-TCAM indication.<br /> <br /> This can eventually lead to nested objects which are not supported by<br /> the library [1].<br /> <br /> Fix by removing the object comparison function from both the driver and<br /> the library as the driver was the only user. That way the lookup will<br /> only return exact matches.<br /> <br /> I do not have a reliable reproducer that can reproduce the issue in a<br /> timely manner, but before the fix the issue would reproduce in several<br /> minutes and with the fix it does not reproduce in over an hour.<br /> <br /> Note that the current usefulness of the hints is limited because they<br /> include the C-TCAM indication and represent aggregation that cannot<br /> actually happen. This will be addressed in net-next.<br /> <br /> [1]<br /> WARNING: CPU: 0 PID: 153 at lib/objagg.c:170 objagg_obj_parent_assign+0xb5/0xd0<br /> Modules linked in:<br /> CPU: 0 PID: 153 Comm: kworker/0:18 Not tainted 6.9.0-rc6-custom-g70fbc2c1c38b #42<br /> Hardware name: Mellanox Technologies Ltd. MSN3700C/VMOD0008, BIOS 5.11 10/10/2018<br /> Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work<br /> RIP: 0010:objagg_obj_parent_assign+0xb5/0xd0<br /> [...]<br /> Call Trace:<br /> <br /> __objagg_obj_get+0x2bb/0x580<br /> objagg_obj_get+0xe/0x80<br /> mlxsw_sp_acl_erp_mask_get+0xb5/0xf0<br /> mlxsw_sp_acl_atcam_entry_add+0xe8/0x3c0<br /> mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0<br /> mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270<br /> mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510<br /> process_one_work+0x151/0x370

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exec: Fix ToCToU between perm check and set-uid/gid usage<br /> <br /> When opening a file for exec via do_filp_open(), permission checking is<br /> done against the file&amp;#39;s metadata at that moment, and on success, a file<br /> pointer is passed back. Much later in the execve() code path, the file<br /> metadata (specifically mode, uid, and gid) is used to determine if/how<br /> to set the uid and gid. However, those values may have changed since the<br /> permissions check, meaning the execution may gain unintended privileges.<br /> <br /> For example, if a file could change permissions from executable and not<br /> set-id:<br /> <br /> ---------x 1 root root 16048 Aug 7 13:16 target<br /> <br /> to set-id and non-executable:<br /> <br /> ---S------ 1 root root 16048 Aug 7 13:16 target<br /> <br /> it is possible to gain root privileges when execution should have been<br /> disallowed.<br /> <br /> While this race condition is rare in real-world scenarios, it has been<br /> observed (and proven exploitable) when package managers are updating<br /> the setuid bits of installed programs. Such files start with being<br /> world-executable but then are adjusted to be group-exec with a set-uid<br /> bit. For example, "chmod o-x,u+s target" makes "target" executable only<br /> by uid "root" and gid "cdrom", while also becoming setuid-root:<br /> <br /> -rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 target<br /> <br /> becomes:<br /> <br /> -rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 target<br /> <br /> But racing the chmod means users without group "cdrom" membership can<br /> get the permission to execute "target" just before the chmod, and when<br /> the chmod finishes, the exec reaches brpm_fill_uid(), and performs the<br /> setuid to root, violating the expressed authorization of "only cdrom<br /> group members can setuid to root".<br /> <br /> Re-check that we still have execute permissions in case the metadata<br /> has changed. It would be better to keep a copy from the perm-check time,<br /> but until we can do that refactoring, the least-bad option is to do a<br /> full inode_permission() call (under inode lock). It is understood that<br /> this is safe against dead-locks, but hardly optimal.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/hns: Fix soft lockup under heavy CEQE load<br /> <br /> CEQEs are handled in interrupt handler currently. This may cause the<br /> CPU core staying in interrupt context too long and lead to soft lockup<br /> under heavy load.<br /> <br /> Handle CEQEs in BH workqueue and set an upper limit for the number of<br /> CEQE handled by a single call of work handler.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: ccp - Fix null pointer dereference in __sev_snp_shutdown_locked<br /> <br /> Fix a null pointer dereference induced by DEBUG_TEST_DRIVER_REMOVE.<br /> Return from __sev_snp_shutdown_locked() if the psp_device or the<br /> sev_device structs are not initialized. Without the fix, the driver will<br /> produce the following splat:<br /> <br /> ccp 0000:55:00.5: enabling device (0000 -&gt; 0002)<br /> ccp 0000:55:00.5: sev enabled<br /> ccp 0000:55:00.5: psp enabled<br /> BUG: kernel NULL pointer dereference, address: 00000000000000f0<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC NOPTI<br /> CPU: 262 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc1+ #29<br /> RIP: 0010:__sev_snp_shutdown_locked+0x2e/0x150<br /> Code: 00 55 48 89 e5 41 57 41 56 41 54 53 48 83 ec 10 41 89 f7 49 89 fe 65 48 8b 04 25 28 00 00 00 48 89 45 d8 48 8b 05 6a 5a 7f 06 8b a0 f0 00 00 00 41 0f b6 9c 24 a2 00 00 00 48 83 fb 02 0f 83<br /> RSP: 0018:ffffb2ea4014b7b8 EFLAGS: 00010286<br /> RAX: 0000000000000000 RBX: ffff9e4acd2e0a28 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffb2ea4014b808<br /> RBP: ffffb2ea4014b7e8 R08: 0000000000000106 R09: 000000000003d9c0<br /> R10: 0000000000000001 R11: ffffffffa39ff070 R12: ffff9e49d40590c8<br /> R13: 0000000000000000 R14: ffffb2ea4014b808 R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffff9e58b1e00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00000000000000f0 CR3: 0000000418a3e001 CR4: 0000000000770ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __die_body+0x6f/0xb0<br /> ? __die+0xcc/0xf0<br /> ? page_fault_oops+0x330/0x3a0<br /> ? save_trace+0x2a5/0x360<br /> ? do_user_addr_fault+0x583/0x630<br /> ? exc_page_fault+0x81/0x120<br /> ? asm_exc_page_fault+0x2b/0x30<br /> ? __sev_snp_shutdown_locked+0x2e/0x150<br /> __sev_firmware_shutdown+0x349/0x5b0<br /> ? pm_runtime_barrier+0x66/0xe0<br /> sev_dev_destroy+0x34/0xb0<br /> psp_dev_destroy+0x27/0x60<br /> sp_destroy+0x39/0x90<br /> sp_pci_remove+0x22/0x60<br /> pci_device_remove+0x4e/0x110<br /> really_probe+0x271/0x4e0<br /> __driver_probe_device+0x8f/0x160<br /> driver_probe_device+0x24/0x120<br /> __driver_attach+0xc7/0x280<br /> ? driver_attach+0x30/0x30<br /> bus_for_each_dev+0x10d/0x130<br /> driver_attach+0x22/0x30<br /> bus_add_driver+0x171/0x2b0<br /> ? unaccepted_memory_init_kdump+0x20/0x20<br /> driver_register+0x67/0x100<br /> __pci_register_driver+0x83/0x90<br /> sp_pci_init+0x22/0x30<br /> sp_mod_init+0x13/0x30<br /> do_one_initcall+0xb8/0x290<br /> ? sched_clock_noinstr+0xd/0x10<br /> ? local_clock_noinstr+0x3e/0x100<br /> ? stack_depot_save_flags+0x21e/0x6a0<br /> ? local_clock+0x1c/0x60<br /> ? stack_depot_save_flags+0x21e/0x6a0<br /> ? sched_clock_noinstr+0xd/0x10<br /> ? local_clock_noinstr+0x3e/0x100<br /> ? __lock_acquire+0xd90/0xe30<br /> ? sched_clock_noinstr+0xd/0x10<br /> ? local_clock_noinstr+0x3e/0x100<br /> ? __create_object+0x66/0x100<br /> ? local_clock+0x1c/0x60<br /> ? __create_object+0x66/0x100<br /> ? parameq+0x1b/0x90<br /> ? parse_one+0x6d/0x1d0<br /> ? parse_args+0xd7/0x1f0<br /> ? do_initcall_level+0x180/0x180<br /> do_initcall_level+0xb0/0x180<br /> do_initcalls+0x60/0xa0<br /> ? kernel_init+0x1f/0x1d0<br /> do_basic_setup+0x41/0x50<br /> kernel_init_freeable+0x1ac/0x230<br /> ? rest_init+0x1f0/0x1f0<br /> kernel_init+0x1f/0x1d0<br /> ? rest_init+0x1f0/0x1f0<br /> ret_from_fork+0x3d/0x50<br /> ? rest_init+0x1f0/0x1f0<br /> ret_from_fork_asm+0x11/0x20<br /> <br /> Modules linked in:<br /> CR2: 00000000000000f0<br /> ---[ end trace 0000000000000000 ]---<br /> RIP: 0010:__sev_snp_shutdown_locked+0x2e/0x150<br /> Code: 00 55 48 89 e5 41 57 41 56 41 54 53 48 83 ec 10 41 89 f7 49 89 fe 65 48 8b 04 25 28 00 00 00 48 89 45 d8 48 8b 05 6a 5a 7f 06 8b a0 f0 00 00 00 41 0f b6 9c 24 a2 00 00 00 48 83 fb 02 0f 83<br /> RSP: 0018:ffffb2ea4014b7b8 EFLAGS: 00010286<br /> RAX: 0000000000000000 RBX: ffff9e4acd2e0a28 RCX: 0000000000000000<br /> RDX: 0000000<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: Fix event leak upon exec and file release<br /> <br /> The perf pending task work is never waited upon the matching event<br /> release. In the case of a child event, released via free_event()<br /> directly, this can potentially result in a leaked event, such as in the<br /> following scenario that doesn&amp;#39;t even require a weak IRQ work<br /> implementation to trigger:<br /> <br /> schedule()<br /> prepare_task_switch()<br /> =======&gt; <br /> perf_event_overflow()<br /> event-&gt;pending_sigtrap = ...<br /> irq_work_queue(&amp;event-&gt;pending_irq)<br /> pending_sigtrap = 0;<br /> atomic_long_inc_not_zero(&amp;event-&gt;refcount)<br /> task_work_add(&amp;event-&gt;pending_task)<br /> finish_lock_switch()<br /> =======&gt; <br /> perf_pending_irq()<br /> //do nothing, rely on pending task work<br /> refcount, 1, 0) != 1)<br /> // event is leaked<br /> <br /> Similar scenarios can also happen with perf_event_remove_on_exec() or<br /> simply against concurrent perf_event_release().<br /> <br /> Fix this with synchonizing against the possibly remaining pending task<br /> work while freeing the event, just like is done with remaining pending<br /> IRQ work. This means that the pending task callback neither need nor<br /> should hold a reference to the event, preventing it from ever beeing<br /> freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: Fix event leak upon exit<br /> <br /> When a task is scheduled out, pending sigtrap deliveries are deferred<br /> to the target task upon resume to userspace via task_work.<br /> <br /> However failures while adding an event&amp;#39;s callback to the task_work<br /> engine are ignored. And since the last call for events exit happen<br /> after task work is eventually closed, there is a small window during<br /> which pending sigtrap can be queued though ignored, leaking the event<br /> refcount addition such as in the following scenario:<br /> <br /> TASK A<br /> -----<br /> <br /> do_exit()<br /> exit_task_work(tsk);<br /> <br /> <br /> perf_event_overflow()<br /> event-&gt;pending_sigtrap = pending_id;<br /> irq_work_queue(&amp;event-&gt;pending_irq);<br /> <br /> =========&gt; PREEMPTION: TASK A -&gt; TASK B<br /> event_sched_out()<br /> event-&gt;pending_sigtrap = 0;<br /> atomic_long_inc_not_zero(&amp;event-&gt;refcount)<br /> // FAILS: task work has exited<br /> task_work_add(&amp;event-&gt;pending_task)<br /> [...]<br /> <br /> perf_pending_irq()<br /> // early return: event-&gt;oncpu = -1<br /> <br /> [...]<br /> =========&gt; TASK B -&gt; TASK A<br /> perf_event_exit_task(tsk)<br /> perf_event_exit_event()<br /> free_event()<br /> WARN(atomic_long_cmpxchg(&amp;event-&gt;refcount, 1, 0) != 1)<br /> // leak event due to unexpected refcount == 2<br /> <br /> As a result the event is never released while the task exits.<br /> <br /> Fix this with appropriate task_work_add()&amp;#39;s error handling.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> devres: Fix memory leakage caused by driver API devm_free_percpu()<br /> <br /> It will cause memory leakage when use driver API devm_free_percpu()<br /> to free memory allocated by devm_alloc_percpu(), fixed by using<br /> devres_release() instead of devres_destroy() within devm_free_percpu().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vhost/vsock: always initialize seqpacket_allow<br /> <br /> There are two issues around seqpacket_allow:<br /> 1. seqpacket_allow is not initialized when socket is<br /> created. Thus if features are never set, it will be<br /> read uninitialized.<br /> 2. if VIRTIO_VSOCK_F_SEQPACKET is set and then cleared,<br /> then seqpacket_allow will not be cleared appropriately<br /> (existing apps I know about don&amp;#39;t usually do this but<br /> it&amp;#39;s legal and there&amp;#39;s no way to be sure no one relies<br /> on this).<br /> <br /> To fix:<br /> - initialize seqpacket_allow after allocation<br /> - set it unconditionally in set_features