Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: mv88e6xxx: Fix refcount leak in mv88e6xxx_mdios_register<br /> <br /> of_get_child_by_name() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when done.<br /> <br /> mv88e6xxx_mdio_register() pass the device node to of_mdiobus_register().<br /> We don&amp;#39;t need the device node after it.<br /> <br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: mtk_eth_soc: out of bounds read in mtk_hwlro_get_fdir_entry()<br /> <br /> The "fsp-&gt;location" variable comes from user via ethtool_get_rxnfc().<br /> Check that it is valid to prevent an out of bounds read.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> amt: fix possible memory leak in amt_rcv()<br /> <br /> If an amt receives packets and it finds socket.<br /> If it can&amp;#39;t find a socket, it should free a received skb.<br /> But it doesn&amp;#39;t.<br /> So, a memory leak would possibly occur.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: dmi-sysfs: Fix memory leak in dmi_sysfs_register_handle<br /> <br /> kobject_init_and_add() takes reference even when it fails.<br /> According to the doc of kobject_init_and_add()<br /> <br /> If this function returns an error, kobject_put() must be called to<br /> properly clean up the memory associated with the object.<br /> <br /> Fix this issue by calling kobject_put().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> driver core: fix deadlock in __device_attach<br /> <br /> In __device_attach function, The lock holding logic is as follows:<br /> ...<br /> __device_attach<br /> device_lock(dev) // get lock dev<br /> async_schedule_dev(__device_attach_async_helper, dev); // func<br /> async_schedule_node<br /> async_schedule_node_domain(func)<br /> entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);<br /> /* when fail or work limit, sync to execute func, but<br /> __device_attach_async_helper will get lock dev as<br /> well, which will lead to A-A deadlock. */<br /> if (!entry || atomic_read(&amp;entry_count) &gt; MAX_WORK) {<br /> func;<br /> else<br /> queue_work_node(node, system_unbound_wq, &amp;entry-&gt;work)<br /> device_unlock(dev)<br /> <br /> As shown above, when it is allowed to do async probes, because of<br /> out of memory or work limit, async work is not allowed, to do<br /> sync execute instead. it will lead to A-A deadlock because of<br /> __device_attach_async_helper getting lock dev.<br /> <br /> To fix the deadlock, move the async_schedule_dev outside device_lock,<br /> as we can see, in async_schedule_node_domain, the parameter of<br /> queue_work_node is system_unbound_wq, so it can accept concurrent<br /> operations. which will also not change the code logic, and will<br /> not lead to deadlock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: tcp_rtx_synack() can be called from process context<br /> <br /> Laurent reported the enclosed report [1]<br /> <br /> This bug triggers with following coditions:<br /> <br /> 0) Kernel built with CONFIG_DEBUG_PREEMPT=y<br /> <br /> 1) A new passive FastOpen TCP socket is created.<br /> This FO socket waits for an ACK coming from client to be a complete<br /> ESTABLISHED one.<br /> 2) A socket operation on this socket goes through lock_sock()<br /> release_sock() dance.<br /> 3) While the socket is owned by the user in step 2),<br /> a retransmit of the SYN is received and stored in socket backlog.<br /> 4) At release_sock() time, the socket backlog is processed while<br /> in process context.<br /> 5) A SYNACK packet is cooked in response of the SYN retransmit.<br /> 6) -&gt; tcp_rtx_synack() is called in process context.<br /> <br /> Before blamed commit, tcp_rtx_synack() was always called from BH handler,<br /> from a timer handler.<br /> <br /> Fix this by using TCP_INC_STATS() &amp; NET_INC_STATS()<br /> which do not assume caller is in non preemptible context.<br /> <br /> [1]<br /> BUG: using __this_cpu_add() in preemptible [00000000] code: epollpep/2180<br /> caller is tcp_rtx_synack.part.0+0x36/0xc0<br /> CPU: 10 PID: 2180 Comm: epollpep Tainted: G OE 5.16.0-0.bpo.4-amd64 #1 Debian 5.16.12-1~bpo11+1<br /> Hardware name: Supermicro SYS-5039MC-H8TRF/X11SCD-F, BIOS 1.7 11/23/2021<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x48/0x5e<br /> check_preemption_disabled+0xde/0xe0<br /> tcp_rtx_synack.part.0+0x36/0xc0<br /> tcp_rtx_synack+0x8d/0xa0<br /> ? kmem_cache_alloc+0x2e0/0x3e0<br /> ? apparmor_file_alloc_security+0x3b/0x1f0<br /> inet_rtx_syn_ack+0x16/0x30<br /> tcp_check_req+0x367/0x610<br /> tcp_rcv_state_process+0x91/0xf60<br /> ? get_nohz_timer_target+0x18/0x1a0<br /> ? lock_timer_base+0x61/0x80<br /> ? preempt_count_add+0x68/0xa0<br /> tcp_v4_do_rcv+0xbd/0x270<br /> __release_sock+0x6d/0xb0<br /> release_sock+0x2b/0x90<br /> sock_setsockopt+0x138/0x1140<br /> ? __sys_getsockname+0x7e/0xc0<br /> ? aa_sk_perm+0x3e/0x1a0<br /> __sys_setsockopt+0x198/0x1e0<br /> __x64_sys_setsockopt+0x21/0x30<br /> do_syscall_64+0x38/0xc0<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> watchdog: ts4800_wdt: Fix refcount leak in ts4800_wdt_probe<br /> <br /> of_parse_phandle() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when done.<br /> Add missing of_node_put() in some error paths.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/papr_scm: don&amp;#39;t requests stats with &amp;#39;0&amp;#39; sized stats buffer<br /> <br /> Sachin reported [1] that on a POWER-10 lpar he is seeing a kernel panic being<br /> reported with vPMEM when papr_scm probe is being called. The panic is of the<br /> form below and is observed only with following option disabled(profile) for the<br /> said LPAR &amp;#39;Enable Performance Information Collection&amp;#39; in the HMC:<br /> <br /> Kernel attempted to write user page (1c) - exploit attempt? (uid: 0)<br /> BUG: Kernel NULL pointer dereference on write at 0x0000001c<br /> Faulting instruction address: 0xc008000001b90844<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> <br /> NIP [c008000001b90844] drc_pmem_query_stats+0x5c/0x270 [papr_scm]<br /> LR [c008000001b92794] papr_scm_probe+0x2ac/0x6ec [papr_scm]<br /> Call Trace:<br /> 0xc00000000941bca0 (unreliable)<br /> papr_scm_probe+0x2ac/0x6ec [papr_scm]<br /> platform_probe+0x98/0x150<br /> really_probe+0xfc/0x510<br /> __driver_probe_device+0x17c/0x230<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> Kernel panic - not syncing: Fatal exception<br /> <br /> On investigation looks like this panic was caused due to a &amp;#39;stat_buffer&amp;#39; of<br /> size==0 being provided to drc_pmem_query_stats() to fetch all performance<br /> stats-ids of an NVDIMM. However drc_pmem_query_stats() shouldn&amp;#39;t have been called<br /> since the vPMEM NVDIMM doesn&amp;#39;t support and performance stat-id&amp;#39;s. This was caused<br /> due to missing check for &amp;#39;p-&gt;stat_buffer_len&amp;#39; at the beginning of<br /> papr_scm_pmu_check_events() which indicates that the NVDIMM doesn&amp;#39;t support<br /> performance-stats.<br /> <br /> Fix this by introducing the check for &amp;#39;p-&gt;stat_buffer_len&amp;#39; at the beginning of<br /> papr_scm_pmu_check_events().<br /> <br /> [1] https://lore.kernel.org/all/6B3A522A-6A5F-4CC9-B268-0C63AA6E07D3@linux.ibm.com

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ata: pata_octeon_cf: Fix refcount leak in octeon_cf_probe<br /> <br /> of_find_device_by_node() takes reference, we should use put_device()<br /> to release it when not need anymore.<br /> Add missing put_device() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> SUNRPC: Trap RDMA segment overflows<br /> <br /> Prevent svc_rdma_build_writes() from walking off the end of a Write<br /> chunk&amp;#39;s segment array. Caught with KASAN.<br /> <br /> The test that this fix replaces is invalid, and might have been left<br /> over from an earlier prototype of the PCL work.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> efi: Do not import certificates from UEFI Secure Boot for T2 Macs<br /> <br /> On Apple T2 Macs, when Linux attempts to read the db and dbx efi variables<br /> at early boot to load UEFI Secure Boot certificates, a page fault occurs<br /> in Apple firmware code and EFI runtime services are disabled with the<br /> following logs:<br /> <br /> [Firmware Bug]: Page fault caused by firmware at PA: 0xffffb1edc0068000<br /> WARNING: CPU: 3 PID: 104 at arch/x86/platform/efi/quirks.c:735 efi_crash_gracefully_on_page_fault+0x50/0xf0<br /> (Removed some logs from here)<br /> Call Trace:<br /> <br /> page_fault_oops+0x4f/0x2c0<br /> ? search_bpf_extables+0x6b/0x80<br /> ? search_module_extables+0x50/0x80<br /> ? search_exception_tables+0x5b/0x60<br /> kernelmode_fixup_or_oops+0x9e/0x110<br /> __bad_area_nosemaphore+0x155/0x190<br /> bad_area_nosemaphore+0x16/0x20<br /> do_kern_addr_fault+0x8c/0xa0<br /> exc_page_fault+0xd8/0x180<br /> asm_exc_page_fault+0x1e/0x30<br /> (Removed some logs from here)<br /> ? __efi_call+0x28/0x30<br /> ? switch_mm+0x20/0x30<br /> ? efi_call_rts+0x19a/0x8e0<br /> ? process_one_work+0x222/0x3f0<br /> ? worker_thread+0x4a/0x3d0<br /> ? kthread+0x17a/0x1a0<br /> ? process_one_work+0x3f0/0x3f0<br /> ? set_kthread_struct+0x40/0x40<br /> ? ret_from_fork+0x22/0x30<br /> <br /> ---[ end trace 1f82023595a5927f ]---<br /> efi: Froze efi_rts_wq and disabled EFI Runtime Services<br /> integrity: Couldn&amp;#39;t get size: 0x8000000000000015<br /> integrity: MODSIGN: Couldn&amp;#39;t get UEFI db list<br /> efi: EFI Runtime Services are disabled!<br /> integrity: Couldn&amp;#39;t get size: 0x8000000000000015<br /> integrity: Couldn&amp;#39;t get UEFI dbx list<br /> integrity: Couldn&amp;#39;t get size: 0x8000000000000015<br /> integrity: Couldn&amp;#39;t get mokx list<br /> integrity: Couldn&amp;#39;t get size: 0x80000000<br /> <br /> So we avoid reading these UEFI variables and thus prevent the crash.