Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: rzg2l_adc: Set driver data before enabling runtime PM<br /> <br /> When stress-testing the system by repeatedly unbinding and binding the ADC<br /> device in a loop, and the ADC is a supplier for another device (e.g., a<br /> thermal hardware block that reads temperature through the ADC), it may<br /> happen that the ADC device is runtime-resumed immediately after runtime PM<br /> is enabled, triggered by its consumer. At this point, since drvdata is not<br /> yet set and the driver&amp;#39;s runtime PM callbacks rely on it, a crash can<br /> occur. To avoid this, set drvdata just after it was allocated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bridge: fix soft lockup in br_multicast_query_expired()<br /> <br /> When set multicast_query_interval to a large value, the local variable<br /> &amp;#39;time&amp;#39; in br_multicast_send_query() may overflow. If the time is smaller<br /> than jiffies, the timer will expire immediately, and then call mod_timer()<br /> again, which creates a loop and may trigger the following soft lockup<br /> issue.<br /> <br /> watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rb_consumer:66]<br /> CPU: 1 UID: 0 PID: 66 Comm: rb_consumer Not tainted 6.16.0+ #259 PREEMPT(none)<br /> Call Trace:<br /> <br /> __netdev_alloc_skb+0x2e/0x3a0<br /> br_ip6_multicast_alloc_query+0x212/0x1b70<br /> __br_multicast_send_query+0x376/0xac0<br /> br_multicast_send_query+0x299/0x510<br /> br_multicast_query_expired.constprop.0+0x16d/0x1b0<br /> call_timer_fn+0x3b/0x2a0<br /> __run_timers+0x619/0x950<br /> run_timer_softirq+0x11c/0x220<br /> handle_softirqs+0x18e/0x560<br /> __irq_exit_rcu+0x158/0x1a0<br /> sysvec_apic_timer_interrupt+0x76/0x90<br /> <br /> <br /> This issue can be reproduced with:<br /> ip link add br0 type bridge<br /> echo 1 &gt; /sys/class/net/br0/bridge/multicast_querier<br /> echo 0xffffffffffffffff &gt;<br /> /sys/class/net/br0/bridge/multicast_query_interval<br /> ip link set dev br0 up<br /> <br /> The multicast_startup_query_interval can also cause this issue. Similar to<br /> the commit 99b40610956a ("net: bridge: mcast: add and enforce query<br /> interval minimum"), add check for the query interval maximum to fix this<br /> issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/debug_vm_pgtable: clear page table entries at destroy_args()<br /> <br /> The mm/debug_vm_pagetable test allocates manually page table entries for<br /> the tests it runs, using also its manually allocated mm_struct. That in<br /> itself is ok, but when it exits, at destroy_args() it fails to clear those<br /> entries with the *_clear functions.<br /> <br /> The problem is that leaves stale entries. If another process allocates an<br /> mm_struct with a pgd at the same address, it may end up running into the<br /> stale entry. This is happening in practice on a debug kernel with<br /> CONFIG_DEBUG_VM_PGTABLE=y, for example this is the output with some extra<br /> debugging I added (it prints a warning trace if pgtables_bytes goes<br /> negative, in addition to the warning at check_mm() function):<br /> <br /> [ 2.539353] debug_vm_pgtable: [get_random_vaddr ]: random_vaddr is 0x7ea247140000<br /> [ 2.539366] kmem_cache info<br /> [ 2.539374] kmem_cachep 0x000000002ce82385 - freelist 0x0000000000000000 - offset 0x508<br /> [ 2.539447] debug_vm_pgtable: [init_args ]: args-&gt;mm is 0x000000002267cc9e<br /> (...)<br /> [ 2.552800] WARNING: CPU: 5 PID: 116 at include/linux/mm.h:2841 free_pud_range+0x8bc/0x8d0<br /> [ 2.552816] Modules linked in:<br /> [ 2.552843] CPU: 5 UID: 0 PID: 116 Comm: modprobe Not tainted 6.12.0-105.debug_vm2.el10.ppc64le+debug #1 VOLUNTARY<br /> [ 2.552859] Hardware name: IBM,9009-41A POWER9 (architected) 0x4e0202 0xf000005 of:IBM,FW910.00 (VL910_062) hv:phyp pSeries<br /> [ 2.552872] NIP: c0000000007eef3c LR: c0000000007eef30 CTR: c0000000003d8c90<br /> [ 2.552885] REGS: c0000000622e73b0 TRAP: 0700 Not tainted (6.12.0-105.debug_vm2.el10.ppc64le+debug)<br /> [ 2.552899] MSR: 800000000282b033 CR: 24002822 XER: 0000000a<br /> [ 2.552954] CFAR: c0000000008f03f0 IRQMASK: 0<br /> [ 2.552954] GPR00: c0000000007eef30 c0000000622e7650 c000000002b1ac00 0000000000000001<br /> [ 2.552954] GPR04: 0000000000000008 0000000000000000 c0000000007eef30 ffffffffffffffff<br /> [ 2.552954] GPR08: 00000000ffff00f5 0000000000000001 0000000000000048 0000000000004000<br /> [ 2.552954] GPR12: 00000003fa440000 c000000017ffa300 c0000000051d9f80 ffffffffffffffdb<br /> [ 2.552954] GPR16: 0000000000000000 0000000000000008 000000000000000a 60000000000000e0<br /> [ 2.552954] GPR20: 4080000000000000 c0000000113af038 00007fffcf130000 0000700000000000<br /> [ 2.552954] GPR24: c000000062a6a000 0000000000000001 8000000062a68000 0000000000000001<br /> [ 2.552954] GPR28: 000000000000000a c000000062ebc600 0000000000002000 c000000062ebc760<br /> [ 2.553170] NIP [c0000000007eef3c] free_pud_range+0x8bc/0x8d0<br /> [ 2.553185] LR [c0000000007eef30] free_pud_range+0x8b0/0x8d0<br /> [ 2.553199] Call Trace:<br /> [ 2.553207] [c0000000622e7650] [c0000000007eef30] free_pud_range+0x8b0/0x8d0 (unreliable)<br /> [ 2.553229] [c0000000622e7750] [c0000000007f40b4] free_pgd_range+0x284/0x3b0<br /> [ 2.553248] [c0000000622e7800] [c0000000007f4630] free_pgtables+0x450/0x570<br /> [ 2.553274] [c0000000622e78e0] [c0000000008161c0] exit_mmap+0x250/0x650<br /> [ 2.553292] [c0000000622e7a30] [c0000000001b95b8] __mmput+0x98/0x290<br /> [ 2.558344] [c0000000622e7a80] [c0000000001d1018] exit_mm+0x118/0x1b0<br /> [ 2.558361] [c0000000622e7ac0] [c0000000001d141c] do_exit+0x2ec/0x870<br /> [ 2.558376] [c0000000622e7b60] [c0000000001d1ca8] do_group_exit+0x88/0x150<br /> [ 2.558391] [c0000000622e7bb0] [c0000000001d1db8] sys_exit_group+0x48/0x50<br /> [ 2.558407] [c0000000622e7be0] [c00000000003d810] system_call_exception+0x1e0/0x4c0<br /> [ 2.558423] [c0000000622e7e50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec<br /> (...)<br /> [ 2.558892] ---[ end trace 0000000000000000 ]---<br /> [ 2.559022] BUG: Bad rss-counter state mm:000000002267cc9e type:MM_ANONPAGES val:1<br /> [ 2.559037] BUG: non-zero pgtables_bytes on freeing mm: -6144<br /> <br /> Here the modprobe process ended up with an allocated mm_struct from the<br /> mm_struct slab that was used before by the debug_vm_pgtable test. That is<br /> not a problem, since the mm_stru<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: pca9450: Use devm_register_sys_off_handler<br /> <br /> With module test, there is error dump:<br /> ------------[ cut here ]------------<br /> notifier callback pca9450_i2c_restart_handler already registered<br /> WARNING: kernel/notifier.c:23 at notifier_chain_register+0x5c/0x88,<br /> CPU#0: kworker/u16:3/50<br /> Call trace:<br /> notifier_chain_register+0x5c/0x88 (P)<br /> atomic_notifier_chain_register+0x30/0x58<br /> register_restart_handler+0x1c/0x28<br /> pca9450_i2c_probe+0x418/0x538<br /> i2c_device_probe+0x220/0x3d0<br /> really_probe+0x114/0x410<br /> __driver_probe_device+0xa0/0x150<br /> driver_probe_device+0x40/0x114<br /> __device_attach_driver+0xd4/0x12c<br /> <br /> So use devm_register_sys_off_handler to let kernel handle the resource<br /> free to avoid kernel dump.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en: Fix lockdep warning during rmmod<br /> <br /> The commit under the Fixes tag added a netdev_assert_locked() in<br /> bnxt_free_ntp_fltrs(). The lock should be held during normal run-time<br /> but the assert will be triggered (see below) during bnxt_remove_one()<br /> which should not need the lock. The netdev is already unregistered by<br /> then. Fix it by calling netdev_assert_locked_or_invisible() which will<br /> not assert if the netdev is unregistered.<br /> <br /> WARNING: CPU: 5 PID: 2241 at ./include/net/netdev_lock.h:17 bnxt_free_ntp_fltrs+0xf8/0x100 [bnxt_en]<br /> Modules linked in: rpcrdma rdma_cm iw_cm ib_cm configfs ib_core bnxt_en(-) bridge stp llc x86_pkg_temp_thermal xfs tg3 [last unloaded: bnxt_re]<br /> CPU: 5 UID: 0 PID: 2241 Comm: rmmod Tainted: G S W 6.16.0 #2 PREEMPT(voluntary)<br /> Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN<br /> Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017<br /> RIP: 0010:bnxt_free_ntp_fltrs+0xf8/0x100 [bnxt_en]<br /> Code: 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 48 8b 47 60 be ff ff ff ff 48 8d b8 28 0c 00 00 e8 d0 cf 41 c3 85 c0 0f 85 2e ff ff ff 0b e9 27 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90<br /> RSP: 0018:ffffa92082387da0 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff9e5b593d8000 RCX: 0000000000000001<br /> RDX: 0000000000000001 RSI: ffffffff83dc9a70 RDI: ffffffff83e1a1cf<br /> RBP: ffff9e5b593d8c80 R08: 0000000000000000 R09: ffffffff8373a2b3<br /> R10: 000000008100009f R11: 0000000000000001 R12: 0000000000000001<br /> R13: ffffffffc01c4478 R14: dead000000000122 R15: dead000000000100<br /> FS: 00007f3a8a52c740(0000) GS:ffff9e631ad1c000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000055bb289419c8 CR3: 000000011274e001 CR4: 00000000003706f0<br /> Call Trace:<br /> <br /> bnxt_remove_one+0x57/0x180 [bnxt_en]<br /> pci_device_remove+0x39/0xc0<br /> device_release_driver_internal+0xa5/0x130<br /> driver_detach+0x42/0x90<br /> bus_remove_driver+0x61/0xc0<br /> pci_unregister_driver+0x38/0x90<br /> bnxt_exit+0xc/0x7d0 [bnxt_en]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: HWS, fix complex rules rehash error flow<br /> <br /> Moving rules from matcher to matcher should not fail.<br /> However, if it does fail due to various reasons, the error flow<br /> should allow the kernel to continue functioning (albeit with broken<br /> steering rules) instead of going into series of soft lock-ups or<br /> some other problematic behaviour.<br /> <br /> Similar to the simple rules, complex rules rehash logic suffers<br /> from the same problems. This patch fixes the error flow for moving<br /> complex rules:<br /> - If new rule creation fails before it was even enqeued, do not<br /> poll for completion<br /> - If TIMEOUT happened while moving the rule, no point trying<br /> to poll for completions for other rules. Something is broken,<br /> completion won&amp;#39;t come, just abort the rehash sequence.<br /> - If some other completion with error received, don&amp;#39;t give up.<br /> Continue handling rest of the rules to minimize the damage.<br /> - Make sure that the first error code that was received will<br /> be actually returned to the caller instead of replacing it<br /> with the generic error code.<br /> <br /> All the aforementioned issues stem from the same bad error flow,<br /> so no point fixing them one by one and leaving partially broken<br /> code - fixing them in one patch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: Optimize module load time by optimizing PLT/GOT counting<br /> <br /> When enabling CONFIG_KASAN, CONFIG_PREEMPT_VOLUNTARY_BUILD and<br /> CONFIG_PREEMPT_VOLUNTARY at the same time, there will be soft deadlock,<br /> the relevant logs are as follows:<br /> <br /> rcu: INFO: rcu_sched self-detected stall on CPU<br /> ...<br /> Call Trace:<br /> [] show_stack+0x5c/0x180<br /> [] dump_stack_lvl+0x94/0xbc<br /> [] rcu_dump_cpu_stacks+0x1fc/0x280<br /> [] rcu_sched_clock_irq+0x720/0xf88<br /> [] update_process_times+0xb4/0x150<br /> [] tick_nohz_handler+0xf4/0x250<br /> [] __hrtimer_run_queues+0x1d0/0x428<br /> [] hrtimer_interrupt+0x214/0x538<br /> [] constant_timer_interrupt+0x64/0x80<br /> [] __handle_irq_event_percpu+0x78/0x1a0<br /> [] handle_irq_event_percpu+0x18/0x88<br /> [] handle_percpu_irq+0x90/0xf0<br /> [] handle_irq_desc+0x94/0xb8<br /> [] handle_cpu_irq+0x68/0xa0<br /> [] handle_loongarch_irq+0x30/0x48<br /> [] do_vint+0x80/0xd0<br /> [] kasan_mem_to_shadow.part.0+0x2c/0x2a0<br /> [] __asan_load8+0x4c/0x120<br /> [] module_frob_arch_sections+0x5c8/0x6b8<br /> [] load_module+0x9e0/0x2958<br /> [] __do_sys_init_module+0x208/0x2d0<br /> [] do_syscall+0x94/0x190<br /> [] handle_syscall+0xbc/0x158<br /> <br /> After analysis, this is because the slow speed of loading the amdgpu<br /> module leads to the long time occupation of the cpu and then the soft<br /> deadlock.<br /> <br /> When loading a module, module_frob_arch_sections() tries to figure out<br /> the number of PLTs/GOTs that will be needed to handle all the RELAs. It<br /> will call the count_max_entries() to find in an out-of-order date which<br /> counting algorithm has O(n^2) complexity.<br /> <br /> To make it faster, we sort the relocation list by info and addend. That<br /> way, to check for a duplicate relocation, it just needs to compare with<br /> the previous entry. This reduces the complexity of the algorithm to O(n<br /> log n), as done in commit d4e0340919fb ("arm64/module: Optimize module<br /> load time by optimizing PLT counting"). This gives sinificant reduction<br /> in module load time for modules with large number of relocations.<br /> <br /> After applying this patch, the soft deadlock problem has been solved,<br /> and the kernel starts normally without "Call Trace".<br /> <br /> Using the default configuration to test some modules, the results are as<br /> follows:<br /> <br /> Module Size<br /> ip_tables 36K<br /> fat 143K<br /> radeon 2.5MB<br /> amdgpu 16MB<br /> <br /> Without this patch:<br /> Module Module load time (ms) Count(PLTs/GOTs)<br /> ip_tables 18 59/6<br /> fat 0 162/14<br /> radeon 54 1221/84<br /> amdgpu 1411 4525/1098<br /> <br /> With this patch:<br /> Module Module load time (ms) Count(PLTs/GOTs)<br /> ip_tables 18 59/6<br /> fat 0 162/14<br /> radeon 22 1221/84<br /> amdgpu 45 4525/1098

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: gso: Forbid IPv6 TSO with extensions on devices with only IPV6_CSUM<br /> <br /> When performing Generic Segmentation Offload (GSO) on an IPv6 packet that<br /> contains extension headers, the kernel incorrectly requests checksum offload<br /> if the egress device only advertises NETIF_F_IPV6_CSUM feature, which has<br /> a strict contract: it supports checksum offload only for plain TCP or UDP<br /> over IPv6 and explicitly does not support packets with extension headers.<br /> The current GSO logic violates this contract by failing to disable the feature<br /> for packets with extension headers, such as those used in GREoIPv6 tunnels.<br /> <br /> This violation results in the device being asked to perform an operation<br /> it cannot support, leading to a `skb_warn_bad_offload` warning and a collapse<br /> of network throughput. While device TSO/USO is correctly bypassed in favor<br /> of software GSO for these packets, the GSO stack must be explicitly told not<br /> to request checksum offload.<br /> <br /> Mask NETIF_F_IPV6_CSUM, NETIF_F_TSO6 and NETIF_F_GSO_UDP_L4<br /> in gso_features_check if the IPv6 header contains extension headers to compute<br /> checksum in software.<br /> <br /> The exception is a BIG TCP extension, which, as stated in commit<br /> 68e068cabd2c6c53 ("net: reenable NETIF_F_IPV6_CSUM offload for BIG TCP packets"):<br /> "The feature is only enabled on devices that support BIG TCP TSO.<br /> The header is only present for PF_PACKET taps like tcpdump,<br /> and not transmitted by physical devices."<br /> <br /> kernel log output (truncated):<br /> WARNING: CPU: 1 PID: 5273 at net/core/dev.c:3535 skb_warn_bad_offload+0x81/0x140<br /> ...<br /> Call Trace:<br /> <br /> skb_checksum_help+0x12a/0x1f0<br /> validate_xmit_skb+0x1a3/0x2d0<br /> validate_xmit_skb_list+0x4f/0x80<br /> sch_direct_xmit+0x1a2/0x380<br /> __dev_xmit_skb+0x242/0x670<br /> __dev_queue_xmit+0x3fc/0x7f0<br /> ip6_finish_output2+0x25e/0x5d0<br /> ip6_finish_output+0x1fc/0x3f0<br /> ip6_tnl_xmit+0x608/0xc00 [ip6_tunnel]<br /> ip6gre_tunnel_xmit+0x1c0/0x390 [ip6_gre]<br /> dev_hard_start_xmit+0x63/0x1c0<br /> __dev_queue_xmit+0x6d0/0x7f0<br /> ip6_finish_output2+0x214/0x5d0<br /> ip6_finish_output+0x1fc/0x3f0<br /> ip6_xmit+0x2ca/0x6f0<br /> ip6_finish_output+0x1fc/0x3f0<br /> ip6_xmit+0x2ca/0x6f0<br /> inet6_csk_xmit+0xeb/0x150<br /> __tcp_transmit_skb+0x555/0xa80<br /> tcp_write_xmit+0x32a/0xe90<br /> tcp_sendmsg_locked+0x437/0x1110<br /> tcp_sendmsg+0x2f/0x50<br /> ...<br /> skb linear: 00000000: e4 3d 1a 7d ec 30 e4 3d 1a 7e 5d 90 86 dd 60 0e<br /> skb linear: 00000010: 00 0a 1b 34 3c 40 20 11 00 00 00 00 00 00 00 00<br /> skb linear: 00000020: 00 00 00 00 00 12 20 11 00 00 00 00 00 00 00 00<br /> skb linear: 00000030: 00 00 00 00 00 11 2f 00 04 01 04 01 01 00 00 00<br /> skb linear: 00000040: 86 dd 60 0e 00 0a 1b 00 06 40 20 23 00 00 00 00<br /> skb linear: 00000050: 00 00 00 00 00 00 00 00 00 12 20 23 00 00 00 00<br /> skb linear: 00000060: 00 00 00 00 00 00 00 00 00 11 bf 96 14 51 13 f9<br /> skb linear: 00000070: ae 27 a0 a8 2b e3 80 18 00 40 5b 6f 00 00 01 01<br /> skb linear: 00000080: 08 0a 42 d4 50 d5 4b 70 f8 1a

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/hisilicon/hibmc: fix the hibmc loaded failed bug<br /> <br /> When hibmc loaded failed, the driver use hibmc_unload to free the<br /> resource, but the mutexes in mode.config are not init, which will<br /> access an NULL pointer. Just change goto statement to return, because<br /> hibnc_hw_init() doesn&amp;#39;t need to free anything.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: Make cake_enqueue return NET_XMIT_CN when past buffer_limit<br /> <br /> The following setup can trigger a WARNING in htb_activate due to<br /> the condition: !cl-&gt;leaf.q-&gt;q.qlen<br /> <br /> tc qdisc del dev lo root<br /> tc qdisc add dev lo root handle 1: htb default 1<br /> tc class add dev lo parent 1: classid 1:1 \<br /> htb rate 64bit<br /> tc qdisc add dev lo parent 1:1 handle f: \<br /> cake memlimit 1b<br /> ping -I lo -f -c1 -s64 -W0.001 127.0.0.1<br /> <br /> This is because the low memlimit leads to a low buffer_limit, which<br /> causes packet dropping. However, cake_enqueue still returns<br /> NET_XMIT_SUCCESS, causing htb_enqueue to call htb_activate with an<br /> empty child qdisc. We should return NET_XMIT_CN when packets are<br /> dropped from the same tin and flow.<br /> <br /> I do not believe return value of NET_XMIT_CN is necessary for packet<br /> drops in the case of ack filtering, as that is meant to optimize<br /> performance, not to signal congestion.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: Decrement TID on RX peer frag setup error handling<br /> <br /> Currently, TID is not decremented before peer cleanup, during error<br /> handling path of ath12k_dp_rx_peer_frag_setup(). This could lead to<br /> out-of-bounds access in peer-&gt;rx_tid[].<br /> <br /> Hence, add a decrement operation for TID, before peer cleanup to<br /> ensures proper cleanup and prevents out-of-bounds access issues when<br /> the RX peer frag setup fails.<br /> <br /> Found during code review. Compile tested only.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: add null check<br /> <br /> [WHY]<br /> Prevents null pointer dereferences to enhance function robustness<br /> <br /> [HOW]<br /> Adds early null check and return false if invalid.