Detections
Analytics

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

high Nessus Plugin ID 239534

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

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

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

 nvme-multipath: defer partition scanning

 We need to suppress the partition scan from occuring within the controller's scan_work context. If a path error occurs here, the IO will wait until a path becomes available or all paths are torn down, but that action also occurs within scan_work, so it would deadlock. Defer the partion scan to a different context that does not block scan_work.

 CVE-2019-19046:
 In the Linux kernel, the following vulnerability has been resolved:

 drm/client: fix null pointer dereference in drm_client_modeset_probe

 In drm_client_modeset_probe(), the return value of drm_mode_duplicate() is assigned to modeset->mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.

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

 io_uring: fix possible deadlock in io_register_iowq_max_workers()

 The io_register_iowq_max_workers() function calls io_put_sq_data(), which acquires the sqd->lock without releasing the uring_lock.
 Similar to the commit 009ad9f0c6ee (io_uring: drop ctx->uring_lock before acquiring sqd->lock), this can lead to a potential deadlock situation.

 To resolve this issue, the uring_lock is released before calling io_put_sq_data(), and then it is re-acquired after the function call.

 This change ensures that the locks are acquired in the correct order, preventing the possibility of a deadlock.

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

 EDAC/bluefield: Fix potential integer overflow

 The 64-bit argument for the get DIMM info SMC call consists of mem_ctrl_idx left-shifted 16 bits and OR-ed with DIMM index. With mem_ctrl_idx defined as 32-bits wide the left-shift operation truncates the upper 16 bits of information during the calculation of the SMC argument.

 The mem_ctrl_idx stack variable must be defined as 64-bits wide to prevent any potential integer overflow, i.e. loss of data from upper 16 bits.

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

 firmware: arm_scpi: Check the DVFS OPP count returned by the firmware

 Fix a kernel crash with the below call trace when the SCPI firmware returns OPP count of zero.

 dvfs_info.opp_count may be zero on some platforms during the reboot test, and the kernel will crash after dereferencing the pointer to kcalloc(info->count, sizeof(*opp), GFP_KERNEL).

 | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028 | Mem abort info:
 | ESR = 0x96000004 | Exception class = DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | Data abort info:
 | ISV = 0, ISS = 0x00000004 | CM = 0, WnR = 0 | user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000faefa08c | [0000000000000028] pgd=0000000000000000 | Internal error: Oops: 96000004 [#1] SMP | scpi-hwmon: probe of PHYT000D:00 failed with error -110 | Process systemd-udevd (pid: 1701, stack limit = 0x00000000aaede86c) | CPU: 2 PID: 1701 Comm: systemd-udevd Not tainted 4.19.90+ #1 | Hardware name: PHYTIUM LTD Phytium FT2000/4/Phytium FT2000/4, BIOS | pstate: 60000005 (nZCv daif -PAN -UAO) | pc : scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi] | lr : clk_register+0x438/0x720 | Call trace:
 | scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi] | devm_clk_hw_register+0x50/0xa0 | scpi_clk_ops_init.isra.2+0xa0/0x138 [clk_scpi] | scpi_clocks_probe+0x528/0x70c [clk_scpi] | platform_drv_probe+0x58/0xa8 | really_probe+0x260/0x3d0 | driver_probe_device+0x12c/0x148 | device_driver_attach+0x74/0x98 | __driver_attach+0xb4/0xe8 | bus_for_each_dev+0x88/0xe0 | driver_attach+0x30/0x40 | bus_add_driver+0x178/0x2b0 | driver_register+0x64/0x118 | __platform_driver_register+0x54/0x60 | scpi_clocks_driver_init+0x24/0x1000 [clk_scpi] | do_one_initcall+0x54/0x220 | do_init_module+0x54/0x1c8 | load_module+0x14a4/0x1668 | __se_sys_finit_module+0xf8/0x110 | __arm64_sys_finit_module+0x24/0x30 | el0_svc_common+0x78/0x170 | el0_svc_handler+0x38/0x78 | el0_svc+0x8/0x340 | Code: 937d7c00 a94153f3 a8c27bfd f9400421 (b8606820) | ---[ end trace 06feb22469d89fa8 ]--- | Kernel panic - not syncing: Fatal exception | SMP: stopping secondary CPUs | Kernel Offset: disabled | CPU features: 0x10,a0002008 | Memory Limit: none

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

 wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service()

 I found the following bug in my fuzzer:

 UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath9k/htc_hst.c:26:51 index 255 is out of range for type 'htc_endpoint [22]' CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.11.0-rc6-dirty #14 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: events request_firmware_work_func Call Trace:
 <TASK> dump_stack_lvl+0x180/0x1b0
 __ubsan_handle_out_of_bounds+0xd4/0x130 htc_issue_send.constprop.0+0x20c/0x230 ? _raw_spin_unlock_irqrestore+0x3c/0x70 ath9k_wmi_cmd+0x41d/0x610 ? mark_held_locks+0x9f/0xe0 ...

 Since this bug has been confirmed to be caused by insufficient verification of conn_rsp_epid, I think it would be appropriate to add a range check for conn_rsp_epid to htc_connect_service() to prevent the bug from occurring.

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

 ocfs2: fix uninitialized value in ocfs2_file_read_iter()

 Syzbot has reported the following KMSAN splat:

 BUG: KMSAN: uninit-value in ocfs2_file_read_iter+0x9a4/0xf80 ocfs2_file_read_iter+0x9a4/0xf80
 __io_read+0x8d4/0x20f0 io_read+0x3e/0xf0 io_issue_sqe+0x42b/0x22c0 io_wq_submit_work+0xaf9/0xdc0 io_worker_handle_work+0xd13/0x2110 io_wq_worker+0x447/0x1410 ret_from_fork+0x6f/0x90 ret_from_fork_asm+0x1a/0x30

 Uninit was created at:
 __alloc_pages_noprof+0x9a7/0xe00 alloc_pages_mpol_noprof+0x299/0x990 alloc_pages_noprof+0x1bf/0x1e0 allocate_slab+0x33a/0x1250
 ___slab_alloc+0x12ef/0x35e0 kmem_cache_alloc_bulk_noprof+0x486/0x1330
 __io_alloc_req_refill+0x84/0x560 io_submit_sqes+0x172f/0x2f30
 __se_sys_io_uring_enter+0x406/0x41c0
 __x64_sys_io_uring_enter+0x11f/0x1a0 x64_sys_call+0x2b54/0x3ba0 do_syscall_64+0xcd/0x1e0 entry_SYSCALL_64_after_hwframe+0x77/0x7f

 Since an instance of 'struct kiocb' may be passed from the block layer with 'private' field uninitialized, introduce 'ocfs2_iocb_init_rw_locked()' and use it from where 'ocfs2_dio_end_io()' might take care, i.e. in 'ocfs2_file_read_iter()' and 'ocfs2_file_write_iter()'.

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

 ALSA: usb-audio: Fix out of bounds reads when finding clock sources

 The current USB-audio driver code doesn't check bLength of each descriptor at traversing for clock descriptors. That is, when a device provides a bogus descriptor with a shorter bLength, the driver might hit out-of-bounds reads.

 For addressing it, this patch adds sanity checks to the validator functions for the clock descriptor traversal. When the descriptor length is shorter than expected, it's skipped in the loop.

 For the clock source and clock multiplier descriptors, we can just check bLength against the sizeof() of each descriptor type.
 OTOH, the clock selector descriptor of UAC2 and UAC3 has an array of bNrInPins elements and two more fields at its tail, hence those have to be checked in addition to the sizeof() check.

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

 comedi: Flush partial mappings in error case

 If some remap_pfn_range() calls succeeded before one failed, we still have buffer pages mapped into the userspace page tables when we drop the buffer reference with comedi_buf_map_put(bm). The userspace mappings are only cleaned up later in the mmap error path.

 Fix it by explicitly flushing all mappings in our VMA on the error path.

 See commit 79a61cc3fc04 (mm: avoid leaving partial pfn mappings around in error case).

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

 NFSD: Prevent a potential integer overflow

 If the tag length is >= U32_MAX - 3 then the length + 4 addition can result in an integer overflow. Address this by splitting the decoding into several steps so that decode_cb_compound4res() does not have to perform arithmetic on the unsafe length value.

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

 um: Fix potential integer overflow during physmem setup

 This issue happens when the real map size is greater than LONG_MAX, which can be easily triggered on UML/i386.

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

 Bluetooth: hci_event: Align BR/EDR JUST_WORKS paring with LE

 This aligned BR/EDR JUST_WORKS method with LE which since 92516cd97fd4 (Bluetooth: Always request for user confirmation for Just Works) always request user confirmation with confirm_hint set since the likes of bluetoothd have dedicated policy around JUST_WORKS method (e.g. main.conf:JustWorksRepairing).

 CVE: CVE-2024-8805

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

 fs: Fix uninitialized value issue in from_kuid and from_kgid

 ocfs2_setattr() uses attr->ia_mode, attr->ia_uid and attr->ia_gid in a trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren't set.

 Initialize all fields of newattrs to avoid uninitialized variables, by checking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0.

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

 smb: client: Fix use-after-free of network namespace.

 Recently, we got a customer report that CIFS triggers oops while reconnecting to a server. [0]

 The workload runs on Kubernetes, and some pods mount CIFS servers in non-root network namespaces. The problem rarely happened, but it was always while the pod was dying.

 The root cause is wrong reference counting for network namespace.

 CIFS uses kernel sockets, which do not hold refcnt of the netns that the socket belongs to. That means CIFS must ensure the socket is always freed before its netns; otherwise, use-after-free happens.

 The repro steps are roughly:

 1. mount CIFS in a non-root netns 2. drop packets from the netns 3. destroy the netns 4. unmount CIFS

 We can reproduce the issue quickly with the script [1] below and see the splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled.

 When the socket is TCP, it is hard to guarantee the netns lifetime without holding refcnt due to async timers.

 Let's hold netns refcnt for each socket as done for SMC in commit 9744d2bf1976 (smc: Fix use-after-free in tcp_write_timer_handler().).

 Note that we need to move put_net() from cifs_put_tcp_session() to clean_demultiplex_info(); otherwise, __sock_create() still could touch a freed netns while cifsd tries to reconnect from cifs_demultiplex_thread().

 Also, maybe_get_net() cannot be put just before __sock_create() because the code is not under RCU and there is a small chance that the same address happened to be reallocated to another netns.

 [0]:
 CIFS: VFS: \\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting...
 CIFS: Serverclose failed 4 times, giving up Unable to handle kernel paging request at virtual address 14de99e461f84a07 Mem abort info:
 ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info:
 ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 [14de99e461f84a07] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1 Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : fib_rules_lookup+0x44/0x238 lr : __fib_lookup+0x64/0xbc sp : ffff8000265db790 x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01 x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580 x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500 x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002 x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294 x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0 x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500 Call trace:
 fib_rules_lookup+0x44/0x238
 __fib_lookup+0x64/0xbc ip_route_output_key_hash_rcu+0x2c4/0x398 ip_route_output_key_hash+0x60/0x8c tcp_v4_connect+0x290/0x488
 __inet_stream_connect+0x108/0x3d0 inet_stream_connect+0x50/0x78 kernel_connect+0x6c/0xac generic_ip_conne
 ---truncated---

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

 nfs: Fix KMSAN warning in decode_getfattr_attrs()

 Fix the following KMSAN warning:

 CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50
 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990
 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0
 __se_sys_newfstatat+0x67/0x880
 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f

 The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is not initialized.

 Fix the issue by initializing fattr->mdsthreshold to NULL in nfs_fattr_init().

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

 ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove()

 Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove():

 [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace:
 [ 57.331477] <TASK> [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...]

 Reproducer uses faultinject facility to fail ocfs2_xa_remove() -> ocfs2_xa_value_truncate() with -ENOMEM.

 In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2_xa_remove_entry(loc);' twice:
 * 1st: in ocfs2_xa_cleanup_value_truncate();
 * 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'.

 Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.

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

 ksmbd: Fix the missing xa_store error check

 xa_store() can fail, it return xa_err(-EINVAL) if the entry cannot be stored in an XArray, or xa_err(-ENOMEM) if memory allocation failed, so check error for xa_store() to fix it.

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

 fsdax: dax_unshare_iter needs to copy entire blocks

 The code that copies data from srcmap to iomap in dax_unshare_iter is very very broken, which bfoster's recent fsx changes have exposed.

 If the pos and len passed to dax_file_unshare are not aligned to an fsblock boundary, the iter pos and length in the _iter function will reflect this unalignment.

 dax_iomap_direct_access always returns a pointer to the start of the kmapped fsdax page, even if its pos argument is in the middle of that page. This is catastrophic for data integrity when iter->pos is not aligned to a page, because daddr/saddr do not point to the same byte in the file as iter->pos. Hence we corrupt user data by copying it to the wrong place.

 If iter->pos + iomap_length() in the _iter function not aligned to a page, then we fail to copy a full block, and only partially populate the destination block. This is catastrophic for data confidentiality because we expose stale pmem contents.

 Fix both of these issues by aligning copy_pos/copy_len to a page boundary (remember, this is fsdax so 1 fsblock == 1 base page) so that we always copy full blocks.

 We're not done yet -- there's no call to invalidate_inode_pages2_range, so programs that have the file range mmap'd will continue accessing the old memory mapping after the file metadata updates have completed.

 Be careful with the return value -- if the unshare succeeds, we still need to return the number of bytes that the iomap iter thinks we're operating on.

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

 fs/ntfs3: Add rough attr alloc_size check

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

 fs/ntfs3: Additional check in ntfs_file_release

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

 fs/ntfs3: Fix possible deadlock in mi_read

 Mutex lock with another subclass used in ni_lock_dir().

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

 fs/ntfs3: Additional check in ni_clear()

 Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to uninitialized bitmap during replay process.

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

 nilfs2: fix potential deadlock with newly created symlinks

 Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock.

 This is because after commit 21fc61c73c39 (don't put symlink bodies in pagecache into highmem), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem().

 This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs->ns_segctor_sem is held:

 Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and
 __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.

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

 udf: refactor inode_bmap() to handle error

 Refactor inode_bmap() to handle error since udf_next_aext() can return error now. On situations like ftruncate, udf_extend_file() can now detect errors and bail out early without resorting to checking for particular offsets and assuming internal behavior of these functions.

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

 smb: client: fix possible double free in smb2_set_ea()

 Clang static checker(scan-build) warning fs/smb/client/smb2ops.c:1304:2: Attempt to free released memory.
 1304 | kfree(ea);
 | ^~~~~~~~~

 There is a double free in such case:
 'ea is initialized to NULL' -> 'first successful memory allocation for ea' -> 'something failed, goto sea_exit' -> 'first memory release for ea'
 -> 'goto replay_again' -> 'second goto sea_exit before allocate memory for ea' -> 'second memory release for ea resulted in double free'.

 Re-initialie 'ea' to NULL near to the replay_again label, it can fix this double free problem.

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

 udf: fix uninit-value use in udf_get_fileshortad

 Check for overflow when computing alen in udf_current_aext to mitigate later uninit-value use in udf_get_fileshortad KMSAN bug[1].
 After applying the patch reproducer did not trigger any issue[2].

 [1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df [2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000

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

 nfsd: cancel nfsd_shrinker_work using sync mode in nfs4_state_shutdown_net

 In the normal case, when we excute `echo 0 > /proc/fs/nfsd/threads`, the function `nfs4_state_destroy_net` in `nfs4_state_shutdown_net` will release all resources related to the hashed `nfs4_client`. If the `nfsd_client_shrinker` is running concurrently, the `expire_client` function will first unhash this client and then destroy it. This can lead to the following warning. Additionally, numerous use-after-free errors may occur as well.

 nfsd_client_shrinker echo 0 > /proc/fs/nfsd/threads

 expire_client nfsd_shutdown_net unhash_client ...
 nfs4_state_shutdown_net /* won't wait shrinker exit */ /* cancel_work(&nn->nfsd_shrinker_work)
 * nfsd_file for this /* won't destroy unhashed client1 */
 * client1 still alive nfs4_state_destroy_net
 */

 nfsd_file_cache_shutdown /* trigger warning */ kmem_cache_destroy(nfsd_file_slab) kmem_cache_destroy(nfsd_file_mark_slab) /* release nfsd_file and mark */
 __destroy_client

 ==================================================================== BUG nfsd_file (Not tainted): Objects remaining in nfsd_file on
 __kmem_cache_shutdown()
 -------------------------------------------------------------------- CPU: 4 UID: 0 PID: 764 Comm: sh Not tainted 6.12.0-rc3+ #1

 dump_stack_lvl+0x53/0x70 slab_err+0xb0/0xf0
 __kmem_cache_shutdown+0x15c/0x310 kmem_cache_destroy+0x66/0x160 nfsd_file_cache_shutdown+0xac/0x210 [nfsd] nfsd_destroy_serv+0x251/0x2a0 [nfsd] nfsd_svc+0x125/0x1e0 [nfsd] write_threads+0x16a/0x2a0 [nfsd] nfsctl_transaction_write+0x74/0xa0 [nfsd] vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e

 ==================================================================== BUG nfsd_file_mark (Tainted: G B W ): Objects remaining nfsd_file_mark on __kmem_cache_shutdown()
 --------------------------------------------------------------------

 dump_stack_lvl+0x53/0x70 slab_err+0xb0/0xf0
 __kmem_cache_shutdown+0x15c/0x310 kmem_cache_destroy+0x66/0x160 nfsd_file_cache_shutdown+0xc8/0x210 [nfsd] nfsd_destroy_serv+0x251/0x2a0 [nfsd] nfsd_svc+0x125/0x1e0 [nfsd] write_threads+0x16a/0x2a0 [nfsd] nfsctl_transaction_write+0x74/0xa0 [nfsd] vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x ...

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

Plugin Details

Severity: High

ID: 239534

File Name: tencentos_TSSA_2025_0038.nasl

Version: 1.3

Type: local

Published: 6/16/2025

Updated: 11/23/2025

Supported Sensors: Nessus

Risk Information

VPR

Risk Factor: High

Score: 7.4

CVSS v2

Risk Factor: Low

Base Score: 2.1

Temporal Score: 1.7

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

CVSS Score Source: CVE-2022-0487

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-2024-53156

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: 2/17/2025

Vulnerability Publication Date: 2/17/2025

CISA Known Exploited Vulnerability Due Dates: 4/20/2023, 4/30/2025

Reference Information

CVE: CVE-2019-19046, CVE-2019-19053, CVE-2019-19054, CVE-2021-46906, CVE-2021-46963, CVE-2021-47180, CVE-2022-0487, CVE-2022-2873, CVE-2022-34495, CVE-2022-48697, CVE-2022-48867, CVE-2022-48868, CVE-2022-48869, CVE-2022-48870, CVE-2022-48871, CVE-2022-48872, CVE-2022-48873, CVE-2022-48874, CVE-2022-48878, CVE-2022-48879, CVE-2022-48880, CVE-2022-48881, CVE-2022-48981, CVE-2022-49002, CVE-2022-49011, CVE-2023-0266, CVE-2023-1073, CVE-2023-28772, CVE-2023-52594, CVE-2023-52595, CVE-2023-52623, CVE-2023-52826, CVE-2023-52921, CVE-2024-26633, CVE-2024-26651, CVE-2024-26654, CVE-2024-26855, CVE-2024-26900, CVE-2024-34030, CVE-2024-35931, CVE-2024-35947, CVE-2024-38560, CVE-2024-41080, CVE-2024-43894, CVE-2024-44989, CVE-2024-44991, CVE-2024-46860, CVE-2024-49885, CVE-2024-49897, CVE-2024-49917, CVE-2024-50066, CVE-2024-50121, CVE-2024-50143, CVE-2024-50152, CVE-2024-50170, CVE-2024-50192, CVE-2024-50211, CVE-2024-50229, CVE-2024-50230, CVE-2024-50242, CVE-2024-50244, CVE-2024-50245, CVE-2024-50246, CVE-2024-50250, CVE-2024-50265, CVE-2024-50282, CVE-2024-50284, CVE-2024-53066, CVE-2024-53072, CVE-2024-53081, CVE-2024-53092, CVE-2024-53093, CVE-2024-53095, CVE-2024-53096, CVE-2024-53100, CVE-2024-53101, CVE-2024-53103, CVE-2024-53108, CVE-2024-53113, CVE-2024-53120, CVE-2024-53121, CVE-2024-53130, CVE-2024-53131, CVE-2024-53135, CVE-2024-53136, CVE-2024-53138, CVE-2024-53139, CVE-2024-53140, CVE-2024-53142, CVE-2024-53144, CVE-2024-53145, CVE-2024-53146, CVE-2024-53148, CVE-2024-53150, CVE-2024-53155, CVE-2024-53156, CVE-2024-53157, CVE-2024-53161