Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: drop bad gso csum_start and offset in virtio_net_hdr<br /> <br /> Tighten csum_start and csum_offset checks in virtio_net_hdr_to_skb<br /> for GSO packets.<br /> <br /> The function already checks that a checksum requested with<br /> VIRTIO_NET_HDR_F_NEEDS_CSUM is in skb linear. But for GSO packets<br /> this might not hold for segs after segmentation.<br /> <br /> Syzkaller demonstrated to reach this warning in skb_checksum_help<br /> <br /> offset = skb_checksum_start_offset(skb);<br /> ret = -EINVAL;<br /> if (WARN_ON_ONCE(offset &gt;= skb_headlen(skb)))<br /> <br /> By injecting a TSO packet:<br /> <br /> WARNING: CPU: 1 PID: 3539 at net/core/dev.c:3284 skb_checksum_help+0x3d0/0x5b0<br /> ip_do_fragment+0x209/0x1b20 net/ipv4/ip_output.c:774<br /> ip_finish_output_gso net/ipv4/ip_output.c:279 [inline]<br /> __ip_finish_output+0x2bd/0x4b0 net/ipv4/ip_output.c:301<br /> iptunnel_xmit+0x50c/0x930 net/ipv4/ip_tunnel_core.c:82<br /> ip_tunnel_xmit+0x2296/0x2c70 net/ipv4/ip_tunnel.c:813<br /> __gre_xmit net/ipv4/ip_gre.c:469 [inline]<br /> ipgre_xmit+0x759/0xa60 net/ipv4/ip_gre.c:661<br /> __netdev_start_xmit include/linux/netdevice.h:4850 [inline]<br /> netdev_start_xmit include/linux/netdevice.h:4864 [inline]<br /> xmit_one net/core/dev.c:3595 [inline]<br /> dev_hard_start_xmit+0x261/0x8c0 net/core/dev.c:3611<br /> __dev_queue_xmit+0x1b97/0x3c90 net/core/dev.c:4261<br /> packet_snd net/packet/af_packet.c:3073 [inline]<br /> <br /> The geometry of the bad input packet at tcp_gso_segment:<br /> <br /> [ 52.003050][ T8403] skb len=12202 headroom=244 headlen=12093 tailroom=0<br /> [ 52.003050][ T8403] mac=(168,24) mac_len=24 net=(192,52) trans=244<br /> [ 52.003050][ T8403] shinfo(txflags=0 nr_frags=1 gso(size=1552 type=3 segs=0))<br /> [ 52.003050][ T8403] csum(0x60000c7 start=199 offset=1536<br /> ip_summed=3 complete_sw=0 valid=0 level=0)<br /> <br /> Mitigate with stricter input validation.<br /> <br /> csum_offset: for GSO packets, deduce the correct value from gso_type.<br /> This is already done for USO. Extend it to TSO. Let UFO be:<br /> udp[46]_ufo_fragment ignores these fields and always computes the<br /> checksum in software.<br /> <br /> csum_start: finding the real offset requires parsing to the transport<br /> header. Do not add a parser, use existing segmentation parsing. Thanks<br /> to SKB_GSO_DODGY, that also catches bad packets that are hw offloaded.<br /> Again test both TSO and USO. Do not test UFO for the above reason, and<br /> do not test UDP tunnel offload.<br /> <br /> GSO packet are almost always CHECKSUM_PARTIAL. USO packets may be<br /> CHECKSUM_NONE since commit 10154dbded6d6 ("udp: Allow GSO transmit<br /> from devices with no checksum offload"), but then still these fields<br /> are initialized correctly in udp4_hwcsum/udp6_hwcsum_outgoing. So no<br /> need to test for ip_summed == CHECKSUM_PARTIAL first.<br /> <br /> This revises an existing fix mentioned in the Fixes tag, which broke<br /> small packets with GSO offload, as detected by kselftests.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: xc2028: avoid use-after-free in load_firmware_cb()<br /> <br /> syzkaller reported use-after-free in load_firmware_cb() [1].<br /> The reason is because the module allocated a struct tuner in tuner_probe(),<br /> and then the module initialization failed, the struct tuner was released.<br /> A worker which created during module initialization accesses this struct<br /> tuner later, it caused use-after-free.<br /> <br /> The process is as follows:<br /> <br /> task-6504 worker_thread<br /> tuner_probe

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Add null checker before passing variables<br /> <br /> Checks null pointer before passing variables to functions.<br /> <br /> This fixes 3 NULL_RETURNS issues reported by Coverity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Add null checks for &amp;#39;stream&amp;#39; and &amp;#39;plane&amp;#39; before dereferencing<br /> <br /> This commit adds null checks for the &amp;#39;stream&amp;#39; and &amp;#39;plane&amp;#39; variables in<br /> the dcn30_apply_idle_power_optimizations function. These variables were<br /> previously assumed to be null at line 922, but they were used later in<br /> the code without checking if they were null. This could potentially lead<br /> to a null pointer dereference, which would cause a crash.<br /> <br /> The null checks ensure that &amp;#39;stream&amp;#39; and &amp;#39;plane&amp;#39; are not null before<br /> they are used, preventing potential crashes.<br /> <br /> Fixes the below static smatch checker:<br /> drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:938 dcn30_apply_idle_power_optimizations() error: we previously assumed &amp;#39;stream&amp;#39; could be null (see line 922)<br /> drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:940 dcn30_apply_idle_power_optimizations() error: we previously assumed &amp;#39;plane&amp;#39; could be null (see line 922)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/pm: Fix the null pointer dereference for vega10_hwmgr<br /> <br /> Check return value and conduct null pointer handling to avoid null pointer dereference.

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 /> drm/amd/display: Fix null pointer deref in dcn20_resource.c<br /> <br /> Fixes a hang thats triggered when MPV is run on a DCN401 dGPU:<br /> <br /> mpv --hwdec=vaapi --vo=gpu --hwdec-codecs=all<br /> <br /> and then enabling fullscreen playback (double click on the video)<br /> <br /> The following calltrace will be seen:<br /> <br /> [ 181.843989] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [ 181.843997] #PF: supervisor instruction fetch in kernel mode<br /> [ 181.844003] #PF: error_code(0x0010) - not-present page<br /> [ 181.844009] PGD 0 P4D 0<br /> [ 181.844020] Oops: 0010 [#1] PREEMPT SMP NOPTI<br /> [ 181.844028] CPU: 6 PID: 1892 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu<br /> [ 181.844038] Hardware name: System manufacturer System Product Name/CROSSHAIR VI HERO, BIOS 6302 10/23/2018<br /> [ 181.844044] RIP: 0010:0x0<br /> [ 181.844079] Code: Unable to access opcode bytes at 0xffffffffffffffd6.<br /> [ 181.844084] RSP: 0018:ffffb593c2b8f7b0 EFLAGS: 00010246<br /> [ 181.844093] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000004<br /> [ 181.844099] RDX: ffffb593c2b8f804 RSI: ffffb593c2b8f7e0 RDI: ffff9e3c8e758400<br /> [ 181.844105] RBP: ffffb593c2b8f7b8 R08: ffffb593c2b8f9c8 R09: ffffb593c2b8f96c<br /> [ 181.844110] R10: 0000000000000000 R11: 0000000000000000 R12: ffffb593c2b8f9c8<br /> [ 181.844115] R13: 0000000000000001 R14: ffff9e3c88000000 R15: 0000000000000005<br /> [ 181.844121] FS: 00007c6e323bb5c0(0000) GS:ffff9e3f85f80000(0000) knlGS:0000000000000000<br /> [ 181.844128] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 181.844134] CR2: ffffffffffffffd6 CR3: 0000000140fbe000 CR4: 00000000003506e0<br /> [ 181.844141] Call Trace:<br /> [ 181.844146] <br /> [ 181.844153] ? show_regs+0x6d/0x80<br /> [ 181.844167] ? __die+0x24/0x80<br /> [ 181.844179] ? page_fault_oops+0x99/0x1b0<br /> [ 181.844192] ? do_user_addr_fault+0x31d/0x6b0<br /> [ 181.844204] ? exc_page_fault+0x83/0x1b0<br /> [ 181.844216] ? asm_exc_page_fault+0x27/0x30<br /> [ 181.844237] dcn20_get_dcc_compression_cap+0x23/0x30 [amdgpu]<br /> [ 181.845115] amdgpu_dm_plane_validate_dcc.constprop.0+0xe5/0x180 [amdgpu]<br /> [ 181.845985] amdgpu_dm_plane_fill_plane_buffer_attributes+0x300/0x580 [amdgpu]<br /> [ 181.846848] fill_dc_plane_info_and_addr+0x258/0x350 [amdgpu]<br /> [ 181.847734] fill_dc_plane_attributes+0x162/0x350 [amdgpu]<br /> [ 181.848748] dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu]<br /> [ 181.849791] ? dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu]<br /> [ 181.850840] amdgpu_dm_atomic_check+0xdfe/0x1760 [amdgpu]

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 /> drm/amd/display: Add null check in resource_log_pipe_topology_update<br /> <br /> [WHY]<br /> When switching from "Extend" to "Second Display Only" we sometimes<br /> call resource_get_otg_master_for_stream on a stream for the eDP,<br /> which is disconnected. This leads to a null pointer dereference.<br /> <br /> [HOW]<br /> Added a null check in dc_resource.c/resource_log_pipe_topology_update.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/tcp: Disable TCP-AO static key after RCU grace period<br /> <br /> The lifetime of TCP-AO static_key is the same as the last<br /> tcp_ao_info. On the socket destruction tcp_ao_info ceases to be<br /> with RCU grace period, while tcp-ao static branch is currently deferred<br /> destructed. The static key definition is<br /> : DEFINE_STATIC_KEY_DEFERRED_FALSE(tcp_ao_needed, HZ);<br /> <br /> which means that if RCU grace period is delayed by more than a second<br /> and tcp_ao_needed is in the process of disablement, other CPUs may<br /> yet see tcp_ao_info which atent dead, but soon-to-be.<br /> And that breaks the assumption of static_key_fast_inc_not_disabled().<br /> <br /> See the comment near the definition:<br /> &gt; * The caller must make sure that the static key can&amp;#39;t get disabled while<br /> &gt; * in this function. It doesn&amp;#39;t patch jump labels, only adds a user to<br /> &gt; * an already enabled static key.<br /> <br /> Originally it was introduced in commit eb8c507296f6 ("jump_label:<br /> Prevent key-&gt;enabled int overflow"), which is needed for the atomic<br /> contexts, one of which would be the creation of a full socket from a<br /> request socket. In that atomic context, it&amp;#39;s known by the presence<br /> of the key (md5/ao) that the static branch is already enabled.<br /> So, the ref counter for that static branch is just incremented<br /> instead of holding the proper mutex.<br /> static_key_fast_inc_not_disabled() is just a helper for such usage<br /> case. But it must not be used if the static branch could get disabled<br /> in parallel as it&amp;#39;s not protected by jump_label_mutex and as a result,<br /> races with jump_label_update() implementation details.<br /> <br /> Happened on netdev test-bot[1], so not a theoretical issue:<br /> <br /> [] jump_label: Fatal kernel bug, unexpected op at tcp_inbound_hash+0x1a7/0x870 [ffffffffa8c4e9b7] (eb 50 0f 1f 44 != 66 90 0f 1f 00)) size:2 type:1<br /> [] ------------[ cut here ]------------<br /> [] kernel BUG at arch/x86/kernel/jump_label.c:73!<br /> [] Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> [] CPU: 3 PID: 243 Comm: kworker/3:3 Not tainted 6.10.0-virtme #1<br /> [] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> [] Workqueue: events jump_label_update_timeout<br /> [] RIP: 0010:__jump_label_patch+0x2f6/0x350<br /> ...<br /> [] Call Trace:<br /> [] <br /> [] arch_jump_label_transform_queue+0x6c/0x110<br /> [] __jump_label_update+0xef/0x350<br /> [] __static_key_slow_dec_cpuslocked.part.0+0x3c/0x60<br /> [] jump_label_update_timeout+0x2c/0x40<br /> [] process_one_work+0xe3b/0x1670<br /> [] worker_thread+0x587/0xce0<br /> [] kthread+0x28a/0x350<br /> [] ret_from_fork+0x31/0x70<br /> [] ret_from_fork_asm+0x1a/0x30<br /> [] <br /> [] Modules linked in: veth<br /> [] ---[ end trace 0000000000000000 ]---<br /> [] RIP: 0010:__jump_label_patch+0x2f6/0x350<br /> <br /> [1]: https://netdev-3.bots.linux.dev/vmksft-tcp-ao-dbg/results/696681/5-connect-deny-ipv6/stderr

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: list_lru: fix UAF for memory cgroup<br /> <br /> The mem_cgroup_from_slab_obj() is supposed to be called under rcu lock or<br /> cgroup_mutex or others which could prevent returned memcg from being<br /> freed. Fix it by adding missing rcu read lock.<br /> <br /> Found by code inspection.<br /> <br /> [songmuchun@bytedance.com: only grab rcu lock when necessary, per Vlastimil]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> padata: Fix possible divide-by-0 panic in padata_mt_helper()<br /> <br /> We are hit with a not easily reproducible divide-by-0 panic in padata.c at<br /> bootup time.<br /> <br /> [ 10.017908] Oops: divide error: 0000 1 PREEMPT SMP NOPTI<br /> [ 10.017908] CPU: 26 PID: 2627 Comm: kworker/u1666:1 Not tainted 6.10.0-15.el10.x86_64 #1<br /> [ 10.017908] Hardware name: Lenovo ThinkSystem SR950 [7X12CTO1WW]/[7X12CTO1WW], BIOS [PSE140J-2.30] 07/20/2021<br /> [ 10.017908] Workqueue: events_unbound padata_mt_helper<br /> [ 10.017908] RIP: 0010:padata_mt_helper+0x39/0xb0<br /> :<br /> [ 10.017963] Call Trace:<br /> [ 10.017968] <br /> [ 10.018004] ? padata_mt_helper+0x39/0xb0<br /> [ 10.018084] process_one_work+0x174/0x330<br /> [ 10.018093] worker_thread+0x266/0x3a0<br /> [ 10.018111] kthread+0xcf/0x100<br /> [ 10.018124] ret_from_fork+0x31/0x50<br /> [ 10.018138] ret_from_fork_asm+0x1a/0x30<br /> [ 10.018147] <br /> <br /> Looking at the padata_mt_helper() function, the only way a divide-by-0<br /> panic can happen is when ps-&gt;chunk_size is 0. The way that chunk_size is<br /> initialized in padata_do_multithreaded(), chunk_size can be 0 when the<br /> min_chunk in the passed-in padata_mt_job structure is 0.<br /> <br /> Fix this divide-by-0 panic by making sure that chunk_size will be at least<br /> 1 no matter what the input parameters are.