Detections
Analytics

TencentOS Server 2: kernel (TSSA-2024:0720)

high Nessus Plugin ID 238604

Synopsis

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

Description

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

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

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

 ALSA: line6: Fix racy access to midibuf

 There can be concurrent accesses to line6 midibuf from both the URB completion callback and the rawmidi API access. This could be a cause of KMSAN warning triggered by syzkaller below (so put as reported-by here).

 This patch protects the midibuf call of the former code path with a spinlock for avoiding the possible races.

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

 kobject_uevent: Fix OOB access within zap_modalias_env()

 zap_modalias_env() wrongly calculates size of memory block to move, so will cause OOB memory access issue if variable MODALIAS is not the last one within its @env parameter, fixed by correcting size to memmove.

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

 protect the fetch of ->fd[fd] in do_dup2() from mispredictions

 both callers have verified that fd is not greater than ->max_fds;
 however, misprediction might end up with tofree = fdt->fd[fd];
 being speculatively executed. That's wrong for the same reasons why it's wrong in close_fd()/file_close_fd_locked(); the same solution applies - array_index_nospec(fd, fdt->max_fds) could differ from fd only in case of speculative execution on mispredicted path.

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

 closures: Change BUG_ON() to WARN_ON()

 If a BUG_ON() can be hit in the wild, it shouldn't be a BUG_ON()

 For reference, this has popped up once in the CI, and we'll need more info to debug it:

 03240 ------------[ cut here ]------------ 03240 kernel BUG at lib/closure.c:21! 03240 kernel BUG at lib/closure.c:21! 03240 Internal error: Oops - BUG: 00000000f2000800 [#1] SMP 03240 Modules linked in:
 03240 CPU: 15 PID: 40534 Comm: kworker/u80:1 Not tainted 6.10.0-rc4-ktest-ga56da69799bd #25570 03240 Hardware name: linux,dummy-virt (DT) 03240 Workqueue: btree_update btree_interior_update_work 03240 pstate: 00001005 (nzcv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) 03240 pc : closure_put+0x224/0x2a0 03240 lr : closure_put+0x24/0x2a0 03240 sp : ffff0000d12071c0 03240 x29: ffff0000d12071c0 x28: dfff800000000000 x27: ffff0000d1207360 03240 x26: 0000000000000040 x25: 0000000000000040 x24: 0000000000000040 03240 x23: ffff0000c1f20180 x22: 0000000000000000 x21: ffff0000c1f20168 03240 x20: 0000000040000000 x19: ffff0000c1f20140 x18: 0000000000000001 03240 x17: 0000000000003aa0 x16: 0000000000003ad0 x15: 1fffe0001c326974 03240 x14: 0000000000000a1e x13: 0000000000000000 x12: 1fffe000183e402d 03240 x11: ffff6000183e402d x10: dfff800000000000 x9 : ffff6000183e402e 03240 x8 : 0000000000000001 x7 : 00009fffe7c1bfd3 x6 : ffff0000c1f2016b 03240 x5 : ffff0000c1f20168 x4 : ffff6000183e402e x3 : ffff800081391954 03240 x2 : 0000000000000001 x1 : 0000000000000000 x0 : 00000000a8000000 03240 Call trace:
 03240 closure_put+0x224/0x2a0 03240 bch2_check_for_deadlock+0x910/0x1028 03240 bch2_six_check_for_deadlock+0x1c/0x30 03240 six_lock_slowpath.isra.0+0x29c/0xed0 03240 six_lock_ip_waiter+0xa8/0xf8 03240 __bch2_btree_node_lock_write+0x14c/0x298 03240 bch2_trans_lock_write+0x6d4/0xb10 03240 __bch2_trans_commit+0x135c/0x5520 03240 btree_interior_update_work+0x1248/0x1c10 03240 process_scheduled_works+0x53c/0xd90 03240 worker_thread+0x370/0x8c8 03240 kthread+0x258/0x2e8 03240 ret_from_fork+0x10/0x20 03240 Code: aa1303e0 d63f0020 a94363f7 17ffff8c (d4210000) 03240 ---[ end trace 0000000000000000 ]--- 03240 Kernel panic - not syncing: Oops - BUG: Fatal exception 03240 SMP: stopping secondary CPUs 03241 SMP: failed to stop secondary CPUs 13,15 03241 Kernel Offset: disabled 03241 CPU features: 0x00,00000003,80000008,4240500b 03241 Memory Limit: none 03241 ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception ]--- 03246 ========= FAILED TIMEOUT copygc_torture_no_checksum in 7200s

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

 bpf: Avoid uninitialized value in BPF_CORE_READ_BITFIELD

 [Changes from V1:
 - Use a default branch in the switch statement to initialize `val'.]

 GCC warns that `val' may be used uninitialized in the BPF_CRE_READ_BITFIELD macro, defined in bpf_core_read.h as:

 [...] unsigned long long val; \ [...] \ switch (__CORE_RELO(s, field, BYTE_SIZE)) { \ case 1: val = *(const unsigned char *)p; break; \ case 2: val = *(const unsigned short *)p; break; \ case 4: val = *(const unsigned int *)p; break; \ case 8: val = *(const unsigned long long *)p; break; \ } \ [...] val; \ } \

 This patch adds a default entry in the switch statement that sets `val' to zero in order to avoid the warning, and random values to be used in case __builtin_preserve_field_info returns unexpected values for BPF_FIELD_BYTE_SIZE.

 Tested in bpf-next master.
 No regressions.

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

 jffs2: Fix potential illegal address access in jffs2_free_inode

 During the stress testing of the jffs2 file system,the following abnormal printouts were found:
 [ 2430.649000] Unable to handle kernel paging request at virtual address 0069696969696948 [ 2430.649622] Mem abort info:
 [ 2430.649829] ESR = 0x96000004 [ 2430.650115] EC = 0x25: DABT (current EL), IL = 32 bits [ 2430.650564] SET = 0, FnV = 0 [ 2430.650795] EA = 0, S1PTW = 0 [ 2430.651032] FSC = 0x04: level 0 translation fault [ 2430.651446] Data abort info:
 [ 2430.651683] ISV = 0, ISS = 0x00000004 [ 2430.652001] CM = 0, WnR = 0 [ 2430.652558] [0069696969696948] address between user and kernel address ranges [ 2430.653265] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 2430.654512] CPU: 2 PID: 20919 Comm: cat Not tainted 5.15.25-g512f31242bf6 #33 [ 2430.655008] Hardware name: linux,dummy-virt (DT) [ 2430.655517] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2430.656142] pc : kfree+0x78/0x348 [ 2430.656630] lr : jffs2_free_inode+0x24/0x48 [ 2430.657051] sp : ffff800009eebd10 [ 2430.657355] x29: ffff800009eebd10 x28: 0000000000000001 x27: 0000000000000000 [ 2430.658327] x26: ffff000038f09d80 x25: 0080000000000000 x24: ffff800009d38000 [ 2430.658919] x23: 5a5a5a5a5a5a5a5a x22: ffff000038f09d80 x21: ffff8000084f0d14 [ 2430.659434] x20: ffff0000bf9a6ac0 x19: 0169696969696940 x18: 0000000000000000 [ 2430.659969] x17: ffff8000b6506000 x16: ffff800009eec000 x15: 0000000000004000 [ 2430.660637] x14: 0000000000000000 x13: 00000001000820a1 x12: 00000000000d1b19 [ 2430.661345] x11: 0004000800000000 x10: 0000000000000001 x9 : ffff8000084f0d14 [ 2430.662025] x8 : ffff0000bf9a6b40 x7 : ffff0000bf9a6b48 x6 : 0000000003470302 [ 2430.662695] x5 : ffff00002e41dcc0 x4 : ffff0000bf9aa3b0 x3 : 0000000003470342 [ 2430.663486] x2 : 0000000000000000 x1 : ffff8000084f0d14 x0 : fffffc0000000000 [ 2430.664217] Call trace:
 [ 2430.664528] kfree+0x78/0x348 [ 2430.664855] jffs2_free_inode+0x24/0x48 [ 2430.665233] i_callback+0x24/0x50 [ 2430.665528] rcu_do_batch+0x1ac/0x448 [ 2430.665892] rcu_core+0x28c/0x3c8 [ 2430.666151] rcu_core_si+0x18/0x28 [ 2430.666473] __do_softirq+0x138/0x3cc [ 2430.666781] irq_exit+0xf0/0x110 [ 2430.667065] handle_domain_irq+0x6c/0x98 [ 2430.667447] gic_handle_irq+0xac/0xe8 [ 2430.667739] call_on_irq_stack+0x28/0x54 The parameter passed to kfree was 5a5a5a5a, which corresponds to the target field of the jffs_inode_info structure. It was found that all variables in the jffs_inode_info structure were 5a5a5a5a, except for the first member sem. It is suspected that these variables are not initialized because they were set to 5a5a5a5a during memory testing, which is meant to detect uninitialized memory.The sem variable is initialized in the function jffs2_i_init_once, while other members are initialized in the function jffs2_init_inode_info.

 The function jffs2_init_inode_info is called after iget_locked, but in the iget_locked function, the destroy_inode process is triggered, which releases the inode and consequently, the target member of the inode is not initialized.In concurrent high pressure scenarios, iget_locked may enter the destroy_inode branch as described in the code.

 Since the destroy_inode functionality of jffs2 only releases the target, the fix method is to set target to NULL in jffs2_i_init_once.

 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-41012:
 In the Linux kernel, the following vulnerability has been resolved:

 filelock: Remove locks reliably when fcntl/close race is detected

 When fcntl_setlk() races with close(), it removes the created lock with do_lock_file_wait().
 However, LSMs can allow the first do_lock_file_wait() that created the lock while denying the second do_lock_file_wait() that tries to remove the lock.
 Separately, posix_lock_file() could also fail to remove a lock due to GFP_KERNEL allocation failure (when splitting a range in the middle).

 After the bug has been triggered, use-after-free reads will occur in lock_get_status() when userspace reads /proc/locks. This can likely be used to read arbitrary kernel memory, but can't corrupt kernel memory.

 Fix it by calling locks_remove_posix() instead, which is designed to reliably get rid of POSIX locks associated with the given file and files_struct and is also used by filp_flush().

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

 drm/radeon: fix UBSAN warning in kv_dpm.c

 Adds bounds check for sumo_vid_mapping_entry.

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

 ACPICA: Revert ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine.

 Undo the modifications made in commit d410ee5109a1 (ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine.). The initial purpose of this commit was to stop memory mappings for operation regions from overlapping page boundaries, as it can trigger warnings if different page attributes are present.

 However, it was found that when this situation arises, mapping continues until the boundary's end, but there is still an attempt to read/write the entire length of the map, leading to a NULL pointer deference. For example, if a four-byte mapping request is made but only one byte is mapped because it hits the current page boundary's end, a four-byte read/write attempt is still made, resulting in a NULL pointer deference.

 Instead, map the entire length, as the ACPI specification does not mandate that it must be within the same page boundary. It is permissible for it to be mapped across different regions.

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

 iommu: Return right value in iommu_sva_bind_device()

 iommu_sva_bind_device() should return either a sva bond handle or an ERR_PTR value in error cases. Existing drivers (idxd and uacce) only check the return value with IS_ERR(). This could potentially lead to a kernel NULL pointer dereference issue if the function returns NULL instead of an error pointer.

 In reality, this doesn't cause any problems because iommu_sva_bind_device() only returns NULL when the kernel is not configured with CONFIG_IOMMU_SVA.
 In this case, iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_SVA) will return an error, and the device drivers won't call iommu_sva_bind_device() at all.

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

 ocfs2: fix races between hole punching and AIO+DIO

 After commit ocfs2: return real error code in ocfs2_dio_wr_get_block, fstests/generic/300 become from always failed to sometimes failed:

 ======================================================================== [ 473.293420 ] run fstests generic/300

 [ 475.296983 ] JBD2: Ignoring recovery information on journal [ 475.302473 ] ocfs2: Mounting device (253,1) on (node local, slot 0) with ordered data mode.
 [ 494.290998 ] OCFS2: ERROR (device dm-1): ocfs2_change_extent_flag: Owner 5668 has an extent at cpos 78723 which can no longer be found [ 494.291609 ] On-disk corruption discovered. Please run fsck.ocfs2 once the filesystem is unmounted.
 [ 494.292018 ] OCFS2: File system is now read-only.
 [ 494.292224 ] (kworker/19:11,2628,19):ocfs2_mark_extent_written:5272 ERROR: status = -30 [ 494.292602 ] (kworker/19:11,2628,19):ocfs2_dio_end_io_write:2374 ERROR: status = -3 fio: io_u error on file /mnt/scratch/racer: Read-only file system: write offset=460849152, buflen=131072 =========================================================================

 In __blockdev_direct_IO, ocfs2_dio_wr_get_block is called to add unwritten extents to a list. extents are also inserted into extent tree in ocfs2_write_begin_nolock. Then another thread call fallocate to puch a hole at one of the unwritten extent. The extent at cpos was removed by ocfs2_remove_extent(). At end io worker thread, ocfs2_search_extent_list found there is no such extent at the cpos.

 T1 T2 T3 inode lock ...
 insert extents ...
 inode unlock ocfs2_fallocate
 __ocfs2_change_file_space inode lock lock ip_alloc_sem ocfs2_remove_inode_range inode ocfs2_remove_btree_range ocfs2_remove_extent ^---remove the extent at cpos 78723 ...
 unlock ip_alloc_sem inode unlock ocfs2_dio_end_io ocfs2_dio_end_io_write lock ip_alloc_sem ocfs2_mark_extent_written ocfs2_change_extent_flag ocfs2_search_extent_list ^---failed to find extent ...
 unlock ip_alloc_sem

 In most filesystems, fallocate is not compatible with racing with AIO+DIO, so fix it by adding to wait for all dio before fallocate/punch_hole like ext4.

 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-38618:
 In the Linux kernel, the following vulnerability has been resolved:

 ALSA: timer: Set lower bound of start tick time

 Currently ALSA timer doesn't have the lower limit of the start tick time, and it allows a very small size, e.g. 1 tick with 1ns resolution for hrtimer. Such a situation may lead to an unexpected RCU stall, where the callback repeatedly queuing the expire update, as reported by fuzzer.

 This patch introduces a sanity check of the timer start tick time, so that the system returns an error when a too small start size is set.
 As of this patch, the lower limit is hard-coded to 100us, which is small enough but can still work somehow.

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

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

Plugin Details

Severity: High

ID: 238604

File Name: tencentos_TSSA_2024_0720.nasl

Version: 1.2

Type: local

Published: 6/16/2025

Updated: 11/20/2025

Supported Sensors: Nessus

Risk Information

VPR

Risk Factor: Medium

Score: 6.7

CVSS v2

Risk Factor: High

Base Score: 7.4

Temporal Score: 5.8

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

CVSS Score Source: CVE-2021-4157

CVSS v3

Risk Factor: High

Base Score: 8

Temporal Score: 7.2

Vector: CVSS:3.0/AV:A/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

Vulnerability Information

CPE: cpe:/o:tencent:tencentos_server:2, 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: 11/4/2024

Vulnerability Publication Date: 11/4/2024

Reference Information

CVE: CVE-2020-16119, CVE-2021-3489, CVE-2021-3732, CVE-2021-3744, CVE-2021-4149, CVE-2021-4157, CVE-2021-46908, CVE-2021-47189, CVE-2021-47277, CVE-2021-47289, CVE-2021-47335, CVE-2021-47505, CVE-2022-48734, CVE-2022-48747, CVE-2022-48809, CVE-2022-48931, CVE-2023-52741, CVE-2023-52799, CVE-2023-52805, CVE-2023-52813, CVE-2024-26589, CVE-2024-26982, CVE-2024-36917, CVE-2024-36953, CVE-2024-36964, CVE-2024-36969, CVE-2024-38578, CVE-2024-38579, CVE-2024-38582, CVE-2024-38583, CVE-2024-38599, CVE-2024-38618, CVE-2024-39276, CVE-2024-39467, CVE-2024-39469, CVE-2024-40902, CVE-2024-40943, CVE-2024-40945, CVE-2024-40984, CVE-2024-40988, CVE-2024-41012, CVE-2024-41059, CVE-2024-42084, CVE-2024-42104, CVE-2024-42105, CVE-2024-42115, CVE-2024-42161, CVE-2024-42252, CVE-2024-42265, CVE-2024-42292, CVE-2024-44954