Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix buffer overflow when parsing NFS reparse points<br /> <br /> ReparseDataLength is sum of the InodeType size and DataBuffer size.<br /> So to get DataBuffer size it is needed to subtract InodeType&amp;#39;s size from<br /> ReparseDataLength.<br /> <br /> Function cifs_strndup_from_utf16() is currentlly accessing buf-&gt;DataBuffer<br /> at position after the end of the buffer because it does not subtract<br /> InodeType size from the length. Fix this problem and correctly subtract<br /> variable len.<br /> <br /> Member InodeType is present only when reparse buffer is large enough. Check<br /> for ReparseDataLength before accessing InodeType to prevent another invalid<br /> memory access.<br /> <br /> Major and minor rdev values are present also only when reparse buffer is<br /> large enough. Check for reparse buffer size before calling reparse_mkdev().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: fix double free issue during amdgpu module unload<br /> <br /> Flexible endpoints use DIGs from available inflexible endpoints,<br /> so only the encoders of inflexible links need to be freed.<br /> Otherwise, a double free issue may occur when unloading the<br /> amdgpu module.<br /> <br /> [ 279.190523] RIP: 0010:__slab_free+0x152/0x2f0<br /> [ 279.190577] Call Trace:<br /> [ 279.190580] <br /> [ 279.190582] ? show_regs+0x69/0x80<br /> [ 279.190590] ? die+0x3b/0x90<br /> [ 279.190595] ? do_trap+0xc8/0xe0<br /> [ 279.190601] ? do_error_trap+0x73/0xa0<br /> [ 279.190605] ? __slab_free+0x152/0x2f0<br /> [ 279.190609] ? exc_invalid_op+0x56/0x70<br /> [ 279.190616] ? __slab_free+0x152/0x2f0<br /> [ 279.190642] ? asm_exc_invalid_op+0x1f/0x30<br /> [ 279.190648] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu]<br /> [ 279.191096] ? __slab_free+0x152/0x2f0<br /> [ 279.191102] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu]<br /> [ 279.191469] kfree+0x260/0x2b0<br /> [ 279.191474] dcn10_link_encoder_destroy+0x19/0x30 [amdgpu]<br /> [ 279.191821] link_destroy+0xd7/0x130 [amdgpu]<br /> [ 279.192248] dc_destruct+0x90/0x270 [amdgpu]<br /> [ 279.192666] dc_destroy+0x19/0x40 [amdgpu]<br /> [ 279.193020] amdgpu_dm_fini+0x16e/0x200 [amdgpu]<br /> [ 279.193432] dm_hw_fini+0x26/0x40 [amdgpu]<br /> [ 279.193795] amdgpu_device_fini_hw+0x24c/0x400 [amdgpu]<br /> [ 279.194108] amdgpu_driver_unload_kms+0x4f/0x70 [amdgpu]<br /> [ 279.194436] amdgpu_pci_remove+0x40/0x80 [amdgpu]<br /> [ 279.194632] pci_device_remove+0x3a/0xa0<br /> [ 279.194638] device_remove+0x40/0x70<br /> [ 279.194642] device_release_driver_internal+0x1ad/0x210<br /> [ 279.194647] driver_detach+0x4e/0xa0<br /> [ 279.194650] bus_remove_driver+0x6f/0xf0<br /> [ 279.194653] driver_unregister+0x33/0x60<br /> [ 279.194657] pci_unregister_driver+0x44/0x90<br /> [ 279.194662] amdgpu_exit+0x19/0x1f0 [amdgpu]<br /> [ 279.194939] __do_sys_delete_module.isra.0+0x198/0x2f0<br /> [ 279.194946] __x64_sys_delete_module+0x16/0x20<br /> [ 279.194950] do_syscall_64+0x58/0x120<br /> [ 279.194954] entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> [ 279.194980]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: x86-android-tablets: Fix use after free on platform_device_register() errors<br /> <br /> x86_android_tablet_remove() frees the pdevs[] array, so it should not<br /> be used after calling x86_android_tablet_remove().<br /> <br /> When platform_device_register() fails, store the pdevs[x] PTR_ERR() value<br /> into the local ret variable before calling x86_android_tablet_remove()<br /> to avoid using pdevs[] after it has been freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer<br /> <br /> Pass pointer reference to amdgpu_bo_unref to clear the correct pointer,<br /> otherwise amdgpu_bo_unref clear the local variable, the original pointer<br /> not set to NULL, this could cause use-after-free bug.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/stm: Avoid use-after-free issues with crtc and plane<br /> <br /> ltdc_load() calls functions drm_crtc_init_with_planes(),<br /> drm_universal_plane_init() and drm_encoder_init(). These functions<br /> should not be called with parameters allocated with devm_kzalloc()<br /> to avoid use-after-free issues [1].<br /> <br /> Use allocations managed by the DRM framework.<br /> <br /> Found by Linux Verification Center (linuxtesting.org).<br /> <br /> [1]<br /> https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: lantiq_etop: fix memory disclosure<br /> <br /> When applying padding, the buffer is not zeroed, which results in memory<br /> disclosure. The mentioned data is observed on the wire. This patch uses<br /> skb_put_padto() to pad Ethernet frames properly. The mentioned function<br /> zeroes the expanded buffer.<br /> <br /> In case the packet cannot be padded it is silently dropped. Statistics<br /> are also not incremented. This driver does not support statistics in the<br /> old 32-bit format or the new 64-bit format. These will be added in the<br /> future. In its current form, the patch should be easily backported to<br /> stable versions.<br /> <br /> Ethernet MACs on Amazon-SE and Danube cannot do padding of the packets<br /> in hardware, so software padding must be applied.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: improve shutdown sequence<br /> <br /> Alexander Sverdlin presents 2 problems during shutdown with the<br /> lan9303 driver. One is specific to lan9303 and the other just happens<br /> to reproduce there.<br /> <br /> The first problem is that lan9303 is unique among DSA drivers in that it<br /> calls dev_get_drvdata() at "arbitrary runtime" (not probe, not shutdown,<br /> not remove):<br /> <br /> phy_state_machine()<br /> -&gt; ...<br /> -&gt; dsa_user_phy_read()<br /> -&gt; ds-&gt;ops-&gt;phy_read()<br /> -&gt; lan9303_phy_read()<br /> -&gt; chip-&gt;ops-&gt;phy_read()<br /> -&gt; lan9303_mdio_phy_read()<br /> -&gt; dev_get_drvdata()<br /> <br /> But we never stop the phy_state_machine(), so it may continue to run<br /> after dsa_switch_shutdown(). Our common pattern in all DSA drivers is<br /> to set drvdata to NULL to suppress the remove() method that may come<br /> afterwards. But in this case it will result in an NPD.<br /> <br /> The second problem is that the way in which we set<br /> dp-&gt;conduit-&gt;dsa_ptr = NULL; is concurrent with receive packet<br /> processing. dsa_switch_rcv() checks once whether dev-&gt;dsa_ptr is NULL,<br /> but afterwards, rather than continuing to use that non-NULL value,<br /> dev-&gt;dsa_ptr is dereferenced again and again without NULL checks:<br /> dsa_conduit_find_user() and many other places. In between dereferences,<br /> there is no locking to ensure that what was valid once continues to be<br /> valid.<br /> <br /> Both problems have the common aspect that closing the conduit interface<br /> solves them.<br /> <br /> In the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWN<br /> event in dsa_user_netdevice_event() which closes user ports as well.<br /> dsa_port_disable_rt() calls phylink_stop(), which synchronously stops<br /> the phylink state machine, and ds-&gt;ops-&gt;phy_read() will thus no longer<br /> call into the driver after this point.<br /> <br /> In the second case, dev_close(conduit) should do this, as per<br /> Documentation/networking/driver.rst:<br /> <br /> | Quiescence<br /> | ----------<br /> |<br /> | After the ndo_stop routine has been called, the hardware must<br /> | not receive or transmit any data. All in flight packets must<br /> | be aborted. If necessary, poll or wait for completion of<br /> | any reset commands.<br /> <br /> So it should be sufficient to ensure that later, when we zeroize<br /> conduit-&gt;dsa_ptr, there will be no concurrent dsa_switch_rcv() call<br /> on this conduit.<br /> <br /> The addition of the netif_device_detach() function is to ensure that<br /> ioctls, rtnetlinks and ethtool requests on the user ports no longer<br /> propagate down to the driver - we&amp;#39;re no longer prepared to handle them.<br /> <br /> The race condition actually did not exist when commit 0650bf52b31f<br /> ("net: dsa: be compatible with masters which unregister on shutdown")<br /> first introduced dsa_switch_shutdown(). It was created later, when we<br /> stopped unregistering the user interfaces from a bad spot, and we just<br /> replaced that sequence with a racy zeroization of conduit-&gt;dsa_ptr<br /> (one which doesn&amp;#39;t ensure that the interfaces aren&amp;#39;t up).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Increase array size of dummy_boolean<br /> <br /> [WHY]<br /> dml2_core_shared_mode_support and dml_core_mode_support access the third<br /> element of dummy_boolean, i.e. hw_debug5 = &amp;s-&gt;dummy_boolean[2], when<br /> dummy_boolean has size of 2. Any assignment to hw_debug5 causes an<br /> OVERRUN.<br /> <br /> [HOW]<br /> Increase dummy_boolean&amp;#39;s array size to 3.<br /> <br /> This fixes 2 OVERRUN issues reported by Coverity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Deallocate DML memory if allocation fails<br /> <br /> [Why]<br /> When DC state create DML memory allocation fails, memory is not<br /> deallocated subsequently, resulting in uninitialized structure<br /> that is not NULL.<br /> <br /> [How]<br /> Deallocate memory if DML memory allocation fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing/timerlat: Drop interface_lock in stop_kthread()<br /> <br /> stop_kthread() is the offline callback for "trace/osnoise:online", since<br /> commit 5bfbcd1ee57b ("tracing/timerlat: Add interface_lock around clearing<br /> of kthread in stop_kthread()"), the following ABBA deadlock scenario is<br /> introduced:<br /> <br /> T1 | T2 [BP] | T3 [AP]<br /> osnoise_hotplug_workfn() | work_for_cpu_fn() | cpuhp_thread_fun()<br /> | _cpu_down() | osnoise_cpu_die()<br /> mutex_lock(&amp;interface_lock) | | stop_kthread()<br /> | cpus_write_lock() | mutex_lock(&amp;interface_lock)<br /> cpus_read_lock() | cpuhp_kick_ap() |<br /> <br /> As the interface_lock here in just for protecting the "kthread" field of<br /> the osn_var, use xchg() instead to fix this issue. Also use<br /> for_each_online_cpu() back in stop_per_cpu_kthreads() as it can take<br /> cpu_read_lock() again.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: gso: fix tcp fraglist segmentation after pull from frag_list<br /> <br /> Detect tcp gso fraglist skbs with corrupted geometry (see below) and<br /> pass these to skb_segment instead of skb_segment_list, as the first<br /> can segment them correctly.<br /> <br /> Valid SKB_GSO_FRAGLIST skbs<br /> - consist of two or more segments<br /> - the head_skb holds the protocol headers plus first gso_size<br /> - one or more frag_list skbs hold exactly one segment<br /> - all but the last must be gso_size<br /> <br /> Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can<br /> modify these skbs, breaking these invariants.<br /> <br /> In extreme cases they pull all data into skb linear. For TCP, this<br /> causes a NULL ptr deref in __tcpv4_gso_segment_list_csum at<br /> tcp_hdr(seg-&gt;next).<br /> <br /> Detect invalid geometry due to pull, by checking head_skb size.<br /> Don&amp;#39;t just drop, as this may blackhole a destination. Convert to be<br /> able to pass to regular skb_segment.<br /> <br /> Approach and description based on a patch by Willem de Bruijn.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vrf: revert "vrf: Remove unnecessary RCU-bh critical section"<br /> <br /> This reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853.<br /> <br /> dev_queue_xmit_nit is expected to be called with BH disabled.<br /> __dev_queue_xmit has the following:<br /> <br /> /* Disable soft irqs for various locks below. Also<br /> * stops preemption for RCU.<br /> */<br /> rcu_read_lock_bh();<br /> <br /> VRF must follow this invariant. The referenced commit removed this<br /> protection. Which triggered a lockdep warning:<br /> <br /> ================================<br /> WARNING: inconsistent lock state<br /> 6.11.0 #1 Tainted: G W<br /> --------------------------------<br /> inconsistent {IN-SOFTIRQ-W} -&gt; {SOFTIRQ-ON-W} usage.<br /> btserver/134819 [HC0[0]:SC0[0]:HE1:SE1] takes:<br /> ffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, at: tpacket_rcv+0x863/0x3b30<br /> {IN-SOFTIRQ-W} state was registered at:<br /> lock_acquire+0x19a/0x4f0<br /> _raw_spin_lock+0x27/0x40<br /> packet_rcv+0xa33/0x1320<br /> __netif_receive_skb_core.constprop.0+0xcb0/0x3a90<br /> __netif_receive_skb_list_core+0x2c9/0x890<br /> netif_receive_skb_list_internal+0x610/0xcc0<br /> [...]<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> <br /> CPU0<br /> ----<br /> lock(rlock-AF_PACKET);<br /> <br /> lock(rlock-AF_PACKET);<br /> <br /> *** DEADLOCK ***<br /> <br /> Call Trace:<br /> <br /> dump_stack_lvl+0x73/0xa0<br /> mark_lock+0x102e/0x16b0<br /> __lock_acquire+0x9ae/0x6170<br /> lock_acquire+0x19a/0x4f0<br /> _raw_spin_lock+0x27/0x40<br /> tpacket_rcv+0x863/0x3b30<br /> dev_queue_xmit_nit+0x709/0xa40<br /> vrf_finish_direct+0x26e/0x340 [vrf]<br /> vrf_l3_out+0x5f4/0xe80 [vrf]<br /> __ip_local_out+0x51e/0x7a0<br /> [...]