Detections
Analytics

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

critical Nessus Plugin ID 276115

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:0438 advisory.

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

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

 arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array

 The loop that detects/populates cache information already has a bounds check on the array size but does not account for cache levels with separate data/instructions cache. Fix this by incrementing the index for any populated leaf (instead of any populated level).

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

 KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKEN

 Hide KVM's pt_mode module param behind CONFIG_BROKEN, i.e. disable support for virtualizing Intel PT via guest/host mode unless BROKEN=y. There are myriad bugs in the implementation, some of which are fatal to the guest, and others which put the stability and health of the host at risk.

 For guest fatalities, the most glaring issue is that KVM fails to ensure tracing is disabled, and *stays* disabled prior to VM-Enter, which is necessary as hardware disallows loading (the guest's) RTIT_CTL if tracing is enabled (enforced via a VMX consistency check). Per the SDM:

 If the logical processor is operating with Intel PT enabled (if IA32_RTIT_CTL.TraceEn = 1) at the time of VM entry, the load IA32_RTIT_CTL VM-entry control must be 0.

 On the host side, KVM doesn't validate the guest CPUID configuration provided by userspace, and even worse, uses the guest configuration to decide what MSRs to save/load at VM-Enter and VM-Exit. E.g. configuring guest CPUID to enumerate more address ranges than are supported in hardware will result in KVM trying to passthrough, save, and load non-existent MSRs, which generates a variety of WARNs, ToPA ERRORs in the host, a potential deadlock, etc.

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

 openvswitch: fix lockup on tx to unregistering netdev with carrier

 Commit in a fixes tag attempted to fix the issue in the following sequence of calls:

 do_output
 -> ovs_vport_send
 -> dev_queue_xmit
 -> __dev_queue_xmit
 -> netdev_core_pick_tx
 -> skb_tx_hash

 When device is unregistering, the 'dev->real_num_tx_queues' goes to zero and the 'while (unlikely(hash >= qcount))' loop inside the 'skb_tx_hash' becomes infinite, locking up the core forever.

 But unfortunately, checking just the carrier status is not enough to fix the issue, because some devices may still be in unregistering state while reporting carrier status OK.

 One example of such device is a net/dummy. It sets carrier ON on start, but it doesn't implement .ndo_stop to set the carrier off.
 And it makes sense, because dummy doesn't really have a carrier.
 Therefore, while this device is unregistering, it's still easy to hit the infinite loop in the skb_tx_hash() from the OVS datapath. There might be other drivers that do the same, but dummy by itself is important for the OVS ecosystem, because it is frequently used as a packet sink for tcpdump while debugging OVS deployments. And when the issue is hit, the only way to recover is to reboot.

 Fix that by also checking if the device is running. The running state is handled by the net core during unregistering, so it covers unregistering case better, and we don't really need to send packets to devices that are not running anyway.

 While only checking the running state might be enough, the carrier check is preserved. The running and the carrier states seem disjoined throughout the code and different drivers. And other core functions like __dev_direct_xmit() check both before attempting to transmit a packet. So, it seems safer to check both flags in OVS as well.

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

 net/mlx5e: Fix inversion dependency warning while enabling IPsec tunnel

 Attempt to enable IPsec packet offload in tunnel mode in debug kernel generates the following kernel panic, which is happening due to two issues:
 1. In SA add section, the should be _bh() variant when marking SA mode.
 2. There is not needed flush_workqueue in SA delete routine. It is not needed as at this stage as it is removed from SADB and the running work will be canceled later in SA free.

 ===================================================== WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected 6.12.0+ #4 Not tainted
 ----------------------------------------------------- charon/1337 [HC0[0]:SC0[4]:HE1:SE0] is trying to acquire:
 ffff88810f365020 (&xa->xa_lock#24){+.+.}-{3:3}, at: mlx5e_xfrm_del_state+0xca/0x1e0 [mlx5_core]

 and this task is already holding:
 ffff88813e0f0d48 (&x->lock){+.-.}-{3:3}, at: xfrm_state_delete+0x16/0x30 which would create a new lock dependency:
 (&x->lock){+.-.}-{3:3} -> (&xa->xa_lock#24){+.+.}-{3:3}

 but this new dependency connects a SOFTIRQ-irq-safe lock:
 (&x->lock){+.-.}-{3:3}

 ... which became SOFTIRQ-irq-safe at:
 lock_acquire+0x1be/0x520
 _raw_spin_lock_bh+0x34/0x40 xfrm_timer_handler+0x91/0xd70
 __hrtimer_run_queues+0x1dd/0xa60 hrtimer_run_softirq+0x146/0x2e0 handle_softirqs+0x266/0x860 irq_exit_rcu+0x115/0x1a0 sysvec_apic_timer_interrupt+0x6e/0x90 asm_sysvec_apic_timer_interrupt+0x16/0x20 default_idle+0x13/0x20 default_idle_call+0x67/0xa0 do_idle+0x2da/0x320 cpu_startup_entry+0x50/0x60 start_secondary+0x213/0x2a0 common_startup_64+0x129/0x138

 to a SOFTIRQ-irq-unsafe lock:
 (&xa->xa_lock#24){+.+.}-{3:3}

 ... which became SOFTIRQ-irq-unsafe at:
 ...
 lock_acquire+0x1be/0x520
 _raw_spin_lock+0x2c/0x40 xa_set_mark+0x70/0x110 mlx5e_xfrm_add_state+0xe48/0x2290 [mlx5_core] xfrm_dev_state_add+0x3bb/0xd70 xfrm_add_sa+0x2451/0x4a90 xfrm_user_rcv_msg+0x493/0x880 netlink_rcv_skb+0x12e/0x380 xfrm_netlink_rcv+0x6d/0x90 netlink_unicast+0x42f/0x740 netlink_sendmsg+0x745/0xbe0
 __sock_sendmsg+0xc5/0x190
 __sys_sendto+0x1fe/0x2c0
 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53

 other info that might help us debug this:

 Possible interrupt unsafe locking scenario:

 CPU0 CPU1
 ---- ---- lock(&xa->xa_lock#24);
 local_irq_disable();
 lock(&x->lock);
 lock(&xa->xa_lock#24);
 <Interrupt> lock(&x->lock);

 *** DEADLOCK ***

 2 locks held by charon/1337:
 #0: ffffffff87f8f858 (&net->xfrm.xfrm_cfg_mutex){+.+.}-{4:4}, at: xfrm_netlink_rcv+0x5e/0x90 #1: ffff88813e0f0d48 (&x->lock){+.-.}-{3:3}, at: xfrm_state_delete+0x16/0x30

 the dependencies between SOFTIRQ-irq-safe lock and the holding lock:
 -> (&x->lock){+.-.}-{3:3} ops: 29 { HARDIRQ-ON-W at:
 lock_acquire+0x1be/0x520
 _raw_spin_lock_bh+0x34/0x40 xfrm_alloc_spi+0xc0/0xe60 xfrm_alloc_userspi+0x5f6/0xbc0 xfrm_user_rcv_msg+0x493/0x880 netlink_rcv_skb+0x12e/0x380 xfrm_netlink_rcv+0x6d/0x90 netlink_unicast+0x42f/0x740 netlink_sendmsg+0x745/0xbe0
 __sock_sendmsg+0xc5/0x190
 __sys_sendto+0x1fe/0x2c0
 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53 IN-SOFTIRQ-W at:
 lock_acquire+0x1be/0x520
 _raw_spin_lock_bh+0x34/0x40 xfrm_timer_handler+0x91/0xd70
 __hrtimer_run_queues+0x1dd/0xa60

 ---truncated---

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

 wifi: ath10k: avoid NULL pointer error during sdio remove

 When running 'rmmod ath10k', ath10k_sdio_remove() will free sdio workqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON is set to yes, kernel panic will happen:
 Call trace:
 destroy_workqueue+0x1c/0x258 ath10k_sdio_remove+0x84/0x94 sdio_bus_remove+0x50/0x16c device_release_driver_internal+0x188/0x25c device_driver_detach+0x20/0x2c

 This is because during 'rmmod ath10k', ath10k_sdio_remove() will call ath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release() will finally be called in ath10k_core_destroy(). This function will free struct cfg80211_registered_device *rdev and all its members, including wiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio workqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.

 After device release, destroy_workqueue() will use NULL pointer then the kernel panic happen.

 Call trace:
 ath10k_sdio_remove
 ->ath10k_core_unregister
->ath10k_core_stop
 ->ath10k_hif_stop
 ->ath10k_sdio_irq_disable
 ->ath10k_hif_power_down
 ->del_timer_sync(&ar_sdio->sleep_timer)
 ->ath10k_core_destroy
 ->ath10k_mac_destroy
 ->ieee80211_free_hw
 ->wiphy_free
->wiphy_dev_release
 ->destroy_workqueue

 Need to call destroy_workqueue() before ath10k_core_destroy(), free the work queue buffer first and then free pointer of work queue by ath10k_core_destroy(). This order matches the error path order in ath10k_sdio_probe().

 No work will be queued on sdio workqueue between it is destroyed and ath10k_core_destroy() is called. Based on the call_stack above, the reason is:
 Only ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and ath10k_sdio_irq_disable() will queue work on sdio workqueue.
 Sleep timer will be deleted before ath10k_core_destroy() in ath10k_hif_power_down().
 ath10k_sdio_irq_disable() only be called in ath10k_hif_stop().
 ath10k_core_unregister() will call ath10k_hif_power_down() to stop hif bus, so ath10k_sdio_hif_tx_sg() won't be called anymore.

 Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189

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

 crypto: starfive - Do not free stack buffer

 RSA text data uses variable length buffer allocated in software stack.
 Calling kfree on it causes undefined behaviour in subsequent operations.

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

 block: fix resource leak in blk_register_queue() error path

 When registering a queue fails after blk_mq_sysfs_register() is successful but the function later encounters an error, we need to clean up the blk_mq_sysfs resources.

 Add the missing blk_mq_sysfs_unregister() call in the error path to properly clean up these resources and prevent a memory leak.

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

 objtool, media: dib8000: Prevent divide-by-zero in dib8000_set_dds()

 If dib8000_set_dds()'s call to dib8000_read32() returns zero, the result is a divide-by-zero. Prevent that from happening.

 Fixes the following warning with an UBSAN kernel:

 drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_tune() falls through to next function dib8096p_cfg_DibRx()

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

 udmabuf: fix a buf size overflow issue during udmabuf creation

 by casting size_limit_mb to u64 when calculate pglimit.

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

 scsi: ufs: mcq: Add NULL check in ufshcd_mcq_abort()

 A race can occur between the MCQ completion path and the abort handler:
 once a request completes, __blk_mq_free_request() sets rq->mq_hctx to NULL, meaning the subsequent ufshcd_mcq_req_to_hwq() call in ufshcd_mcq_abort() can return a NULL pointer. If this NULL pointer is dereferenced, the kernel will crash.

 Add a NULL check for the returned hwq pointer. If hwq is NULL, log an error and return FAILED, preventing a potential NULL-pointer dereference. As suggested by Bart, the ufshcd_cmd_inflight() check is removed.

 This is similar to the fix in commit 74736103fb41 (scsi: ufs: core: Fix ufshcd_abort_one racing issue).

 This is found by our static analysis tool KNighter.

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

 Bluetooth: btusb: avoid NULL pointer dereference in skb_dequeue()

 A NULL pointer dereference can occur in skb_dequeue() when processing a QCA firmware crash dump on WCN7851 (0489:e0f3).

 [ 93.672166] Bluetooth: hci0: ACL memdump size(589824)

 [ 93.672475] BUG: kernel NULL pointer dereference, address: 0000000000000008 [ 93.672517] Workqueue: hci0 hci_devcd_rx [bluetooth] [ 93.672598] RIP: 0010:skb_dequeue+0x50/0x80

 The issue stems from handle_dump_pkt_qca() returning 0 even when a dump packet is successfully processed. This is because it incorrectly forwards the return value of hci_devcd_init() (which returns 0 on success). As a result, the caller (btusb_recv_acl_qca() or btusb_recv_evt_qca()) assumes the packet was not handled and passes it to hci_recv_frame(), leading to premature kfree() of the skb.

 Later, hci_devcd_rx() attempts to dequeue the same skb from the dump queue, resulting in a NULL pointer dereference.

 Fix this by:
 1. Making handle_dump_pkt_qca() return 0 on success and negative errno on failure, consistent with kernel conventions.
 2. Splitting dump packet detection into separate functions for ACL and event packets for better structure and readability.

 This ensures dump packets are properly identified and consumed, avoiding double handling and preventing NULL pointer access.

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

 9p/net: fix improper handling of bogus negative read/write replies

 In p9_client_write() and p9_client_read_once(), if the server incorrectly replies with success but a negative write/read count then we would consider written (negative) <= rsize (positive) because both variables were signed.

 Make variables unsigned to avoid this problem.

 The reproducer linked below now fails with the following error instead of a null pointer deref:
 9pnet: bogus RWRITE count (4294967295 > 3)

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

 usb: cdns3: Fix deadlock when using NCM gadget

 The cdns3 driver has the same NCM deadlock as fixed in cdnsp by commit 58f2fcb3a845 (usb: cdnsp: Fix deadlock issue during using NCM gadget).

 Under PREEMPT_RT the deadlock can be readily triggered by heavy network traffic, for example using iperf --bidir over NCM ethernet link.

 The deadlock occurs because the threaded interrupt handler gets preempted by a softirq, but both are protected by the same spinlock.
 Prevent deadlock by disabling softirq during threaded irq handler.

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

 ext4: fix OOB read when checking dotdot dir

 Mounting a corrupted filesystem with directory which contains '.' dir entry with rec_len == block size results in out-of-bounds read (later on, when the corrupted directory is removed).

 ext4_empty_dir() assumes every ext4 directory contains at least '.' and '..' as directory entries in the first data block. It first loads the '.' dir entry, performs sanity checks by calling ext4_check_dir_entry() and then uses its rec_len member to compute the location of '..' dir entry (in ext4_next_entry). It assumes the '..' dir entry fits into the same data block.

 If the rec_len of '.' is precisely one block (4KB), it slips through the sanity checks (it is considered the last directory entry in the data block) and leaves struct ext4_dir_entry_2 *de point exactly past the memory slot allocated to the data block. The following call to ext4_check_dir_entry() on new value of de then dereferences this pointer which results in out-of-bounds mem access.

 Fix this by extending __ext4_check_dir_entry() to check for '.' dir entries that reach the end of data block. Make sure to ignore the phony dir entries for checksum (by checking name_len for non-zero).

 Note: This is reported by KASAN as use-after-free in case another structure was recently freed from the slot past the bound, but it is really an OOB read.

 This issue was found by syzkaller tool.

 Call Trace:
 [ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710 [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375 [ 38.595158] [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1 [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 38.595304] Call Trace:
 [ 38.595308] <TASK> [ 38.595311] dump_stack_lvl+0xa7/0xd0 [ 38.595325] print_address_description.constprop.0+0x2c/0x3f0 [ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595349] print_report+0xaa/0x250 [ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595368] ? kasan_addr_to_slab+0x9/0x90 [ 38.595378] kasan_report+0xab/0xe0 [ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595400] __ext4_check_dir_entry+0x67e/0x710 [ 38.595410] ext4_empty_dir+0x465/0x990 [ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10 [ 38.595432] ext4_rmdir.part.0+0x29a/0xd10 [ 38.595441] ? __dquot_initialize+0x2a7/0xbf0 [ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10 [ 38.595464] ? __pfx___dquot_initialize+0x10/0x10 [ 38.595478] ? down_write+0xdb/0x140 [ 38.595487] ? __pfx_down_write+0x10/0x10 [ 38.595497] ext4_rmdir+0xee/0x140 [ 38.595506] vfs_rmdir+0x209/0x670 [ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190 [ 38.595529] do_rmdir+0x363/0x3c0 [ 38.595537] ? __pfx_do_rmdir+0x10/0x10 [ 38.595544] ? strncpy_from_user+0x1ff/0x2e0 [ 38.595561] __x64_sys_unlinkat+0xf0/0x130 [ 38.595570] do_syscall_64+0x5b/0x180 [ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e

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

 net: ppp: Add bound checking for skb data on ppp_sync_txmung

 Ensure we have enough data in linear buffer from skb before accessing initial bytes. This prevents potential out-of-bounds accesses when processing short packets.

 When ppp_sync_txmung receives an incoming package with an empty payload:
 (remote) gef p *(struct pppoe_hdr *) (skb->head + skb->network_header) $18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96 }

 from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 4, data = 0xffff88803346f416 :\377, truesize = 0x380, len = 0x0, data_len = 0x0, mac_len = 0xe, hdr_len = 0x0,

 it is not safe to access data[2].

 [[email protected]: fixed subj typo]

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

 jfs: Fix uninit-value access of imap allocated in the diMount() function

 syzbot reports that hex_dump_to_buffer is using uninit-value:

 ===================================================== BUG: KMSAN: uninit-value in hex_dump_to_buffer+0x888/0x1100 lib/hexdump.c:171 hex_dump_to_buffer+0x888/0x1100 lib/hexdump.c:171 print_hex_dump+0x13d/0x3e0 lib/hexdump.c:276 diFree+0x5ba/0x4350 fs/jfs/jfs_imap.c:876 jfs_evict_inode+0x510/0x550 fs/jfs/inode.c:156 evict+0x723/0xd10 fs/inode.c:796 iput_final fs/inode.c:1946 [inline] iput+0x97b/0xdb0 fs/inode.c:1972 txUpdateMap+0xf3e/0x1150 fs/jfs/jfs_txnmgr.c:2367 txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline] jfs_lazycommit+0x627/0x11d0 fs/jfs/jfs_txnmgr.c:2733 kthread+0x6b9/0xef0 kernel/kthread.c:464 ret_from_fork+0x6d/0x90 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

 Uninit was created at:
 slab_post_alloc_hook mm/slub.c:4121 [inline] slab_alloc_node mm/slub.c:4164 [inline]
 __kmalloc_cache_noprof+0x8e3/0xdf0 mm/slub.c:4320 kmalloc_noprof include/linux/slab.h:901 [inline] diMount+0x61/0x7f0 fs/jfs/jfs_imap.c:105 jfs_mount+0xa8e/0x11d0 fs/jfs/jfs_mount.c:176 jfs_fill_super+0xa47/0x17c0 fs/jfs/super.c:523 get_tree_bdev_flags+0x6ec/0x910 fs/super.c:1636 get_tree_bdev+0x37/0x50 fs/super.c:1659 jfs_get_tree+0x34/0x40 fs/jfs/super.c:635 vfs_get_tree+0xb1/0x5a0 fs/super.c:1814 do_new_mount+0x71f/0x15e0 fs/namespace.c:3560 path_mount+0x742/0x1f10 fs/namespace.c:3887 do_mount fs/namespace.c:3900 [inline]
 __do_sys_mount fs/namespace.c:4111 [inline]
 __se_sys_mount+0x71f/0x800 fs/namespace.c:4088
 __x64_sys_mount+0xe4/0x150 fs/namespace.c:4088 x64_sys_call+0x39bf/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:166 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 =====================================================

 The reason is that imap is not properly initialized after memory allocation. It will cause the snprintf() function to write uninitialized data into linebuf within hex_dump_to_buffer().

 Fix this by using kzalloc instead of kmalloc to clear its content at the beginning in diMount().

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

 jfs: add sanity check for agwidth in dbMount

 The width in dmapctl of the AG is zero, it trigger a divide error when calculating the control page level in dbAllocAG.

 To avoid this issue, add a check for agwidth in dbAllocAG.

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

 ext4: fix off-by-one error in do_split

 Syzkaller detected a use-after-free issue in ext4_insert_dentry that was caused by out-of-bounds access due to incorrect splitting in do_split.

 BUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847

 CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189
 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154 make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455 ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796 ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431 vfs_symlink+0x137/0x2e0 fs/namei.c:4615 do_symlinkat+0x222/0x3a0 fs/namei.c:4641
 __do_sys_symlink fs/namei.c:4662 [inline]
 __se_sys_symlink fs/namei.c:4660 [inline]
 __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK>

 The following loop is located right above 'if' statement.

 for (i = count-1; i >= 0; i--) { /* is more than half of this entry in 2nd half of the block? */ if (size + map[i].size/2 > blocksize/2) break;
 size += map[i].size;
 move++;
 }

 'i' in this case could go down to -1, in which case sum of active entries wouldn't exceed half the block size, but previous behaviour would also do split in half if sum would exceed at the very last block, which in case of having too many long name files in a single block could lead to out-of-bounds access and following use-after-free.

 Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

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

 ocfs2: validate l_tree_depth to avoid out-of-bounds access

 The l_tree_depth field is 16-bit (__le16), but the actual maximum depth is limited to OCFS2_MAX_PATH_DEPTH.

 Add a check to prevent out-of-bounds access if l_tree_depth has an invalid value, which may occur when reading from a corrupted mounted disk [1].

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

 eth: bnxt: fix truesize for mb-xdp-pass case

 When mb-xdp is set and return is XDP_PASS, packet is converted from xdp_buff to sk_buff with xdp_update_skb_shared_info() in bnxt_xdp_build_skb().
 bnxt_xdp_build_skb() passes incorrect truesize argument to xdp_update_skb_shared_info().
 The truesize is calculated as BNXT_RX_PAGE_SIZE * sinfo->nr_frags but the skb_shared_info was wiped by napi_build_skb() before.
 So it stores sinfo->nr_frags before bnxt_xdp_build_skb() and use it instead of getting skb_shared_info from xdp_get_shared_info_from_buff().

 Splat looks like:
 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 0 at net/core/skbuff.c:6072 skb_try_coalesce+0x504/0x590 Modules linked in: xt_nat xt_tcpudp veth af_packet xt_conntrack nft_chain_nat xt_MASQUERADE nf_conntrack_netlink xfrm_user xt_addrtype nft_coms CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.14.0-rc2+ #3 RIP: 0010:skb_try_coalesce+0x504/0x590 Code: 4b fd ff ff 49 8b 34 24 40 80 e6 40 0f 84 3d fd ff ff 49 8b 74 24 48 40 f6 c6 01 0f 84 2e fd ff ff 48 8d 4e ff e9 25 fd ff ff <0f> 0b e99 RSP: 0018:ffffb62c4120caa8 EFLAGS: 00010287 RAX: 0000000000000003 RBX: ffffb62c4120cb14 RCX: 0000000000000ec0 RDX: 0000000000001000 RSI: ffffa06e5d7dc000 RDI: 0000000000000003 RBP: ffffa06e5d7ddec0 R08: ffffa06e6120a800 R09: ffffa06e7a119900 R10: 0000000000002310 R11: ffffa06e5d7dcec0 R12: ffffe4360575f740 R13: ffffe43600000000 R14: 0000000000000002 R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffffa0755f700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f147b76b0f8 CR3: 00000001615d4000 CR4: 00000000007506f0 PKRU: 55555554 Call Trace:
 <IRQ> ? __warn+0x84/0x130 ? skb_tr ...

 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-20250438.xml

Plugin Details

Severity: Critical

ID: 276115

File Name: tencentos_TSSA_2025_0438.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: 9.4

Temporal Score: 7

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

CVSS Score Source: CVE-2024-47685

CVSS v3

Risk Factor: Critical

Base Score: 9.1

Temporal Score: 7.9

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

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

Vulnerability Information

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

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

Exploit Ease: No known exploits are available

Patch Publication Date: 7/8/2025

Vulnerability Publication Date: 7/21/2021

Reference Information

CVE: CVE-2022-49030, CVE-2022-49109, CVE-2022-49296, CVE-2022-49828, CVE-2022-49901, CVE-2023-52670, CVE-2024-26756, CVE-2024-26813, CVE-2024-39478, CVE-2024-39480, CVE-2024-41023, CVE-2024-41045, CVE-2024-42068, CVE-2024-42112, CVE-2024-42131, CVE-2024-42148, CVE-2024-46731, CVE-2024-46740, CVE-2024-46818, CVE-2024-46834, CVE-2024-47685, CVE-2024-53099, CVE-2024-53135, CVE-2024-53227, CVE-2024-53685, CVE-2024-56599, CVE-2024-56664, CVE-2024-56703, CVE-2024-57883, CVE-2024-57924, CVE-2025-21671, CVE-2025-21674, CVE-2025-21681, CVE-2025-21702, CVE-2025-21731, CVE-2025-21785, CVE-2025-21926, CVE-2025-21961, CVE-2025-22070, CVE-2025-22079, CVE-2025-23142, CVE-2025-23150, CVE-2025-23156, CVE-2025-37738, CVE-2025-37740, CVE-2025-37741, CVE-2025-37742, CVE-2025-37749, CVE-2025-37777, CVE-2025-37780, CVE-2025-37785, CVE-2025-37803, CVE-2025-37805, CVE-2025-37807, CVE-2025-37812, CVE-2025-37819, CVE-2025-37828, CVE-2025-37836, CVE-2025-37839, CVE-2025-37861, CVE-2025-37870, CVE-2025-37878, CVE-2025-37879, CVE-2025-37884, CVE-2025-37885, CVE-2025-37886, CVE-2025-37891, CVE-2025-37911, CVE-2025-37914, CVE-2025-37918, CVE-2025-37921, CVE-2025-37929, CVE-2025-37936, CVE-2025-37937, CVE-2025-37940, CVE-2025-37948, CVE-2025-37954, CVE-2025-37957, CVE-2025-37958, CVE-2025-37960, CVE-2025-37963, CVE-2025-37964, CVE-2025-37969, CVE-2025-37970, CVE-2025-37977, CVE-2025-37979, CVE-2025-37980, CVE-2025-37984, CVE-2025-37985, CVE-2025-37992