Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> coresight: holding cscfg_csdev_lock while removing cscfg from csdev<br /> <br /> There&amp;#39;ll be possible race scenario for coresight config:<br /> <br /> CPU0 CPU1<br /> (perf enable) load module<br /> cscfg_load_config_sets()<br /> activate config. // sysfs<br /> (sys_active_cnt == 1)<br /> ...<br /> cscfg_csdev_enable_active_config()<br /> lock(csdev-&gt;cscfg_csdev_lock)<br /> deactivate config // sysfs<br /> (sys_activec_cnt == 0)<br /> cscfg_unload_config_sets()<br /> cscfg_remove_owned_csdev_configs()<br /> // here load config activate by CPU1<br /> unlock(csdev-&gt;cscfg_csdev_lock)<br /> <br /> iterating config_csdev_list could be raced with config_csdev_list&amp;#39;s<br /> entry delete.<br /> <br /> To resolve this race , hold csdev-&gt;cscfg_csdev_lock() while<br /> cscfg_remove_owned_csdev_configs()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: ad4851: fix ad4858 chan pointer handling<br /> <br /> The pointer returned from ad4851_parse_channels_common() is incremented<br /> internally as each channel is populated. In ad4858_parse_channels(),<br /> the same pointer was further incremented while setting ext_scan_type<br /> fields for each channel. This resulted in indio_dev-&gt;channels being set<br /> to a pointer past the end of the allocated array, potentially causing<br /> memory corruption or undefined behavior.<br /> <br /> Fix this by iterating over the channels using an explicit index instead<br /> of incrementing the pointer. This preserves the original base pointer<br /> and ensures all channel metadata is set correctly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: acpi: Prevent null pointer dereference in usb_acpi_add_usb4_devlink()<br /> <br /> As demonstrated by the fix for update_port_device_state,<br /> commit 12783c0b9e2c ("usb: core: Prevent null pointer dereference in update_port_device_state"),<br /> usb_hub_to_struct_hub() can return NULL in certain scenarios,<br /> such as during hub driver unbind or teardown race conditions,<br /> even if the underlying usb_device structure exists.<br /> <br /> Plus, all other places that call usb_hub_to_struct_hub() in the same file<br /> do check for NULL return values.<br /> <br /> If usb_hub_to_struct_hub() returns NULL, the subsequent access to<br /> hub-&gt;ports[udev-&gt;portnum - 1] will cause a null pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: Fix potential null-ptr-deref in mlb_usio_probe()<br /> <br /> devm_ioremap() can return NULL on error. Currently, mlb_usio_probe()<br /> does not check for this case, which could result in a NULL pointer<br /> dereference.<br /> <br /> Add NULL check after devm_ioremap() to prevent this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_set_pipapo_avx2: fix initial map fill<br /> <br /> If the first field doesn&amp;#39;t cover the entire start map, then we must zero<br /> out the remainder, else we leak those bits into the next match round map.<br /> <br /> The early fix was incomplete and did only fix up the generic C<br /> implementation.<br /> <br /> A followup patch adds a test case to nft_concat_range.sh.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mld: avoid panic on init failure<br /> <br /> In case of an error during init, in_hw_restart will be set, but it will<br /> never get cleared.<br /> Instead, we will retry to init again, and then we will act like we are in a<br /> restart when we are actually not.<br /> <br /> This causes (among others) to a NULL pointer dereference when canceling<br /> rx_omi::finished_work, that was not even initialized, because we thought<br /> that we are in hw_restart.<br /> <br /> Set in_hw_restart to true only if the fw is running, then we know that<br /> FW was loaded successfully and we are not going to the retry loop.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gve: add missing NULL check for gve_alloc_pending_packet() in TX DQO<br /> <br /> gve_alloc_pending_packet() can return NULL, but gve_tx_add_skb_dqo()<br /> did not check for this case before dereferencing the returned pointer.<br /> <br /> Add a missing NULL check to prevent a potential NULL pointer<br /> dereference when allocation fails.<br /> <br /> This improves robustness in low-memory scenarios.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: wwan: t7xx: Fix napi rx poll issue<br /> <br /> When driver handles the napi rx polling requests, the netdev might<br /> have been released by the dellink logic triggered by the disconnect<br /> operation on user plane. However, in the logic of processing skb in<br /> polling, an invalid netdev is still being used, which causes a panic.<br /> <br /> BUG: kernel NULL pointer dereference, address: 00000000000000f1<br /> Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> RIP: 0010:dev_gro_receive+0x3a/0x620<br /> [...]<br /> Call Trace:<br /> <br /> ? __die_body+0x68/0xb0<br /> ? page_fault_oops+0x379/0x3e0<br /> ? exc_page_fault+0x4f/0xa0<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? __pfx_t7xx_ccmni_recv_skb+0x10/0x10 [mtk_t7xx (HASH:1400 7)]<br /> ? dev_gro_receive+0x3a/0x620<br /> napi_gro_receive+0xad/0x170<br /> t7xx_ccmni_recv_skb+0x48/0x70 [mtk_t7xx (HASH:1400 7)]<br /> t7xx_dpmaif_napi_rx_poll+0x590/0x800 [mtk_t7xx (HASH:1400 7)]<br /> net_rx_action+0x103/0x470<br /> irq_exit_rcu+0x13a/0x310<br /> sysvec_apic_timer_interrupt+0x56/0x90<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fix udp gso skb_segment after pull from frag_list<br /> <br /> Commit a1e40ac5b5e9 ("net: gso: fix udp gso fraglist segmentation after<br /> pull from frag_list") detected invalid geometry in frag_list skbs and<br /> redirects them from skb_segment_list to more robust skb_segment. But some<br /> packets with modified geometry can also hit bugs in that code. We don&amp;#39;t<br /> know how many such cases exist. Addressing each one by one also requires<br /> touching the complex skb_segment code, which risks introducing bugs for<br /> other types of skbs. Instead, linearize all these packets that fail the<br /> basic invariants on gso fraglist skbs. That is more robust.<br /> <br /> If only part of the fraglist payload is pulled into head_skb, it will<br /> always cause exception when splitting skbs by skb_segment. For detailed<br /> call stack information, see below.<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 fraglist skbs, breaking these invariants.<br /> <br /> In extreme cases they pull one part of data into skb linear. For UDP,<br /> this causes three payloads with lengths of (11,11,10) bytes were<br /> pulled tail to become (12,10,10) bytes.<br /> <br /> The skbs no longer meets the above SKB_GSO_FRAGLIST conditions because<br /> payload was pulled into head_skb, it needs to be linearized before pass<br /> to regular skb_segment.<br /> <br /> skb_segment+0xcd0/0xd14<br /> __udp_gso_segment+0x334/0x5f4<br /> udp4_ufo_fragment+0x118/0x15c<br /> inet_gso_segment+0x164/0x338<br /> skb_mac_gso_segment+0xc4/0x13c<br /> __skb_gso_segment+0xc4/0x124<br /> validate_xmit_skb+0x9c/0x2c0<br /> validate_xmit_skb_list+0x4c/0x80<br /> sch_direct_xmit+0x70/0x404<br /> __dev_queue_xmit+0x64c/0xe5c<br /> neigh_resolve_output+0x178/0x1c4<br /> ip_finish_output2+0x37c/0x47c<br /> __ip_finish_output+0x194/0x240<br /> ip_finish_output+0x20/0xf4<br /> ip_output+0x100/0x1a0<br /> NF_HOOK+0xc4/0x16c<br /> ip_forward+0x314/0x32c<br /> ip_rcv+0x90/0x118<br /> __netif_receive_skb+0x74/0x124<br /> process_backlog+0xe8/0x1a4<br /> __napi_poll+0x5c/0x1f8<br /> net_rx_action+0x154/0x314<br /> handle_softirqs+0x154/0x4b8<br /> <br /> [118.376811] [C201134] rxq0_pus: [name:bug&amp;]kernel BUG at net/core/skbuff.c:4278!<br /> [118.376829] [C201134] rxq0_pus: [name:traps&amp;]Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP<br /> [118.470774] [C201134] rxq0_pus: [name:mrdump&amp;]Kernel Offset: 0x178cc00000 from 0xffffffc008000000<br /> [118.470810] [C201134] rxq0_pus: [name:mrdump&amp;]PHYS_OFFSET: 0x40000000<br /> [118.470827] [C201134] rxq0_pus: [name:mrdump&amp;]pstate: 60400005 (nZCv daif +PAN -UAO)<br /> [118.470848] [C201134] rxq0_pus: [name:mrdump&amp;]pc : [0xffffffd79598aefc] skb_segment+0xcd0/0xd14<br /> [118.470900] [C201134] rxq0_pus: [name:mrdump&amp;]lr : [0xffffffd79598a5e8] skb_segment+0x3bc/0xd14<br /> [118.470928] [C201134] rxq0_pus: [name:mrdump&amp;]sp : ffffffc008013770

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: stmmac: make sure that ptp_rate is not 0 before configuring EST<br /> <br /> If the ptp_rate recorded earlier in the driver happens to be 0, this<br /> bogus value will propagate up to EST configuration, where it will<br /> trigger a division by 0.<br /> <br /> Prevent this division by 0 by adding the corresponding check and error<br /> code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: stmmac: make sure that ptp_rate is not 0 before configuring timestamping<br /> <br /> The stmmac platform drivers that do not open-code the clk_ptp_rate value<br /> after having retrieved the default one from the device-tree can end up<br /> with 0 in clk_ptp_rate (as clk_get_rate can return 0). It will<br /> eventually propagate up to PTP initialization when bringing up the<br /> interface, leading to a divide by 0:<br /> <br /> Division by zero in kernel.<br /> CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.30-00001-g48313bd5768a #22<br /> Hardware name: STM32 (Device Tree Support)<br /> Call trace:<br /> unwind_backtrace from show_stack+0x18/0x1c<br /> show_stack from dump_stack_lvl+0x6c/0x8c<br /> dump_stack_lvl from Ldiv0_64+0x8/0x18<br /> Ldiv0_64 from stmmac_init_tstamp_counter+0x190/0x1a4<br /> stmmac_init_tstamp_counter from stmmac_hw_setup+0xc1c/0x111c<br /> stmmac_hw_setup from __stmmac_open+0x18c/0x434<br /> __stmmac_open from stmmac_open+0x3c/0xbc<br /> stmmac_open from __dev_open+0xf4/0x1ac<br /> __dev_open from __dev_change_flags+0x1cc/0x224<br /> __dev_change_flags from dev_change_flags+0x24/0x60<br /> dev_change_flags from ip_auto_config+0x2e8/0x11a0<br /> ip_auto_config from do_one_initcall+0x84/0x33c<br /> do_one_initcall from kernel_init_freeable+0x1b8/0x214<br /> kernel_init_freeable from kernel_init+0x24/0x140<br /> kernel_init from ret_from_fork+0x14/0x28<br /> Exception stack(0xe0815fb0 to 0xe0815ff8)<br /> <br /> Prevent this division by 0 by adding an explicit check and error log<br /> about the actual issue. While at it, remove the same check from<br /> stmmac_ptp_register, which then becomes duplicate

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix Tx scheduler error handling in XDP callback<br /> <br /> When the XDP program is loaded, the XDP callback adds new Tx queues.<br /> This means that the callback must update the Tx scheduler with the new<br /> queue number. In the event of a Tx scheduler failure, the XDP callback<br /> should also fail and roll back any changes previously made for XDP<br /> preparation.<br /> <br /> The previous implementation had a bug that not all changes made by the<br /> XDP callback were rolled back. This caused the crash with the following<br /> call trace:<br /> <br /> [ +9.549584] ice 0000:ca:00.0: Failed VSI LAN queue config for XDP, error: -5<br /> [ +0.382335] Oops: general protection fault, probably for non-canonical address 0x50a2250a90495525: 0000 [#1] SMP NOPTI<br /> [ +0.010710] CPU: 103 UID: 0 PID: 0 Comm: swapper/103 Not tainted 6.14.0-net-next-mar-31+ #14 PREEMPT(voluntary)<br /> [ +0.010175] Hardware name: Intel Corporation M50CYP2SBSTD/M50CYP2SBSTD, BIOS SE5C620.86B.01.01.0005.2202160810 02/16/2022<br /> [ +0.010946] RIP: 0010:__ice_update_sample+0x39/0xe0 [ice]<br /> <br /> [...]<br /> <br /> [ +0.002715] Call Trace:<br /> [ +0.002452] <br /> [ +0.002021] ? __die_body.cold+0x19/0x29<br /> [ +0.003922] ? die_addr+0x3c/0x60<br /> [ +0.003319] ? exc_general_protection+0x17c/0x400<br /> [ +0.004707] ? asm_exc_general_protection+0x26/0x30<br /> [ +0.004879] ? __ice_update_sample+0x39/0xe0 [ice]<br /> [ +0.004835] ice_napi_poll+0x665/0x680 [ice]<br /> [ +0.004320] __napi_poll+0x28/0x190<br /> [ +0.003500] net_rx_action+0x198/0x360<br /> [ +0.003752] ? update_rq_clock+0x39/0x220<br /> [ +0.004013] handle_softirqs+0xf1/0x340<br /> [ +0.003840] ? sched_clock_cpu+0xf/0x1f0<br /> [ +0.003925] __irq_exit_rcu+0xc2/0xe0<br /> [ +0.003665] common_interrupt+0x85/0xa0<br /> [ +0.003839] <br /> [ +0.002098] <br /> [ +0.002106] asm_common_interrupt+0x26/0x40<br /> [ +0.004184] RIP: 0010:cpuidle_enter_state+0xd3/0x690<br /> <br /> Fix this by performing the missing unmapping of XDP queues from<br /> q_vectors and setting the XDP rings pointer back to NULL after all those<br /> queues are released.<br /> Also, add an immediate exit from the XDP callback in case of ring<br /> preparation failure.