Vulnerabilidades

*** Pendiente de traducción *** 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

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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]

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: APEI: send SIGBUS to current task if synchronous memory error not recovered<br /> <br /> If a synchronous error is detected as a result of user-space process<br /> triggering a 2-bit uncorrected error, the CPU will take a synchronous<br /> error exception such as Synchronous External Abort (SEA) on Arm64. The<br /> kernel will queue a memory_failure() work which poisons the related<br /> page, unmaps the page, and then sends a SIGBUS to the process, so that<br /> a system wide panic can be avoided.<br /> <br /> However, no memory_failure() work will be queued when abnormal<br /> synchronous errors occur. These errors can include situations like<br /> invalid PA, unexpected severity, no memory failure config support,<br /> invalid GUID section, etc. In such a case, the user-space process will<br /> trigger SEA again. This loop can potentially exceed the platform<br /> firmware threshold or even trigger a kernel hard lockup, leading to a<br /> system reboot.<br /> <br /> Fix it by performing a force kill if no memory_failure() work is queued<br /> for synchronous errors.<br /> <br /> [ rjw: Changelog edits ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ctnetlink: remove refcounting in expectation dumpers<br /> <br /> Same pattern as previous patch: do not keep the expectation object<br /> alive via refcount, only store a cookie value and then use that<br /> as the skip hint for dump resumption.<br /> <br /> AFAICS this has the same issue as the one resolved in the conntrack<br /> dumper, when we do<br /> if (!refcount_inc_not_zero(&amp;exp-&gt;use))<br /> <br /> to increment the refcount, there is a chance that exp == last, which<br /> causes a double-increment of the refcount and subsequent memory leak.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: timer: fix ida_free call while not allocated<br /> <br /> In the snd_utimer_create() function, if the kasprintf() function return<br /> NULL, snd_utimer_put_id() will be called, finally use ida_free()<br /> to free the unallocated id 0.<br /> <br /> the syzkaller reported the following information:<br /> ------------[ cut here ]------------<br /> ida_free called for id=0 which is not allocated.<br /> WARNING: CPU: 1 PID: 1286 at lib/idr.c:592 ida_free+0x1fd/0x2f0 lib/idr.c:592<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 1286 Comm: syz-executor164 Not tainted 6.15.8 #3 PREEMPT(lazy)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.fc42 04/01/2014<br /> RIP: 0010:ida_free+0x1fd/0x2f0 lib/idr.c:592<br /> Code: f8 fc 41 83 fc 3e 76 69 e8 70 b2 f8 (...)<br /> RSP: 0018:ffffc900007f79c8 EFLAGS: 00010282<br /> RAX: 0000000000000000 RBX: 1ffff920000fef3b RCX: ffffffff872176a5<br /> RDX: ffff88800369d200 RSI: 0000000000000000 RDI: ffff88800369d200<br /> RBP: 0000000000000000 R08: ffffffff87ba60a5 R09: 0000000000000000<br /> R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000<br /> R13: 0000000000000002 R14: 0000000000000000 R15: 0000000000000000<br /> FS: 00007f6f1abc1740(0000) GS:ffff8880d76a0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f6f1ad7a784 CR3: 000000007a6e2000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> snd_utimer_put_id sound/core/timer.c:2043 [inline] [snd_timer]<br /> snd_utimer_create+0x59b/0x6a0 sound/core/timer.c:2184 [snd_timer]<br /> snd_utimer_ioctl_create sound/core/timer.c:2202 [inline] [snd_timer]<br /> __snd_timer_user_ioctl.isra.0+0x724/0x1340 sound/core/timer.c:2287 [snd_timer]<br /> snd_timer_user_ioctl+0x75/0xc0 sound/core/timer.c:2298 [snd_timer]<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:907 [inline]<br /> __se_sys_ioctl fs/ioctl.c:893 [inline]<br /> __x64_sys_ioctl+0x198/0x200 fs/ioctl.c:893<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0x7b/0x160 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [...]<br /> <br /> The utimer-&gt;id should be set properly before the kasprintf() function,<br /> ensures the snd_utimer_put_id() function will free the allocated id.