Detections
Analytics

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

high Nessus Plugin ID 276160

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

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

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

 nilfs2: fix inode number range checks

 Patch series nilfs2: fix potential issues related to reserved inodes.

 This series fixes one use-after-free issue reported by syzbot, caused by nilfs2's internal inode being exposed in the namespace on a corrupted filesystem, and a couple of flaws that cause problems if the starting number of non-reserved inodes written in the on-disk super block is intentionally (or corruptly) changed from its default value.


 This patch (of 3):

 In the current implementation of nilfs2, nilfs->ns_first_ino, which gives the first non-reserved inode number, is read from the superblock, but its lower limit is not checked.

 As a result, if a number that overlaps with the inode number range of reserved inodes such as the root directory or metadata files is set in the super block parameter, the inode number test macros (NILFS_MDT_INODE and NILFS_VALID_INODE) will not function properly.

 In addition, these test macros use left bit-shift calculations using with the inode number as the shift count via the BIT macro, but the result of a shift calculation that exceeds the bit width of an integer is undefined in the C specification, so if ns_first_ino is set to a large value other than the default value NILFS_USER_INO (=11), the macros may potentially malfunction depending on the environment.

 Fix these issues by checking the lower bound of nilfs->ns_first_ino and by preventing bit shifts equal to or greater than the NILFS_USER_INO constant in the inode number test macros.

 Also, change the type of ns_first_ino from signed integer to unsigned integer to avoid the need for type casting in comparisons such as the lower bound check introduced this time.

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

 nilfs2: add missing check for inode numbers on directory entries

 Syzbot reported that mounting and unmounting a specific pattern of corrupted nilfs2 filesystem images causes a use-after-free of metadata file inodes, which triggers a kernel bug in lru_add_fn().

 As Jan Kara pointed out, this is because the link count of a metadata file gets corrupted to 0, and nilfs_evict_inode(), which is called from iput(), tries to delete that inode (ifile inode in this case).

 The inconsistency occurs because directories containing the inode numbers of these metadata files that should not be visible in the namespace are read without checking.

 Fix this issue by treating the inode numbers of these internal files as errors in the sanity check helper when reading directory folios/pages.

 Also thanks to Hillf Danton and Matthew Wilcox for their initial mm-layer analysis.

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

 ftruncate: pass a signed offset

 The old ftruncate() syscall, using the 32-bit off_t misses a sign extension when called in compat mode on 64-bit architectures. As a result, passing a negative length accidentally succeeds in truncating to file size between 2GiB and 4GiB.

 Changing the type of the compat syscall to the signed compat_off_t changes the behavior so it instead returns -EINVAL.

 The native entry point, the truncate() syscall and the corresponding loff_t based variants are all correct already and do not suffer from this mistake.

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

 hfsplus: fix uninit-value in copy_name

 [syzbot reported] BUG: KMSAN: uninit-value in sized_strscpy+0xc4/0x160 sized_strscpy+0xc4/0x160 copy_name+0x2af/0x320 fs/hfsplus/xattr.c:411 hfsplus_listxattr+0x11e9/0x1a50 fs/hfsplus/xattr.c:750 vfs_listxattr fs/xattr.c:493 [inline] listxattr+0x1f3/0x6b0 fs/xattr.c:840 path_listxattr fs/xattr.c:864 [inline]
 __do_sys_listxattr fs/xattr.c:876 [inline]
 __se_sys_listxattr fs/xattr.c:873 [inline]
 __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873 x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/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:3877 [inline] slab_alloc_node mm/slub.c:3918 [inline] kmalloc_trace+0x57b/0xbe0 mm/slub.c:4065 kmalloc include/linux/slab.h:628 [inline] hfsplus_listxattr+0x4cc/0x1a50 fs/hfsplus/xattr.c:699 vfs_listxattr fs/xattr.c:493 [inline] listxattr+0x1f3/0x6b0 fs/xattr.c:840 path_listxattr fs/xattr.c:864 [inline]
 __do_sys_listxattr fs/xattr.c:876 [inline]
 __se_sys_listxattr fs/xattr.c:873 [inline]
 __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873 x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [Fix] When allocating memory to strbuf, initialize memory to 0.

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

 filelock: fix potential use-after-free in posix_lock_inode

 Light Hsieh reported a KASAN UAF warning in trace_posix_lock_inode().
 The request pointer had been changed earlier to point to a lock entry that was added to the inode's list. However, before the tracepoint could fire, another task raced in and freed that lock.

 Fix this by moving the tracepoint inside the spinlock, which should ensure that this doesn't happen.

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

 nilfs2: fix kernel bug on rename operation of broken directory

 Syzbot reported that in rename directory operation on broken directory on nilfs2, __block_write_begin_int() called to prepare block write may fail BUG_ON check for access exceeding the folio/page size.

 This is because nilfs_dotdot(), which gets parent directory reference entry (..) of the directory to be moved or renamed, does not check consistency enough, and may return location exceeding folio/page size for broken directories.

 Fix this issue by checking required directory entries (. and ..) in the first chunk of the directory in nilfs_dotdot().

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

 filelock: Fix fcntl/close race recovery compat path

 When I wrote commit 3cad1bc01041 (filelock: Remove locks reliably when fcntl/close race is detected), I missed that there are two copies of the code I was patching: The normal version, and the version for 64-bit offsets on 32-bit kernels.
 Thanks to Greg KH for stumbling over this while doing the stable backport...

 Apply exactly the same fix to the compat path for 32-bit kernels.

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

 jfs: don't walk off the end of ealist

 Add a check before visiting the members of ea to make sure each ea stays within the ealist.

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

 ocfs2: strict bound check before memcmp in ocfs2_xattr_find_entry()

 xattr in ocfs2 maybe 'non-indexed', which saved with additional space requested. It's better to check if the memory is out of bound before memcmp, although this possibility mainly comes from crafted poisonous images.

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

 ocfs2: add bounds checking to ocfs2_check_dir_entry()

 This adds sanity checks for ocfs2_dir_entry to make sure all members of ocfs2_dir_entry don't stray beyond valid memory region.

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

 xfs: add bounds checking to xlog_recover_process_data

 There is a lack of verification of the space occupied by fixed members of xlog_op_header in the xlog_recover_process_data.

 We can create a crafted image to trigger an out of bounds read by following these steps:
 1) Mount an image of xfs, and do some file operations to leave records 2) Before umounting, copy the image for subsequent steps to simulate abnormal exit. Because umount will ensure that tail_blk and head_blk are the same, which will result in the inability to enter xlog_recover_process_data 3) Write a tool to parse and modify the copied image in step 2 4) Make the end of the xlog_op_header entries only 1 byte away from xlog_rec_header->h_size 5) xlog_rec_header->h_num_logops++ 6) Modify xlog_rec_header->h_crc

 Fix:
 Add a check to make sure there is sufficient space to access fixed members of xlog_op_header.

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

 xfs: don't walk off the end of a directory data block

 This adds sanity checks for xfs_dir2_data_unused and xfs_dir2_data_entry to make sure don't stray beyond valid memory region. Before patching, the loop simply checks that the start offset of the dup and dep is within the range. So in a crafted image, if last entry is xfs_dir2_data_unused, we can change dup->length to dup->length-1 and leave 1 byte of space. In the next traversal, this space will be considered as dup or dep. We may encounter an out of bound read when accessing the fixed members.

 In the patch, we make sure that the remaining bytes large enough to hold an unused entry before accessing xfs_dir2_data_unused and xfs_dir2_data_unused is XFS_DIR2_DATA_ALIGN byte aligned. We also make sure that the remaining bytes large enough to hold a dirent with a single-byte name before accessing xfs_dir2_data_entry.

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

 jfs: xattr: fix buffer overflow for invalid xattr

 When an xattr size is not what is expected, it is printed out to the kernel log in hex format as a form of debugging. But when that xattr size is bigger than the expected size, printing it out can cause an access off the end of the buffer.

 Fix this all up by properly restricting the size of the debug hex dump in the kernel log.

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

 nilfs2: fix nilfs_empty_dir() misjudgment and long loop on I/O errors

 The error handling in nilfs_empty_dir() when a directory folio/page read fails is incorrect, as in the old ext2 implementation, and if the folio/page cannot be read or nilfs_check_folio() fails, it will falsely determine the directory as empty and corrupt the file system.

 In addition, since nilfs_empty_dir() does not immediately return on a failed folio/page read, but continues to loop, this can cause a long loop with I/O if i_size of the directory's inode is also corrupted, causing the log writer thread to wait and hang, as reported by syzbot.

 Fix these issues by making nilfs_empty_dir() immediately return a false value (0) if it fails to get a directory folio/page.

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

 f2fs: fix to do sanity check on i_xattr_nid in sanity_check_inode()

 syzbot reports a kernel bug as below:

 F2FS-fs (loop0): Mounted with checkpoint version = 48b305e4 ================================================================== BUG: KASAN: slab-out-of-bounds in f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline] BUG: KASAN: slab-out-of-bounds in current_nat_addr fs/f2fs/node.h:213 [inline] BUG: KASAN: slab-out-of-bounds in f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600 Read of size 1 at addr ffff88807a58c76c by task syz-executor280/5076

 CPU: 1 PID: 5076 Comm: syz-executor280 Not tainted 6.9.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 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 f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline] current_nat_addr fs/f2fs/node.h:213 [inline] f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600 f2fs_xattr_fiemap fs/f2fs/data.c:1848 [inline] f2fs_fiemap+0x55d/0x1ee0 fs/f2fs/data.c:1925 ioctl_fiemap fs/ioctl.c:220 [inline] do_vfs_ioctl+0x1c07/0x2e50 fs/ioctl.c:838
 __do_sys_ioctl fs/ioctl.c:902 [inline]
 __se_sys_ioctl+0x81/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f

 The root cause is we missed to do sanity check on i_xattr_nid during f2fs_iget(), so that in fiemap() path, current_nat_addr() will access nat_bitmap w/ offset from invalid i_xattr_nid, result in triggering kasan bug report, fix it.

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

 ext4: fix mb_cache_entry's e_refcnt leak in ext4_xattr_block_cache_find()

 Syzbot reports a warning as follows:

 ============================================ WARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290 Modules linked in:
 CPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7 RIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419 Call Trace:
 <TASK> ext4_put_super+0x6d4/0xcd0 fs/ext4/super.c:1375 generic_shutdown_super+0x136/0x2d0 fs/super.c:641 kill_block_super+0x44/0x90 fs/super.c:1675 ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327 [...] ============================================

 This is because when finding an entry in ext4_xattr_block_cache_find(), if ext4_sb_bread() returns -ENOMEM, the ce's e_refcnt, which has already grown in the __entry_find(), won't be put away, and eventually trigger the above issue in mb_cache_destroy() due to reference count leakage.

 So call mb_cache_entry_put() on the -ENOMEM error branch as a quick fix.

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

 jffs2: prevent xattr node from overflowing the eraseblock

 Add a check to make sure that the requested xattr node size is no larger than the eraseblock minus the cleanmarker.

 Unlike the usual inode nodes, the xattr nodes aren't split into parts and spread across multiple eraseblocks, which means that a xattr node must not occupy more than one eraseblock. If the requested xattr value is too large, the xattr node can spill onto the next eraseblock, overwriting the nodes and causing errors such as:

 jffs2: argh. node added in wrong place at 0x0000b050(2) jffs2: nextblock 0x0000a000, expected at 0000b00c jffs2: error: (823) do_verify_xattr_datum: node CRC failed at 0x01e050, read=0xfc892c93, calc=0x000000 jffs2: notice: (823) jffs2_get_inode_nodes: Node header CRC failed at 0x01e00c. {848f,2fc4,0fef511f,59a3d171} jffs2: Node at 0x0000000c with length 0x00001044 would run over the end of the erase block jffs2: Perhaps the file system was created with the wrong erase size? jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000010: 0x1044 instead

 This breaks the filesystem and can lead to KASAN crashes such as:

 BUG: KASAN: slab-out-of-bounds in jffs2_sum_add_kvec+0x125e/0x15d0 Read of size 4 at addr ffff88802c31e914 by task repro/830 CPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 Call Trace:
 <TASK> dump_stack_lvl+0xc6/0x120 print_report+0xc4/0x620 ? __virt_addr_valid+0x308/0x5b0 kasan_report+0xc1/0xf0 ? jffs2_sum_add_kvec+0x125e/0x15d0 ? jffs2_sum_add_kvec+0x125e/0x15d0 jffs2_sum_add_kvec+0x125e/0x15d0 jffs2_flash_direct_writev+0xa8/0xd0 jffs2_flash_writev+0x9c9/0xef0 ? __x64_sys_setxattr+0xc4/0x160 ? do_syscall_64+0x69/0x140 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [...]

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

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

 nilfs2: fix use-after-free of timer for log writer thread

 Patch series nilfs2: fix log writer related issues.

 This bug fix series covers three nilfs2 log writer-related issues, including a timer use-after-free issue and potential deadlock issue on unmount, and a potential freeze issue in event synchronization found during their analysis. Details are described in each commit log.


 This patch (of 3):

 A use-after-free issue has been reported regarding the timer sc_timer on the nilfs_sc_info structure.

 The problem is that even though it is used to wake up a sleeping log writer thread, sc_timer is not shut down until the nilfs_sc_info structure is about to be freed, and is used regardless of the thread's lifetime.

 Fix this issue by limiting the use of sc_timer only while the log writer thread is alive.

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

 nilfs2: fix potential hang in nilfs_detach_log_writer()

 Syzbot has reported a potential hang in nilfs_detach_log_writer() called during nilfs2 unmount.

 Analysis revealed that this is because nilfs_segctor_sync(), which synchronizes with the log writer thread, can be called after nilfs_segctor_destroy() terminates that thread, as shown in the call trace below:

 nilfs_detach_log_writer nilfs_segctor_destroy nilfs_segctor_kill_thread --> Shut down log writer thread flush_work nilfs_iput_work_func nilfs_dispose_list iput nilfs_evict_inode nilfs_transaction_commit nilfs_construct_segment (if inode needs sync) nilfs_segctor_sync --> Attempt to synchronize with log writer thread
 *** DEADLOCK ***

 Fix this issue by changing nilfs_segctor_sync() so that the log writer thread returns normally without synchronizing after it terminates, and by forcing tasks that are already waiting to complete once after the thread terminates.

 The skipped inode metadata flushout will then be processed together in the subsequent cleanup work in nilfs_segctor_destroy().

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

 ecryptfs: Fix buffer size for tag 66 packet

 The 'TAG 66 Packet Format' description is missing the cipher code and checksum fields that are packed into the message packet. As a result, the buffer allocated for the packet is 3 bytes too small and write_tag_66_packet() will write up to 3 bytes past the end of the buffer.

 Fix this by increasing the size of the allocation so the whole packet will always fit in the buffer.

 This fixes the below kasan slab-out-of-bounds bug:

 BUG: KASAN: slab-out-of-bounds in ecryptfs_generate_key_packet_set+0x7d6/0xde0 Write of size 1 at addr ffff88800afbb2a5 by task touch/181

 CPU: 0 PID: 181 Comm: touch Not tainted 6.6.13-gnu #1 4c9534092be820851bb687b82d1f92a426598dc6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2/GNU Guix 04/01/2014 Call Trace:
 <TASK> dump_stack_lvl+0x4c/0x70 print_report+0xc5/0x610 ? ecryptfs_generate_key_packet_set+0x7d6/0xde0 ? kasan_complete_mode_report_info+0x44/0x210 ? ecryptfs_generate_key_packet_set+0x7d6/0xde0 kasan_report+0xc2/0x110 ? ecryptfs_generate_key_packet_set+0x7d6/0xde0
 __asan_store1+0x62/0x80 ecryptfs_generate_key_packet_set+0x7d6/0xde0 ? __pfx_ecryptfs_generate_key_packet_set+0x10/0x10 ? __alloc_pages+0x2e2/0x540 ? __pfx_ovl_open+0x10/0x10 [overlay 30837f11141636a8e1793533a02e6e2e885dad1d] ? dentry_open+0x8f/0xd0 ecryptfs_write_metadata+0x30a/0x550 ? __pfx_ecryptfs_write_metadata+0x10/0x10 ? ecryptfs_get_lower_file+0x6b/0x190 ecryptfs_initialize_file+0x77/0x150 ecryptfs_create+0x1c2/0x2f0 path_openat+0x17cf/0x1ba0 ? __pfx_path_openat+0x10/0x10 do_filp_open+0x15e/0x290 ? __pfx_do_filp_open+0x10/0x10 ? __kasan_check_write+0x18/0x30 ? _raw_spin_lock+0x86/0xf0 ? __pfx__raw_spin_lock+0x10/0x10 ? __kasan_check_write+0x18/0x30 ? alloc_fd+0xf4/0x330 do_sys_openat2+0x122/0x160 ? __pfx_do_sys_openat2+0x10/0x10
 __x64_sys_openat+0xef/0x170 ? __pfx___x64_sys_openat+0x10/0x10 do_syscall_64+0x60/0xd0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f00a703fd67 Code: 25 00 00 41 00 3d 00 00 41 00 74 37 64 8b 04 25 18 00 00 00 85 c0 75 5b 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 85 00 00 00 48 83 c4 68 5d 41 5c c3 0f 1f RSP: 002b:00007ffc088e30b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101 RAX: ffffffffffffffda RBX: 00007ffc088e3368 RCX: 00007f00a703fd67 RDX: 0000000000000941 RSI: 00007ffc088e48d7 RDI: 00000000ffffff9c RBP: 00007ffc088e48d7 R08: 0000000000000001 R09: 0000000000000000 R10: 00000000000001b6 R11: 0000000000000246 R12: 0000000000000941 R13: 0000000000000000 R14: 00007ffc088e48d7 R15: 00007f00a7180040 </TASK>

 Allocated by task 181:
 kasan_save_stack+0x2f/0x60 kasan_set_track+0x29/0x40 kasan_save_alloc_info+0x25/0x40
 __kasan_kmalloc+0xc5/0xd0
 __kmalloc+0x66/0x160 ecryptfs_generate_key_packet_set+0x6d2/0xde0 ecryptfs_write_metadata+0x30a/0x550 ecryptfs_initialize_file+0x77/0x150 ecryptfs_create+0x1c2/0x2f0 path_openat+0x17cf/0x1ba0 do_filp_open+0x15e/0x290 do_sys_openat2+0x122/0x160
 __x64_sys_openat+0xef/0x170 do_syscall_64+0x60/0xd0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8

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

 netfilter: nf_tables: use timestamp to check for set element timeout

 Add a timestamp field at the beginning of the transaction, store it in the nftables per-netns area.

 Update set backend .insert, .deactivate and sync gc path to use the timestamp, this avoids that an element expires while control plane transaction is still unfinished.

 .lookup and .update, which are used from packet path, still use the current time to check if the element has expired. And .get path and dump also since this runs lockless under rcu read size lock. Then, there is async gc which also needs to check the current time since it runs asynchronously from a workqueue.

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

 scsi: lpfc: Fix null pointer dereference after failing to issue FLOGI and PLOGI

 If lpfc_issue_els_flogi() fails and returns non-zero status, the node reference count is decremented to trigger the release of the nodelist structure. However, if there is a prior registration or dev-loss-evt work pending, the node may be released prematurely. When dev-loss-evt completes, the released node is referenced causing a use-after-free null pointer dereference.

 Similarly, when processing non-zero ELS PLOGI completion status in lpfc_cmpl_els_plogi(), the ndlp flags are checked for a transport registration before triggering node removal. If dev-loss-evt work is pending, the node may be released prematurely and a subsequent call to lpfc_dev_loss_tmo_handler() results in a use after free ndlp dereference.

 Add test for pending dev-loss before decrementing the node reference count for FLOGI, PLOGI, PRLI, and ADISC handling.

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

 btrfs: do not double complete bio on errors during compressed reads

 I hit some weird panics while fixing up the error handling from btrfs_lookup_bio_sums(). Turns out the compression path will complete the bio we use if we set up any of the compression bios and then return an error, and then btrfs_submit_data_bio() will also call bio_endio() on the bio.

 Fix this by making btrfs_submit_compressed_read() responsible for calling bio_endio() on the bio if there are any errors. Currently it was only doing it if we created the compression bios, otherwise it was depending on btrfs_submit_data_bio() to do the right thing. This creates the above problem, so fix up btrfs_submit_compressed_read() to always call bio_endio() in case of an error, and then simply return from btrfs_submit_data_bio() if we had to call btrfs_submit_compressed_read().

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

 isofs: Fix out of bound access for corrupted isofs image

 When isofs image is suitably corrupted isofs_read_inode() can read data beyond the end of buffer. Sanity-check the directory entry length before using it.

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

 dm cache: fix potential out-of-bounds access on the first resume

 Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue.

 Reproduce steps:

 1. prepare component devices:

 dmsetup create cmeta --table 0 8192 linear /dev/sdc 0 dmsetup create cdata --table 0 65536 linear /dev/sdc 8192 dmsetup create corig --table 0 524288 linear /dev/sdc 262144 dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct

 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate.

 dmsetup create cache --notable dmsetup reload cache --table 0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0 dmsetup reload cdata --table 0 131072 linear /dev/sdc 8192 dmsetup resume cdata dmsetup resume cache

 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40:

 dmsetup suspend cache

 KASAN reports:

 BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90

 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by:
 cache_ctr+0x176a/0x35f0

 (...snip...) Memory state around the buggy a ...

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

Plugin Details

Severity: High

ID: 276160

File Name: tencentos_TSSA_2025_0432.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: Medium

Base Score: 4.6

Temporal Score: 3.6

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

CVSS Score Source: CVE-2021-42252

CVSS v3

Risk Factor: High

Base Score: 7.8

Temporal Score: 7

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

CVSS Score Source: CVE-2024-42105

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 Available: true

Exploit Ease: Exploits are available

Patch Publication Date: 7/8/2025

Vulnerability Publication Date: 7/21/2021

Reference Information

CVE: CVE-2021-42252, CVE-2021-47478, CVE-2022-49053, CVE-2022-49114, CVE-2022-49167, CVE-2022-49535, CVE-2024-27397, CVE-2024-38578, CVE-2024-38582, CVE-2024-38583, CVE-2024-38599, CVE-2024-39276, CVE-2024-39467, CVE-2024-39469, CVE-2024-39487, CVE-2024-40902, CVE-2024-40958, CVE-2024-41013, CVE-2024-41014, CVE-2024-41015, CVE-2024-41016, CVE-2024-41017, CVE-2024-41020, CVE-2024-41034, CVE-2024-41049, CVE-2024-41059, CVE-2024-42084, CVE-2024-42104, CVE-2024-42105, CVE-2024-50278