Detections
Analytics

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

high Nessus Plugin ID 275906

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

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

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

 ALSA: pcm: Fix races among concurrent hw_params and hw_free calls

 Currently we have neither proper check nor protection against the concurrent calls of PCM hw_params and hw_free ioctls, which may result in a UAF. Since the existing PCM stream lock can't be used for protecting the whole ioctl operations, we need a new mutex to protect those racy calls.

 This patch introduced a new mutex, runtime->buffer_mutex, and applies it to both hw_params and hw_free ioctl code paths. Along with it, the both functions are slightly modified (the mmap_count check is moved into the state-check block) for code simplicity.

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

 ASoC: rt5645: Fix errorenous cleanup order

 There is a logic error when removing rt5645 device as the function rt5645_i2c_remove() first cancel the &rt5645->jack_detect_work and delete the &rt5645->btn_check_timer latter. However, since the timer handler rt5645_btn_check_callback() will re-queue the jack_detect_work, this cleanup order is buggy.

 That is, once the del_timer_sync in rt5645_i2c_remove is concurrently run with the rt5645_btn_check_callback, the canceled jack_detect_work will be rescheduled again, leading to possible use-after-free.

 This patch fix the issue by placing the del_timer_sync function before the cancel_delayed_work_sync.

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

 ASoC: SOF: ipc3-topology: Correct get_control_data for non bytes payload

 It is possible to craft a topology where sof_get_control_data() would do out of bounds access because it expects that it is only called when the payload is bytes type.
 Confusingly it also handles other types of controls, but the payload parsing implementation is only valid for bytes.

 Fix the code to count the non bytes controls and instead of storing a pointer to sof_abi_hdr in sof_widget_data (which is only valid for bytes), store the pointer to the data itself and add a new member to save the size of the data.

 In case of non bytes controls we store the pointer to the chanv itself, which is just an array of values at the end.

 In case of bytes control, drop the wrong cdata->data (wdata[i].pdata) check against NULL since it is incorrect and invalid in this context.
 The data is pointing to the end of cdata struct, so it should never be null.

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

 pps: Fix a use-after-free

 On a board running ntpd and gpsd, I'm seeing a consistent use-after-free in sys_exit() from gpsd when rebooting:

 pps pps1: removed
 ------------[ cut here ]------------ kobject: '(null)' (00000000db4bec24): is not initialized, yet kobject_put() is being called.
 WARNING: CPU: 2 PID: 440 at lib/kobject.c:734 kobject_put+0x120/0x150 CPU: 2 UID: 299 PID: 440 Comm: gpsd Not tainted 6.11.0-rc6-00308-gb31c44928842 #1 Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kobject_put+0x120/0x150 lr : kobject_put+0x120/0x150 sp : ffffffc0803d3ae0 x29: ffffffc0803d3ae0 x28: ffffff8042dc9738 x27: 0000000000000001 x26: 0000000000000000 x25: ffffff8042dc9040 x24: ffffff8042dc9440 x23: ffffff80402a4620 x22: ffffff8042ef4bd0 x21: ffffff80405cb600 x20: 000000000008001b x19: ffffff8040b3b6e0 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 696e6920746f6e20 x14: 7369203a29343263 x13: 205d303434542020 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace:
 kobject_put+0x120/0x150 cdev_put+0x20/0x3c
 __fput+0x2c4/0x2d8
 ____fput+0x1c/0x38 task_work_run+0x70/0xfc do_exit+0x2a0/0x924 do_group_exit+0x34/0x90 get_signal+0x7fc/0x8c0 do_signal+0x128/0x13b4 do_notify_resume+0xdc/0x160 el0_svc+0xd4/0xf8 el0t_64_sync_handler+0x140/0x14c el0t_64_sync+0x190/0x194
 ---[ end trace 0000000000000000 ]---

 ...followed by more symptoms of corruption, with similar stacks:

 refcount_t: underflow; use-after-free.
 kernel BUG at lib/list_debug.c:62! Kernel panic - not syncing: Oops - BUG: Fatal exception

 This happens because pps_device_destruct() frees the pps_device with the embedded cdev immediately after calling cdev_del(), but, as the comment above cdev_del() notes, fops for previously opened cdevs are still callable even after cdev_del() returns. I think this bug has always been there: I can't explain why it suddenly started happening every time I reboot this particular board.

 In commit d953e0e837e6 (pps: Fix a use-after free bug when unregistering a source.), George Spelvin suggested removing the embedded cdev. That seems like the simplest way to fix this, so I've implemented his suggestion, using __register_chrdev() with pps_idr becoming the source of truth for which minor corresponds to which device.

 But now that pps_idr defines userspace visibility instead of cdev_add(), we need to be sure the pps->dev refcount can't reach zero while userspace can still find it again. So, the idr_remove() call moves to pps_unregister_cdev(), and pps_idr now holds a reference to pps->dev.

 pps_core: source serial1 got cdev (251:1) <...> pps pps1: removed pps_core: unregistering pps1 pps_core: deallocating pps1

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

 openvswitch: use RCU protection in ovs_vport_cmd_fill_info()

 ovs_vport_cmd_fill_info() can be called without RTNL or RCU.

 Use RCU protection and dev_net_rcu() to avoid potential UAF.

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

 arp: use RCU protection in arp_xmit()

 arp_xmit() can be called without RTNL or RCU protection.

 Use RCU protection to avoid potential UAF.

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

 ndisc: use RCU protection in ndisc_alloc_skb()

 ndisc_alloc_skb() can be called without RTNL or RCU being held.

 Add RCU protection to avoid possible UAF.

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

 ipv6: use RCU protection in ip6_default_advmss()

 ip6_default_advmss() needs rcu protection to make sure the net structure it reads does not disappear.

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

 batman-adv: fix panic during interface removal

 Reference counting is used to ensure that batadv_hardif_neigh_node and batadv_hard_iface are not freed before/during batadv_v_elp_throughput_metric_update work is finished.

 But there isn't a guarantee that the hard if will remain associated with a soft interface up until the work is finished.

 This fixes a crash triggered by reboot that looks like this:

 Call trace:
 batadv_v_mesh_free+0xd0/0x4dc [batman_adv] batadv_v_elp_throughput_metric_update+0x1c/0xa4 process_one_work+0x178/0x398 worker_thread+0x2e8/0x4d0 kthread+0xd8/0xdc ret_from_fork+0x10/0x20

 (the batadv_v_mesh_free call is misleading, and does not actually happen)

 I was able to make the issue happen more reliably by changing hardif_neigh->bat_v.metric_work work to be delayed work. This allowed me to track down and confirm the fix.

 [[email protected]: prevent entering batadv_v_elp_get_throughput without soft_iface]

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

 orangefs: fix a oob in orangefs_debug_write

 I got a syzbot report: slab-out-of-bounds Read in orangefs_debug_write... several people suggested fixes, I tested Al Viro's suggestion and made this patch.

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

 drm/amdgpu: bail out when failed to load fw in psp_init_cap_microcode()

 In function psp_init_cap_microcode(), it should bail out when failed to load firmware, otherwise it may cause invalid memory access.

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

 team: better TEAM_OPTION_TYPE_STRING validation

 syzbot reported following splat [1]

 Make sure user-provided data contains one nul byte.

 [1] BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:633 [inline] BUG: KMSAN: uninit-value in string+0x3ec/0x5f0 lib/vsprintf.c:714 string_nocheck lib/vsprintf.c:633 [inline] string+0x3ec/0x5f0 lib/vsprintf.c:714 vsnprintf+0xa5d/0x1960 lib/vsprintf.c:2843
 __request_module+0x252/0x9f0 kernel/module/kmod.c:149 team_mode_get drivers/net/team/team_core.c:480 [inline] team_change_mode drivers/net/team/team_core.c:607 [inline] team_mode_option_set+0x437/0x970 drivers/net/team/team_core.c:1401 team_option_set drivers/net/team/team_core.c:375 [inline] team_nl_options_set_doit+0x1339/0x1f90 drivers/net/team/team_core.c:2662 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x1214/0x12c0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2543 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:718 [inline]
 __sock_sendmsg+0x30f/0x380 net/socket.c:733
 ____sys_sendmsg+0x877/0xb60 net/socket.c:2573
 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2627
 __sys_sendmsg net/socket.c:2659 [inline]
 __do_sys_sendmsg net/socket.c:2664 [inline]
 __se_sys_sendmsg net/socket.c:2662 [inline]
 __x64_sys_sendmsg+0x212/0x3c0 net/socket.c:2662 x64_sys_call+0x2ed6/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:47 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

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

 LoongArch: csum: Fix OoB access in IP checksum code for negative lengths

 Commit 69e3a6aa6be2 (LoongArch: Add checksum optimization for 64-bit system) would cause an undefined shift and an out-of-bounds read.

 Commit 8bd795fedb84 (arm64: csum: Fix OoB access in IP checksum code for negative lengths) fixes the same issue on ARM64.

 CVE-2021-47659:
 In the Linux kernel, the following vulnerability has been resolved:

 vxlan: check vxlan_vnigroup_init() return value

 vxlan_init() must check vxlan_vnigroup_init() success otherwise a crash happens later, spotted by syzbot.

 Oops: general protection fault, probably for non-canonical address 0xdffffc000000002c: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000160-0x0000000000000167] CPU: 0 UID: 0 PID: 7313 Comm: syz-executor147 Not tainted 6.14.0-rc1-syzkaller-00276-g69b54314c975 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:vxlan_vnigroup_uninit+0x89/0x500 drivers/net/vxlan/vxlan_vnifilter.c:912 Code: 00 48 8b 44 24 08 4c 8b b0 98 41 00 00 49 8d 86 60 01 00 00 48 89 c2 48 89 44 24 10 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4d 04 00 00 49 8b 86 60 01 00 00 48 ba 00 00 00 RSP: 0018:ffffc9000cc1eea8 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000001 RCX: ffffffff8672effb RDX: 000000000000002c RSI: ffffffff8672ecb9 RDI: ffff8880461b4f18 RBP: ffff8880461b4ef4 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000020000 R13: ffff8880461b0d80 R14: 0000000000000000 R15: dffffc0000000000 FS: 00007fecfa95d6c0(0000) GS:ffff88806a600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fecfa95cfb8 CR3: 000000004472c000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:
 <TASK> vxlan_uninit+0x1ab/0x200 drivers/net/vxlan/vxlan_core.c:2942 unregister_netdevice_many_notify+0x12d6/0x1f30 net/core/dev.c:11824 unregister_netdevice_many net/core/dev.c:11866 [inline] unregister_netdevice_queue+0x307/0x3f0 net/core/dev.c:11736 register_netdevice+0x1829/0x1eb0 net/core/dev.c:10901
 __vxlan_dev_create+0x7c6/0xa30 drivers/net/vxlan/vxlan_core.c:3981 vxlan_newlink+0xd1/0x130 drivers/net/vxlan/vxlan_core.c:4407 rtnl_newlink_create net/core/rtnetlink.c:3795 [inline]
 __rtnl_newlink net/core/rtnetlink.c:3906 [inline]

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

 ax25: Fix refcount leak caused by setting SO_BINDTODEVICE sockopt

 If an AX25 device is bound to a socket by setting the SO_BINDTODEVICE socket option, a refcount leak will occur in ax25_release().

 Commit 9fd75b66b8f6 (ax25: Fix refcount leaks caused by ax25_cb_del()) added decrement of device refcounts in ax25_release(). In order for that to work correctly the refcounts must already be incremented when the device is bound to the socket. An AX25 device can be bound to a socket by either calling ax25_bind() or setting SO_BINDTODEVICE socket option.
 In both cases the refcounts should be incremented, but in fact it is done only in ax25_bind().

 This bug leads to the following issue reported by Syzkaller:

 ================================================================ refcount_t: decrement hit 0; leaking memory.
 WARNING: CPU: 1 PID: 5932 at lib/refcount.c:31 refcount_warn_saturate+0x1ed/0x210 lib/refcount.c:31 Modules linked in:
 CPU: 1 UID: 0 PID: 5932 Comm: syz-executor424 Not tainted 6.13.0-rc4-syzkaller-00110-g4099a71718b0 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:refcount_warn_saturate+0x1ed/0x210 lib/refcount.c:31 Call Trace:
 <TASK>
 __refcount_dec include/linux/refcount.h:336 [inline] refcount_dec include/linux/refcount.h:351 [inline] ref_tracker_free+0x710/0x820 lib/ref_tracker.c:236 netdev_tracker_free include/linux/netdevice.h:4156 [inline] netdev_put include/linux/netdevice.h:4173 [inline] netdev_put include/linux/netdevice.h:4169 [inline] ax25_release+0x33f/0xa10 net/ax25/af_ax25.c:1069
 __sock_release+0xb0/0x270 net/socket.c:640 sock_close+0x1c/0x30 net/socket.c:1408 ...
 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f ...
 </TASK> ================================================================

 Fix the implementation of ax25_setsockopt() by adding increment of refcounts for the new device bound, and decrement of refcounts for the old unbound device.

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

 video: fbdev: cirrusfb: check pixclock to avoid divide by zero

 Do a sanity check on pixclock value to avoid divide by zero.

 If the pixclock value is zero, the cirrusfb driver will round up pixclock to get the derived frequency as close to maxclock as possible.

 Syzkaller reported a divide error in cirrusfb_check_pixclock.

 divide error: 0000 [#1] SMP KASAN PTI CPU: 0 PID: 14938 Comm: cirrusfb_test Not tainted 5.15.0-rc6 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2 RIP: 0010:cirrusfb_check_var+0x6f1/0x1260

 Call Trace:
 fb_set_var+0x398/0xf90 do_fb_ioctl+0x4b8/0x6f0 fb_ioctl+0xeb/0x130
 __x64_sys_ioctl+0x19d/0x220 do_syscall_64+0x3a/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae

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

 drm/plane: Move range check for format_count earlier

 While the check for format_count > 64 in __drm_universal_plane_init() shouldn't be hit (it's a WARN_ON), in its current position it will then leak the plane->format_types array and fail to call drm_mode_object_unregister() leaking the modeset identifier. Move it to the start of the function to avoid allocating those resources in the first place.

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

 fbdev: Fix unregistering of framebuffers without device

 OF framebuffers do not have an underlying device in the Linux device hierarchy. Do a regular unregister call instead of hot unplugging such a non-existing device. Fixes a NULL dereference.
 An example error message on ppc64le is shown below.

 BUG: Kernel NULL pointer dereference on read at 0x00000060 Faulting instruction address: 0xc00000000080dfa4 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries [...] CPU: 2 PID: 139 Comm: systemd-udevd Not tainted 5.17.0-ae085d7f9365 #1 NIP: c00000000080dfa4 LR: c00000000080df9c CTR: c000000000797430 REGS: c000000004132fe0 TRAP: 0300 Not tainted (5.17.0-ae085d7f9365) MSR: 8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR: 28228282 XER: 20000000 CFAR: c00000000000c80c DAR: 0000000000000060 DSISR: 40000000 IRQMASK: 0 GPR00: c00000000080df9c c000000004133280 c00000000169d200 0000000000000029 GPR04: 00000000ffffefff c000000004132f90 c000000004132f88 0000000000000000 GPR08: c0000000015658f8 c0000000015cd200 c0000000014f57d0 0000000048228283 GPR12: 0000000000000000 c00000003fffe300 0000000020000000 0000000000000000 GPR16: 0000000000000000 0000000113fc4a40 0000000000000005 0000000113fcfb80 GPR20: 000001000f7283b0 0000000000000000 c000000000e4a588 c000000000e4a5b0 GPR24: 0000000000000001 00000000000a0000 c008000000db0168 c0000000021f6ec0 GPR28: c0000000016d65a8 c000000004b36460 0000000000000000 c0000000016d64b0 NIP [c00000000080dfa4] do_remove_conflicting_framebuffers+0x184/0x1d0 [c000000004133280] [c00000000080df9c] do_remove_conflicting_framebuffers+0x17c/0x1d0 (unreliable) [c000000004133350] [c00000000080e4d0] remove_conflicting_framebuffers+0x60/0x150 [c0000000041333a0] [c00000000080e6f4] remove_conflicting_pci_framebuffers+0x134/0x1b0 [c000000004133450] [c008000000e70438] drm_aperture_remove_conflicting_pci_framebuffers+0x90/0x100 [drm] [c000000004133490] [c008000000da0ce4] bochs_pci_probe+0x6c/0xa64 [bochs] [...] [c000000004133db0] [c00000000002aaa0] system_call_exception+0x170/0x2d0 [c000000004133e10] [c00000000000c3cc] system_call_common+0xec/0x250

 The bug [1] was introduced by commit 27599aacbaef (fbdev: Hot-unplug firmware fb devices on forced removal). Most firmware framebuffers have an underlying platform device, which can be hot-unplugged before loading the native graphics driver. OF framebuffers do not (yet) have that device. Fix the code by unregistering the framebuffer as before without a hot unplug.

 Tested with 5.17 on qemu ppc64le emulation.

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

 Bluetooth: use memset avoid memory leaks

 Use memset to initialize structs to prevent memory leaks in l2cap_ecred_connect

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

 f2fs: use spin_lock to avoid hang

 [14696.634553] task:cat state:D stack: 0 pid:1613738 ppid:1613735 flags:0x00000004 [14696.638285] Call Trace:
 [14696.639038] <TASK> [14696.640032] __schedule+0x302/0x930 [14696.640969] schedule+0x58/0xd0 [14696.641799] schedule_preempt_disabled+0x18/0x30 [14696.642890] __mutex_lock.constprop.0+0x2fb/0x4f0 [14696.644035] ? mod_objcg_state+0x10c/0x310 [14696.645040] ? obj_cgroup_charge+0xe1/0x170 [14696.646067] __mutex_lock_slowpath+0x13/0x20 [14696.647126] mutex_lock+0x34/0x40 [14696.648070] stat_show+0x25/0x17c0 [f2fs] [14696.649218] seq_read_iter+0x120/0x4b0 [14696.650289] ? aa_file_perm+0x12a/0x500 [14696.651357] ? lru_cache_add+0x1c/0x20 [14696.652470] seq_read+0xfd/0x140 [14696.653445] full_proxy_read+0x5c/0x80 [14696.654535] vfs_read+0xa0/0x1a0 [14696.655497] ksys_read+0x67/0xe0 [14696.656502] __x64_sys_read+0x1a/0x20 [14696.657580] do_syscall_64+0x3b/0xc0 [14696.658671] entry_SYSCALL_64_after_hwframe+0x44/0xae [14696.660068] RIP: 0033:0x7efe39df1cb2 [14696.661133] RSP: 002b:00007ffc8badd948 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [14696.662958] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007efe39df1cb2 [14696.664757] RDX: 0000000000020000 RSI: 00007efe399df000 RDI: 0000000000000003 [14696.666542] RBP: 00007efe399df000 R08: 00007efe399de010 R09: 00007efe399de010 [14696.668363] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000000000 [14696.670155] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000 [14696.671965] </TASK> [14696.672826] task:umount state:D stack: 0 pid:1614985 ppid:1614984 flags:0x00004000 [14696.674930] Call Trace:
 [14696.675903] <TASK> [14696.676780] __schedule+0x302/0x930 [14696.677927] schedule+0x58/0xd0 [14696.679019] schedule_preempt_disabled+0x18/0x30 [14696.680412] __mutex_lock.constprop.0+0x2fb/0x4f0 [14696.681783] ? destroy_inode+0x65/0x80 [14696.683006] __mutex_lock_slowpath+0x13/0x20 [14696.684305] mutex_lock+0x34/0x40 [14696.685442] f2fs_destroy_stats+0x1e/0x60 [f2fs] [14696.686803] f2fs_put_super+0x158/0x390 [f2fs] [14696.688238] generic_shutdown_super+0x7a/0x120 [14696.689621] kill_block_super+0x27/0x50 [14696.690894] kill_f2fs_super+0x7f/0x100 [f2fs] [14696.692311] deactivate_locked_super+0x35/0xa0 [14696.693698] deactivate_super+0x40/0x50 [14696.694985] cleanup_mnt+0x139/0x190 [14696.696209] __cleanup_mnt+0x12/0x20 [14696.697390] task_work_run+0x64/0xa0 [14696.698587] exit_to_user_mode_prepare+0x1b7/0x1c0 [14696.700053] syscall_exit_to_user_mode+0x27/0x50 [14696.701418] do_syscall_64+0x48/0xc0 [14696.702630] entry_SYSCALL_64_after_hwframe+0x44/0xae

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

 NFSD: prevent integer overflow on 32 bit systems

 On a 32 bit system, the len * sizeof(*p) operation can have an integer overflow.

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

 ext4: fix use-after-free in ext4_rename_dir_prepare

 We got issue as follows:
 EXT4-fs (loop0): mounted filesystem without journal. Opts: ,errors=continue ext4_get_first_dir_block: bh->b_data=0xffff88810bee6000 len=34478 ext4_get_first_dir_block: *parent_de=0xffff88810beee6ae bh->b_data=0xffff88810bee6000 ext4_rename_dir_prepare: [1] parent_de=0xffff88810beee6ae ================================================================== BUG: KASAN: use-after-free in ext4_rename_dir_prepare+0x152/0x220 Read of size 4 at addr ffff88810beee6ae by task rep/1895

 CPU: 13 PID: 1895 Comm: rep Not tainted 5.10.0+ #241 Call Trace:
 dump_stack+0xbe/0xf9 print_address_description.constprop.0+0x1e/0x220 kasan_report.cold+0x37/0x7f ext4_rename_dir_prepare+0x152/0x220 ext4_rename+0xf44/0x1ad0 ext4_rename2+0x11c/0x170 vfs_rename+0xa84/0x1440 do_renameat2+0x683/0x8f0
 __x64_sys_renameat+0x53/0x60 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f45a6fc41c9 RSP: 002b:00007ffc5a470218 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f45a6fc41c9 RDX: 0000000000000005 RSI: 0000000020000180 RDI: 0000000000000005 RBP: 00007ffc5a470240 R08: 00007ffc5a470160 R09: 0000000020000080 R10: 00000000200001c0 R11: 0000000000000246 R12: 0000000000400bb0 R13: 00007ffc5a470320 R14: 0000000000000000 R15: 0000000000000000

 The buggy address belongs to the page:
 page:00000000440015ce refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x10beee flags: 0x200000000000000() raw: 0200000000000000 ffffea00043ff4c8 ffffea0004325608 0000000000000000 raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected

 Memory state around the buggy address:
 ffff88810beee580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88810beee600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88810beee680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88810beee700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88810beee780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint ext4_rename_dir_prepare: [2] parent_de->inode=3537895424 ext4_rename_dir_prepare: [3] dir=0xffff888124170140 ext4_rename_dir_prepare: [4] ino=2 ext4_rename_dir_prepare: ent->dir->i_ino=2 parent=-757071872

 Reason is first directory entry which 'rec_len' is 34478, then will get illegal parent entry. Now, we do not check directory entry after read directory block in 'ext4_get_first_dir_block'.
 To solve this issue, check directory entry in 'ext4_get_first_dir_block'.

 [ Trigger an ext4_error() instead of just warning if the directory is missing a '.' or '..' entry. Also make sure we return an error code if the file system is corrupted. -TYT ]

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

 f2fs: fix to clear dirty inode in f2fs_evict_inode()

 As Yanming reported in bugzilla:

 https://bugzilla.kernel.org/show_bug.cgi?id=215904

 The kernel message is shown below:

 kernel BUG at fs/f2fs/inode.c:825! Call Trace:
 evict+0x282/0x4e0
 __dentry_kill+0x2b2/0x4d0 shrink_dentry_list+0x17c/0x4f0 shrink_dcache_parent+0x143/0x1e0 do_one_tree+0x9/0x30 shrink_dcache_for_umount+0x51/0x120 generic_shutdown_super+0x5c/0x3a0 kill_block_super+0x90/0xd0 kill_f2fs_super+0x225/0x310 deactivate_locked_super+0x78/0xc0 cleanup_mnt+0x2b7/0x480 task_work_run+0xc8/0x150 exit_to_user_mode_prepare+0x14a/0x150 syscall_exit_to_user_mode+0x1d/0x40 do_syscall_64+0x48/0x90

 The root cause is: inode node and dnode node share the same nid, so during f2fs_evict_inode(), dnode node truncation will invalidate its NAT entry, so when truncating i ...

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

Plugin Details

Severity: High

ID: 275906

File Name: tencentos_TSSA_2025_0346.nasl

Version: 1.1

Type: local

Published: 11/20/2025

Updated: 11/20/2025

Supported Sensors: Nessus

Risk Information

VPR

Risk Factor: Critical

Score: 9.2

CVSS v2

Risk Factor: Medium

Base Score: 6.8

Temporal Score: 5.9

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

CVSS Score Source: CVE-2025-21735

CVSS v3

Risk Factor: High

Base Score: 7.8

Temporal Score: 7.5

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:H/RL:O/RC:C

Vulnerability Information

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

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

Exploit Available: true

Exploit Ease: Exploits are available

Patch Publication Date: 5/15/2025

Vulnerability Publication Date: 4/19/2022

Reference Information

CVE: CVE-2021-47641, CVE-2021-47659, CVE-2022-49055, CVE-2022-49070, CVE-2022-49077, CVE-2022-49111, CVE-2022-49116, CVE-2022-49169, CVE-2022-49175, CVE-2022-49178, CVE-2022-49279, CVE-2022-49291, CVE-2022-49292, CVE-2022-49297, CVE-2022-49301, CVE-2022-49312, CVE-2022-49318, CVE-2022-49326, CVE-2022-49343, CVE-2022-49349, CVE-2022-49352, CVE-2022-49363, CVE-2022-49364, CVE-2022-49447, CVE-2022-49457, CVE-2022-49465, CVE-2022-49493, CVE-2022-49501, CVE-2022-49502, CVE-2022-49518, CVE-2022-49526, CVE-2022-49615, CVE-2022-49619, CVE-2022-49620, CVE-2022-49622, CVE-2022-49646, CVE-2022-49651, CVE-2022-49673, CVE-2022-49674, CVE-2022-49681, CVE-2022-49682, CVE-2022-49707, CVE-2022-49727, CVE-2022-49728, CVE-2022-49729, CVE-2022-49731, CVE-2024-54456, CVE-2024-54458, CVE-2024-57834, CVE-2024-57925, CVE-2024-57973, CVE-2024-57978, CVE-2024-57979, CVE-2024-57980, CVE-2024-57993, CVE-2024-57997, CVE-2024-57998, CVE-2024-58005, CVE-2024-58013, CVE-2024-58020, CVE-2025-21705, CVE-2025-21706, CVE-2025-21707, CVE-2025-21711, CVE-2025-21718, CVE-2025-21720, CVE-2025-21724, CVE-2025-21725, CVE-2025-21726, CVE-2025-21735, CVE-2025-21741, CVE-2025-21742, CVE-2025-21743, CVE-2025-21744, CVE-2025-21745, CVE-2025-21749, CVE-2025-21750, CVE-2025-21756, CVE-2025-21761, CVE-2025-21762, CVE-2025-21764, CVE-2025-21765, CVE-2025-21767, CVE-2025-21781, CVE-2025-21782, CVE-2025-21784, CVE-2025-21787, CVE-2025-21789, CVE-2025-21790, CVE-2025-21792, CVE-2025-21794, CVE-2025-21795, CVE-2025-21796, CVE-2025-21802, CVE-2025-21806, CVE-2025-21812, CVE-2025-21814, CVE-2025-21823