Detections
Analytics

TencentOS Server 4: kernel (TSSA-2025:0435)

high Nessus Plugin ID 276005

Synopsis

The remote TencentOS Server 4 host is missing one or more security updates.

Description

The version of Tencent Linux installed on the remote TencentOS Server 4 host is prior to tested version. It is, therefore, affected by multiple vulnerabilities as referenced in the TSSA-2025:0435 advisory.

 Package updates are available for TencentOS Server 4 that fix the following vulnerabilities:

 CVE-2024-56631:
 In the Linux kernel, the following vulnerability has been resolved:

 scsi: sg: Fix slab-use-after-free read in sg_release()

 Fix a use-after-free bug in sg_release(), detected by syzbot with KASAN:

 BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5838
 __mutex_unlock_slowpath+0xe2/0x750 kernel/locking/mutex.c:912 sg_release+0x1f4/0x2e0 drivers/scsi/sg.c:407

 In sg_release(), the function kref_put(&sfp->f_ref, sg_remove_sfp) is called before releasing the open_rel_lock mutex. The kref_put() call may decrement the reference count of sfp to zero, triggering its cleanup through sg_remove_sfp(). This cleanup includes scheduling deferred work via sg_remove_sfp_usercontext(), which ultimately frees sfp.

 After kref_put(), sg_release() continues to unlock open_rel_lock and may reference sfp or sdp. If sfp has already been freed, this results in a slab-use-after-free error.

 Move the kref_put(&sfp->f_ref, sg_remove_sfp) call after unlocking the open_rel_lock mutex. This ensures:

 - No references to sfp or sdp occur after the reference count is decremented.

 - Cleanup functions such as sg_remove_sfp() and sg_remove_sfp_usercontext() can safely execute without impacting the mutex handling in sg_release().

 The fix has been tested and validated by syzbot. This patch closes the bug reported at the following syzkaller link and ensures proper sequencing of resource cleanup and mutex operations, eliminating the risk of use-after-free errors in sg_release().

 CVE-2022-25265:
 In the Linux kernel through 5.16.10, certain binary files may have the exec-all attribute if they were built in approximately 2003 (e.g., with GCC 3.2.2 and Linux kernel 2.4.20). This can cause execution of bytes located in supposedly non-executable regions of a file.

 CVE-2024-50125:
 In the Linux kernel, the following vulnerability has been resolved:

 Bluetooth: SCO: Fix UAF on sco_sock_timeout

 conn->sk maybe have been unlinked/freed while waiting for sco_conn_lock so this checks if the conn->sk is still valid by checking if it part of sco_sk_list.

 CVE-2024-50067:
 In the Linux kernel, the following vulnerability has been resolved:

 uprobe: avoid out-of-bounds memory access of fetching args

 Uprobe needs to fetch args into a percpu buffer, and then copy to ring buffer to avoid non-atomic context problem.

 Sometimes user-space strings, arrays can be very large, but the size of percpu buffer is only page size. And store_trace_args() won't check whether these data exceeds a single page or not, caused out-of-bounds memory access.

 It could be reproduced by following steps:
 1. build kernel with CONFIG_KASAN enabled 2. save follow program as test.c

 ``` \#include <stdio.h> \#include <stdlib.h> \#include <string.h>

 // If string length large than MAX_STRING_SIZE, the fetch_store_strlen() // will return 0, cause __get_data_size() return shorter size, and // store_trace_args() will not trigger out-of-bounds access.
 // So make string length less than 4096.
 \#define STRLEN 4093

 void generate_string(char *str, int n) { int i;
 for (i = 0; i < n; ++i) { char c = i % 26 + 'a';
 str[i] = c;
 } str[n-1] = '\0';
 }

 void print_string(char *str) { printf(%s\n, str);
 }

 int main() { char tmp[STRLEN];

 generate_string(tmp, STRLEN);
 print_string(tmp);

 return 0;
 } ``` 3. compile program `gcc -o test test.c`

 4. get the offset of `print_string()` ``` objdump -t test | grep -w print_string 0000000000401199 g F .text 000000000000001b print_string ```

 5. configure uprobe with offset 0x1199 ``` off=0x1199

 cd /sys/kernel/debug/tracing/ echo p /root/test:${off} arg1=+0(%di):ustring arg2=\$comm arg3=+0(%di):ustring > uprobe_events echo 1 > events/uprobes/enable echo 1 > tracing_on ```

 6. run `test`, and kasan will report error.
 ================================================================== BUG: KASAN: use-after-free in strncpy_from_user+0x1d6/0x1f0 Write of size 8 at addr ffff88812311c004 by task test/499CPU: 0 UID: 0 PID: 499 Comm: test Not tainted 6.12.0-rc3+ #18 Hardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014 Call Trace:
 <TASK> dump_stack_lvl+0x55/0x70 print_address_description.constprop.0+0x27/0x310 kasan_report+0x10f/0x120 ? strncpy_from_user+0x1d6/0x1f0 strncpy_from_user+0x1d6/0x1f0 ? rmqueue.constprop.0+0x70d/0x2ad0 process_fetch_insn+0xb26/0x1470 ? __pfx_process_fetch_insn+0x10/0x10 ? _raw_spin_lock+0x85/0xe0 ? __pfx__raw_spin_lock+0x10/0x10 ? __pte_offset_map+0x1f/0x2d0 ? unwind_next_frame+0xc5f/0x1f80 ? arch_stack_walk+0x68/0xf0 ? is_bpf_text_address+0x23/0x30 ? kernel_text_address.part.0+0xbb/0xd0 ? __kernel_text_address+0x66/0xb0 ? unwind_get_return_address+0x5e/0xa0 ? __pfx_stack_trace_consume_entry+0x10/0x10 ? arch_stack_walk+0xa2/0xf0 ? _raw_spin_lock_irqsave+0x8b/0xf0 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? depot_alloc_stack+0x4c/0x1f0 ? _raw_spin_unlock_irqrestore+0xe/0x30 ? stack_depot_save_flags+0x35d/0x4f0 ? kasan_save_stack+0x34/0x50 ? kasan_save_stack+0x24/0x50 ? mutex_lock+0x91/0xe0 ? __pfx_mutex_lock+0x10/0x10 prepare_uprobe_buffer.part.0+0x2cd/0x500 uprobe_dispatcher+0x2c3/0x6a0 ? __pfx_uprobe_dispatcher+0x10/0x10 ? __kasan_slab_alloc+0x4d/0x90 handler_chain+0xdd/0x3e0 handle_swbp+0x26e/0x3d0 ? __pfx_handle_swbp+0x10/0x10 ? uprobe_pre_sstep_notifier+0x151/0x1b0 irqentry_exit_to_user_mode+0xe2/0x1b0 asm_exc_int3+0x39/0x40 RIP: 0033:0x401199 Code: 01 c2 0f b6 45 fb 88 02 83 45 fc 01 8b 45 fc 3b 45 e4 7c b7 8b 45 e4 48 98 48 8d 50 ff 48 8b 45 e8 48 01 d0 ce RSP: 002b:00007ffdf00576a8 EFLAGS: 00000206 RAX: 00007ffdf00576b0 RBX: 0000000000000000 RCX: 0000000000000ff2 RDX: 0000000000000ffc RSI: 0000000000000ffd RDI: 00007ffdf00576b0 RBP: 00007ffdf00586b0 R08: 00007feb2f9c0d20 R09: 00007feb2f9c0d20 R10: 0000000000000001 R11: 0000000000000202 R12: 0000000000401040 R13: 00007ffdf0058780 R14: 0000000000000000 R15: 0000000000000000 </TASK>

 This commit enforces the buffer's maxlen less than a page-size to avoid store_trace_args() out-of-memory access.

 CVE-2024-36978:
 In the Linux kernel, the following vulnerability has been resolved:

 net: sched: sch_multiq: fix possible OOB write in multiq_tune()

 q->bands will be assigned to qopt->bands to execute subsequent code logic after kmalloc. So the old q->bands should not be used in kmalloc.
 Otherwise, an out-of-bounds write will occur.

 CVE-2024-26593:
 In the Linux kernel, the following vulnerability has been resolved:

 i2c: i801: Fix block process call transactions

 According to the Intel datasheets, software must reset the block buffer index twice for block process call transactions: once before writing the outgoing data to the buffer, and once again before reading the incoming data from the buffer.

 The driver is currently missing the second reset, causing the wrong portion of the block buffer to be read.

 CVE-2023-52340:
 The IPv6 implementation in the Linux kernel before 6.3 has a net/ipv6/route.c max_size threshold that can be consumed easily, e.g., leading to a denial of service (network is unreachable errors) when IPv6 packets are sent in a loop via a raw socket.

 CVE-2025-21700:
 In the Linux kernel, the following vulnerability has been resolved:

 net: sched: Disallow replacing of child qdisc from one parent to another

 Lion Ackermann was able to create a UAF which can be abused for privilege escalation with the following script

 Step 1. create root qdisc tc qdisc add dev lo root handle 1:0 drr

 step2. a class for packet aggregation do demonstrate uaf tc class add dev lo classid 1:1 drr

 step3. a class for nesting tc class add dev lo classid 1:2 drr

 step4. a class to graft qdisc to tc class add dev lo classid 1:3 drr

 step5.
 tc qdisc add dev lo parent 1:1 handle 2:0 plug limit 1024

 step6.
 tc qdisc add dev lo parent 1:2 handle 3:0 drr

 step7.
 tc class add dev lo classid 3:1 drr

 step 8.
 tc qdisc add dev lo parent 3:1 handle 4:0 pfifo

 step 9. Display the class/qdisc layout

 tc class ls dev lo class drr 1:1 root leaf 2: quantum 64Kb class drr 1:2 root leaf 3: quantum 64Kb class drr 3:1 root leaf 4: quantum 64Kb

 tc qdisc ls qdisc drr 1: dev lo root refcnt 2 qdisc plug 2: dev lo parent 1:1 qdisc pfifo 4: dev lo parent 3:1 limit 1000p qdisc drr 3: dev lo parent 1:2

 step10. trigger the bug <=== prevented by this patch tc qdisc replace dev lo parent 1:3 handle 4:0

 step 11. Redisplay again the qdiscs/classes

 tc class ls dev lo class drr 1:1 root leaf 2: quantum 64Kb class drr 1:2 root leaf 3: quantum 64Kb class drr 1:3 root leaf 4: quantum 64Kb class drr 3:1 root leaf 4: quantum 64Kb

 tc qdisc ls qdisc drr 1: dev lo root refcnt 2 qdisc plug 2: dev lo parent 1:1 qdisc pfifo 4: dev lo parent 3:1 refcnt 2 limit 1000p qdisc drr 3: dev lo parent 1:2

 Observe that a) parent for 4:0 does not change despite the replace request.
 There can only be one parent. b) refcount has gone up by two for 4:0 and c) both class 1:3 and 3:1 are pointing to it.

 Step 12. send one packet to plug echo | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10001)) step13. send one packet to the grafted fifo echo | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10003))

 step14. lets trigger the uaf tc class delete dev lo classid 1:3 tc class delete dev lo classid 1:1

 The semantics of replace is for a del/add _on the same node_ and not a delete from one node(3:1) and add to another node (1:3) as in step10.
 While we could fix with a more complex approach there could be consequences to expectations so the patch takes the preventive approach of disallow such config.

 Joint work with Lion Ackermann <[email protected]>

 CVE-2024-56662:
 In the Linux kernel, the following vulnerability has been resolved:

 acpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctl

 Fix an issue detected by syzbot with KASAN:

 BUG: KASAN: vmalloc-out-of-bounds in cmd_to_func drivers/acpi/nfit/ core.c:416 [inline] BUG: KASAN: vmalloc-out-of-bounds in acpi_nfit_ctl+0x20e8/0x24a0 drivers/acpi/nfit/core.c:459

 The issue occurs in cmd_to_func when the call_pkg->nd_reserved2 array is accessed without verifying that call_pkg points to a buffer that is appropriately sized as a struct nd_cmd_pkg. This can lead to out-of-bounds access and undefined behavior if the buffer does not have sufficient space.

 To address this, a check was added in acpi_nfit_ctl() to ensure that buf is not NULL and that buf_len is less than sizeof(*call_pkg) before accessing it. This ensures safe access to the members of call_pkg, including the nd_reserved2 array.

 CVE-2024-40980:
 In the Linux kernel, the following vulnerability has been resolved:

 drop_monitor: replace spin_lock by raw_spin_lock

 trace_drop_common() is called with preemption disabled, and it acquires a spin_lock. This is problematic for RT kernels because spin_locks are sleeping locks in this configuration, which causes the following splat:

 BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 449, name: rcuc/47 preempt_count: 1, expected: 0 RCU nest depth: 2, expected: 2 5 locks held by rcuc/47/449:
 #0: ff1100086ec30a60 ((softirq_ctrl.lock)){+.+.}-{2:2}, at: __local_bh_disable_ip+0x105/0x210 #1: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: rt_spin_lock+0xbf/0x130 #2: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: __local_bh_disable_ip+0x11c/0x210 #3: ffffffffb394a160 (rcu_callback){....}-{0:0}, at: rcu_do_batch+0x360/0xc70 #4: ff1100086ee07520 (&data->lock){+.+.}-{2:2}, at: trace_drop_common.constprop.0+0xb5/0x290 irq event stamp: 139909 hardirqs last enabled at (139908): [<ffffffffb1df2b33>] _raw_spin_unlock_irqrestore+0x63/0x80 hardirqs last disabled at (139909): [<ffffffffb19bd03d>] trace_drop_common.constprop.0+0x26d/0x290 softirqs last enabled at (139892): [<ffffffffb07a1083>] __local_bh_enable_ip+0x103/0x170 softirqs last disabled at (139898): [<ffffffffb0909b33>] rcu_cpu_kthread+0x93/0x1f0 Preemption disabled at:
 [<ffffffffb1de786b>] rt_mutex_slowunlock+0xab/0x2e0 CPU: 47 PID: 449 Comm: rcuc/47 Not tainted 6.9.0-rc2-rt1+ #7 Hardware name: Dell Inc. PowerEdge R650/0Y2G81, BIOS 1.6.5 04/15/2022 Call Trace:
 <TASK> dump_stack_lvl+0x8c/0xd0 dump_stack+0x14/0x20
 __might_resched+0x21e/0x2f0 rt_spin_lock+0x5e/0x130 ? trace_drop_common.constprop.0+0xb5/0x290 ? skb_queue_purge_reason.part.0+0x1bf/0x230 trace_drop_common.constprop.0+0xb5/0x290 ? preempt_count_sub+0x1c/0xd0 ? _raw_spin_unlock_irqrestore+0x4a/0x80 ? __pfx_trace_drop_common.constprop.0+0x10/0x10 ? rt_mutex_slowunlock+0x26a/0x2e0 ? skb_queue_purge_reason.part.0+0x1bf/0x230 ? __pfx_rt_mutex_slowunlock+0x10/0x10 ? skb_queue_purge_reason.part.0+0x1bf/0x230 trace_kfree_skb_hit+0x15/0x20 trace_kfree_skb+0xe9/0x150 kfree_skb_reason+0x7b/0x110 skb_queue_purge_reason.part.0+0x1bf/0x230 ? __pfx_skb_queue_purge_reason.part.0+0x10/0x10 ? mark_lock.part.0+0x8a/0x520 ...

 trace_drop_common() also disables interrupts, but this is a minor issue because we could easily replace it with a local_lock.

 Replace the spin_lock with raw_spin_lock to avoid sleeping in atomic context.

 CVE-2022-48742:
 In the Linux kernel, the following vulnerability has been resolved:

 rtnetlink: make sure to refresh master_dev/m_ops in __rtnl_newlink()

 While looking at one unrelated syzbot bug, I found the replay logic in __rtnl_newlink() to potentially trigger use-after-free.

 It is better to clear master_dev and m_ops inside the loop, in case we have to replay it.

 CVE-2024-50035:
 In the Linux kernel, the following vulnerability has been resolved:

 ppp: fix ppp_async_encode() illegal access

 syzbot reported an issue in ppp_async_encode() [1]

 In this case, pppoe_sendmsg() is called with a zero size.
 Then ppp_async_encode() is called with an empty skb.

 BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline] ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113
 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline]
 __sock_sendmsg+0x30f/0x380 net/socket.c:744
 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602
 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656
 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742
 __do_sys_sendmmsg net/socket.c:2771 [inline]
 __se_sys_sendmmsg net/socket.c:2768 [inline]
 __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f

 Uninit was created at:
 slab_post_alloc_hook mm/slub.c:4092 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587
 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline]
 __sock_sendmsg+0x30f/0x380 net/socket.c:744
 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602
 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656
 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742
 __do_sys_sendmmsg net/socket.c:2771 [inline]
 __se_sys_sendmmsg net/socket.c:2768 [inline]
 __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f

 CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024

 CVE-2024-49894:
 In the Linux kernel, the following vulnerability has been resolved:

 drm/amd/display: Fix index out of bounds in degamma hardware format translation

 Fixes index out of bounds issue in `cm_helper_translate_curve_to_degamma_hw_format` function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS).

 The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds the function returns false to indicate an error.

 Reported by smatch:
 drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max

 CVE-2024-44940:
 In the Linux kernel, the following vulnerability has been resolved:

 fou: remove warn in gue_gro_receive on unsupported protocol

 Drop the WARN_ON_ONCE inn gue_gro_receive if the encapsulated type is not known or does not have a GRO handler.

 Such a packet is easily constructed. Syzbot generates them and sets off this warning.

 Remove the warning as it is expected and not actionable.

 The warning was previously reduced from WARN_ON to WARN_ON_ONCE in commit 270136613bf7 (fou: Do WARN_ON_ONCE in gue_gro_receive for bad proto callbacks).

 CVE-2024-42301:
 In the Linux kernel, the following vulnerability has been resolved:

 dev/parport: fix the array out-of-bounds risk

 Fixed array out-of-bounds issues caused by sprintf by replacing it with snprintf for safer data copying, ensuring the destination buffer is not overflowed.

 Below is the stack trace I encountered during the actual issue:

 [ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector:
 Kernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport] [ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm:
 QThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2 [ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp [ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun PGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024 [ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace:
 [ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0 [ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20 [ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c [ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc [ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38 [ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport]

 CVE-2024-42285:
 In the Linux kernel, the following vulnerability has been resolved:

 RDMA/iwcm: Fix a use-after-free related to destroying CM IDs

 iw_conn_req_handler() associates a new struct rdma_id_private (conn_id) with an existing struct iw_cm_id (cm_id) as follows:

 conn_id->cm_id.iw = cm_id;
 cm_id->context = conn_id;
 cm_id->cm_handler = cma_iw_handler;

 rdma_destroy_id() frees both the cm_id and the struct rdma_id_private. Make sure that cm_work_handler() does not trigger a use-after-free by only freeing of the struct rdma_id_private after all pending work has finished.

 CVE-2024-36971:
 In the Linux kernel, the following vulnerability has been resolved:

 net: fix __dst_negative_advice() race

 __dst_negative_advice() does not enforce proper RCU rules when sk->dst_cache must be cleared, leading to possible UAF.

 RCU rules are that we must first clear sk->sk_dst_cache, then call dst_release(old_dst).

 Note that sk_dst_reset(sk) is implementing this protocol correctly, while __dst_negative_advice() uses the wrong order.

 Given that ip6_negative_advice() has special logic against RTF_CACHE, this means each of the three ->negative_advice() existing methods must perform the sk_dst_reset() themselves.

 Note the check against NULL dst is centralized in
 __dst_negative_advice(), there is no need to duplicate it in various callbacks.

 Many thanks to Clement Lecigne for tracking this issue.

 This old bug became visible after the blamed commit, using UDP sockets.

 CVE-2024-35955:
 In the Linux kernel, the following vulnerability has been resolved:

 kprobes: Fix possible use-after-free issue on kprobe registration

 When unloading a module, its state is changing MODULE_STATE_LIVE -> MODULE_STATE_GOING -> MODULE_STATE_UNFORMED. Each change will take a time. `is_module_text_address()` and `__module_text_address()` works with MODULE_STATE_LIVE and MODULE_STATE_GOING.
 If we use `is_module_text_address()` and `__module_text_address()` separately, there is a chance that the first one is succeeded but the next one is failed because module->state becomes MODULE_STATE_UNFORMED between those operations.

 In `check_kprobe_address_safe()`, if the second `__module_text_address()` is failed, that is ignored because it expected a kernel_text address.
 But it may have failed simply because module->state has been changed to MODULE_STATE_UNFORMED. In this case, arm_kprobe() will try to modify non-exist module text address (use-after-free).

 To fix this problem, we should not use separated `is_module_text_address()` and `__module_text_address()`, but use only `__module_text_address()` once and do `try_module_get(module)` which is only available with MODULE_STATE_LIVE.

 CVE-2021-3715:
 A flaw was found in the Routing decision classifier in the Linux kernel's Traffic Control networking subsystem in the way it handled changing of classification filters, leading to a use-after-free condition.
 This flaw allows unprivileged local users to escalate their privileges on the system. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability.

 CVE-2024-26865:
 In the Linux kernel, the following vulnerability has been resolved:

 rds: tcp: Fix use-after-free of net in reqsk_timer_handler().

 syzkaller reported a warning of netns tracker [0] followed by KASAN splat [1] and another ref tracker warning [1].

 syzkaller could not find a repro, but in the log, the only suspicious sequence was as follows:

 18:26:22 executing program 1:
 r0 = socket$inet6_mptcp(0xa, 0x1, 0x106) ...
 connect$inet6(r0, &(0x7f0000000080)={0xa, 0x4001, 0x0, @loopback}, 0x1c) (async)

 The notable thing here is 0x4001 in connect(), which is RDS_TCP_PORT.

 So, the scenario would be:

 1. unshare(CLONE_NEWNET) creates a per netns tcp listener in rds_tcp_listen_init().
 2. syz-executor connect()s to it and creates a reqsk.
 3. syz-executor exit()s immediately.
 4. netns is dismantled. [0] 5. reqsk timer is fired, and UAF happens while freeing reqsk. [1] 6. listener is freed after RCU grace period. [2]

 Basically, reqsk assumes that the listener guarantees netns safety until all reqsk timers are expired by holding the listener's refcount.
 However, this was not the case for kernel sockets.

 Commit 740ea3c4a0b2 (tcp: Clean up kernel listener's reqsk in inet_twsk_purge()) fixed this issue only for per-netns ehash.

 Let's apply the same fix for the global ehash.

 [0]:
 ref_tracker: net notrefcnt@0000000065449cc3 has 1/1 users at sk_alloc (./include/net/net_namespace.h:337 net/core/sock.c:2146) inet6_create (net/ipv6/af_inet6.c:192 net/ipv6/af_inet6.c:119)
 __sock_create (net/socket.c:1572) rds_tcp_listen_init (net/rds/tcp_listen.c:279) rds_tcp_init_net (net/rds/tcp.c:577) ops_init (net/core/net_namespace.c:137) setup_net (net/core/net_namespace.c:340) copy_net_ns (net/core/net_namespace.c:497) create_new_namespaces (kernel/nsproxy.c:110) unshare_nsproxy_namespaces (kernel/nsproxy.c:228 (discriminator 4)) ksys_unshare (kernel/fork.c:3429)
 __x64_sys_unshare (kernel/fork.c:3496) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129) ...
 WARNING: CPU: 0 PID: 27 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)

 [1]:
 BUG: KASAN: slab-use-after-free in inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966) Read of size 8 at addr ffff88801b370400 by task swapper/0/0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Call Trace:
 <IRQ> dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1)) print_report (mm/kasan/report.c:378 mm/kasan/report.c:488) kasan_report (mm/kasan/report.c:603) inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966) reqsk_timer_handler (net/ipv4/inet_connection_sock.c:979 net/ipv4/inet_connection_sock.c:1092) call_timer_fn (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701)
 __run_timers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2038) run_timer_softirq (kernel/time/timer.c:2053)
 __do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:554) ...

 Please note that the description has been truncated due to length. Please refer to vendor advisory for the full description.

Tenable has extracted the preceding description block directly from the Tencent Linux security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

Solution

Update the affected packages.

See Also

https://mirrors.tencent.com/tlinux/errata/tssa-20250435.xml

Plugin Details

Severity: High

ID: 276005

File Name: tencentos_TSSA_2025_0435.nasl

Version: 1.1

Type: local

Published: 11/20/2025

Updated: 11/20/2025

Supported Sensors: Nessus

Risk Information

VPR

Risk Factor: High

Score: 7.4

CVSS v2

Risk Factor: High

Base Score: 7.2

Temporal Score: 6

Vector: CVSS2#AV:L/AC:L/Au:N/C:C/I:C/A:C

CVSS Score Source: CVE-2021-3715

CVSS v3

Risk Factor: High

Base Score: 7.8

Temporal Score: 7.2

Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Temporal Vector: CVSS:3.0/E:F/RL:O/RC:C

CVSS Score Source: CVE-2025-37854

Vulnerability Information

CPE: cpe:/o:tencent:tencentos_server:4, p-cpe:/a:tencent:tencentos_server:kernel

Required KB Items: Host/local_checks_enabled, Host/etc/os-release, Host/TencentOS/rpm-list, Host/cpu

Exploit Available: true

Exploit Ease: Exploits are available

Patch Publication Date: 7/8/2025

Vulnerability Publication Date: 11/4/2020

CISA Known Exploited Vulnerability Due Dates: 8/28/2024

Reference Information

CVE: CVE-2021-3715, CVE-2022-25265, CVE-2022-48742, CVE-2022-48789, CVE-2023-52340, CVE-2023-52843, CVE-2024-26593, CVE-2024-26865, CVE-2024-35910, CVE-2024-35955, CVE-2024-35960, CVE-2024-36941, CVE-2024-36971, CVE-2024-36978, CVE-2024-40980, CVE-2024-40981, CVE-2024-40995, CVE-2024-42285, CVE-2024-42301, CVE-2024-43817, CVE-2024-44940, CVE-2024-44944, CVE-2024-46759, CVE-2024-46762, CVE-2024-46779, CVE-2024-46804, CVE-2024-46813, CVE-2024-46815, CVE-2024-46837, CVE-2024-46842, CVE-2024-49894, CVE-2024-50035, CVE-2024-50067, CVE-2024-50073, CVE-2024-50125, CVE-2024-50131, CVE-2024-50299, CVE-2024-53142, CVE-2024-53173, CVE-2024-56631, CVE-2024-56650, CVE-2024-56659, CVE-2024-56662, CVE-2024-56690, CVE-2024-57850, CVE-2025-21700, CVE-2025-21760, CVE-2025-21791, CVE-2025-21858, CVE-2025-21892, CVE-2025-23141, CVE-2025-23144, CVE-2025-23145, CVE-2025-23147, CVE-2025-23149, CVE-2025-23151, CVE-2025-23163, CVE-2025-37739, CVE-2025-37752, CVE-2025-37754, CVE-2025-37755, CVE-2025-37756, CVE-2025-37757, CVE-2025-37767, CVE-2025-37769, CVE-2025-37771, CVE-2025-37772, CVE-2025-37773, CVE-2025-37776, CVE-2025-37784, CVE-2025-37786, CVE-2025-37787, CVE-2025-37788, CVE-2025-37789, CVE-2025-37792, CVE-2025-37794, CVE-2025-37798, CVE-2025-37841, CVE-2025-37844, CVE-2025-37849, CVE-2025-37853, CVE-2025-37854, CVE-2025-37863, CVE-2025-37864, CVE-2025-37865, CVE-2025-37867, CVE-2025-37871, CVE-2025-37874, CVE-2025-37875, CVE-2025-37889