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

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

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

    btrfs: fix information leak in btrfs_ioctl_logical_to_ino()

    Syzbot reported the following information leak for in     btrfs_ioctl_logical_to_ino():

    BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]     BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40      instrument_copy_to_user include/linux/instrumented.h:114 [inline]
     _copy_to_user+0xbc/0x110 lib/usercopy.c:40      copy_to_user include/linux/uaccess.h:191 [inline]      btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499      btrfs_ioctl+0x714/0x1260      vfs_ioctl fs/ioctl.c:51 [inline]
     __do_sys_ioctl fs/ioctl.c:904 [inline]
     __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890
     __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890      x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17      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:
     __kmalloc_large_node+0x231/0x370 mm/slub.c:3921
     __do_kmalloc_node mm/slub.c:3954 [inline]
     __kmalloc_node+0xb07/0x1060 mm/slub.c:3973      kmalloc_node include/linux/slab.h:648 [inline]      kvmalloc_node+0xc0/0x2d0 mm/util.c:634      kvmalloc include/linux/slab.h:766 [inline]      init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779      btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480      btrfs_ioctl+0x714/0x1260      vfs_ioctl fs/ioctl.c:51 [inline]
     __do_sys_ioctl fs/ioctl.c:904 [inline]
     __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890
     __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890      x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17      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

    Bytes 40-65535 of 65536 are uninitialized     Memory access of size 65536 starts at ffff888045a40000

    This happens, because we're copying a 'struct btrfs_data_container' back     to user-space. This btrfs_data_container is allocated in     'init_data_container()' via kvmalloc(), which does not zero-fill the     memory.

    Fix this by using kvzalloc() which zeroes out the memory on allocation.

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

    fs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversion

    The first kiocb_set_cancel_fn() argument may point at a struct kiocb     that is not embedded inside struct aio_kiocb. With the current code,     depending on the compiler, the req->ki_ctx read happens either before     the IOCB_AIO_RW test or after that test. Move the req->ki_ctx read such     that it is guaranteed that the IOCB_AIO_RW test happens first.

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

    ext4: fix corruption during on-line resize

    We observed a corruption during on-line resize of a file system that is     larger than 16 TiB with 4k block size. With having more then 2^32 blocks     resize_inode is turned off by default by mke2fs. The issue can be     reproduced on a smaller file system for convenience by explicitly     turning off resize_inode. An on-line resize across an 8 GiB boundary (the     size of a meta block group in this setup) then leads to a corruption:

    dev=/dev/<some_dev> # should be >= 16 GiB     mkdir -p /corruption     /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15))     mount -t ext4 $dev /corruption

    dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15))     sha1sum /corruption/test     # 79d2658b39dcfd77274e435b0934028adafaab11  /corruption/test

    /sbin/resize2fs $dev $((2*2**21))     # drop page cache to force reload the block from disk     echo 1 > /proc/sys/vm/drop_caches

    sha1sum /corruption/test     # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3  /corruption/test

    2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks per     block group and 2^6 are the number of block groups that make a meta     block group.

    The last checksum might be different depending on how the file is laid     out across the physical blocks. The actual corruption occurs at physical     block 63*2^15 = 2064384 which would be the location of the backup of the     meta block group's block descriptor. During the on-line resize the file     system will be converted to meta_bg starting at s_first_meta_bg which is     2 in the example - meaning all block groups after 16 GiB. However, in     ext4_flex_group_add we might add block groups that are not part of the     first meta block group yet. In the reproducer we achieved this by     substracting the size of a whole block group from the point where the     meta block group would start. This must be considered when updating the     backup block group descriptors to follow the non-meta_bg layout. The fix     is to add a test whether the group to add is already part of the meta     block group or not.

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

    fs: sysfs: Fix reference leak in sysfs_break_active_protection()

    The sysfs_break_active_protection() routine has an obvious reference     leak in its error path.  If the call to kernfs_find_and_get() fails then     kn will be NULL, so the companion sysfs_unbreak_active_protection()     routine won't get called (and would only cause an access violation by     trying to dereference kn->parent if it was called).  As a result, the     reference to kobj acquired at the start of the function will never be     released.

    Fix the leak by adding an explicit kobject_put() call when kn is NULL.

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

    fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaio

    If kiocb_set_cancel_fn() is called for I/O submitted via io_uring, the     following kernel warning appears:

    WARNING: CPU: 3 PID: 368 at fs/aio.c:598 kiocb_set_cancel_fn+0x9c/0xa8     Call trace:
     kiocb_set_cancel_fn+0x9c/0xa8      ffs_epfile_read_iter+0x144/0x1d0      io_read+0x19c/0x498      io_issue_sqe+0x118/0x27c      io_submit_sqes+0x25c/0x5fc
     __arm64_sys_io_uring_enter+0x104/0xab0      invoke_syscall+0x58/0x11c      el0_svc_common+0xb4/0xf4      do_el0_svc+0x2c/0xb0      el0_svc+0x2c/0xa4      el0t_64_sync_handler+0x68/0xb4      el0t_64_sync+0x1a4/0x1a8

    Fix this by setting the IOCB_AIO_RW flag for read and write I/O that is     submitted by libaio.

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

    nfsd: Fix nsfd startup race (again)

    Commit bd5ae9288d64 (nfsd: register pernet ops last, unregister first)     has re-opened rpc_pipefs_event() race against nfsd_net_id registration     (register_pernet_subsys()) which has been fixed by commit bb7ffbf29e76     (nfsd: fix nsfd startup race triggering BUG_ON).

    Restore the order of register_pernet_subsys() vs register_cld_notifier().
    Add WARN_ON() to prevent a future regression.

    Crash info:
    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000012     CPU: 8 PID: 345 Comm: mount Not tainted 5.4.144-... #1     pc : rpc_pipefs_event+0x54/0x120 [nfsd]     lr : rpc_pipefs_event+0x48/0x120 [nfsd]     Call trace:
     rpc_pipefs_event+0x54/0x120 [nfsd]      blocking_notifier_call_chain      rpc_fill_super      get_tree_keyed      rpc_fs_get_tree      vfs_get_tree      do_mount      ksys_mount
     __arm64_sys_mount      el0_svc_handler      el0_svc

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

    nfsd: fix use-after-free due to delegation race

    A delegation break could arrive as soon as we've called vfs_setlease.  A     delegation break runs a callback which immediately (in     nfsd4_cb_recall_prepare) adds the delegation to del_recall_lru.  If we     then exit nfs4_set_delegation without hashing the delegation, it will be     freed as soon as the callback is done with it, without ever being     removed from del_recall_lru.

    Symptoms show up later as use-after-free or list corruption warnings,     usually in the laundromat thread.

    I suspect aba2072f4523 nfsd: grant read delegations to clients holding     writes made this bug easier to hit, but I looked as far back as v3.0     and it looks to me it already had the same problem.  So I'm not sure     where the bug was introduced; it may have been there from the beginning.

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

    ocfs2: fix data corruption after conversion from inline format

    Commit 6dbf7bb55598 (fs: Don't invalidate page buffers in     block_write_full_page()) uncovered a latent bug in ocfs2 conversion     from inline inode format to a normal inode format.

    The code in ocfs2_convert_inline_data_to_extents() attempts to zero out     the whole cluster allocated for file data by grabbing, zeroing, and     dirtying all pages covering this cluster.  However these pages are     beyond i_size, thus writeback code generally ignores these dirty pages     and no blocks were ever actually zeroed on the disk.

    This oversight was fixed by commit 693c241a5f6a (ocfs2: No need to zero     pages past i_size.) for standard ocfs2 write path, inline conversion     path was apparently forgotten; the commit log also has a reasoning why     the zeroing actually is not needed.

    After commit 6dbf7bb55598, things became worse as writeback code stopped     invalidating buffers on pages beyond i_size and thus these pages end up     with clean PageDirty bit but with buffers attached to these pages being     still dirty.  So when a file is converted from inline format, then     writeback triggers, and then the file is grown so that these pages     become valid, the invalid dirtiness state is preserved,     mark_buffer_dirty() does nothing on these pages (buffers are already     dirty) but page is never written back because it is clean.  So data     written to these pages is lost once pages are reclaimed.

    Simple reproducer for the problem is:

    xfs_io -f -c pwrite 0 2000 -c pwrite 2000 2000 -c fsync \
      -c pwrite 4000 2000 ocfs2_file

    After unmounting and mounting the fs again, you can observe that end of     'ocfs2_file' has lost its contents.

    Fix the problem by not doing the pointless zeroing during conversion     from inline format similarly as in the standard write path.

    [akpm@linux-foundation.org: fix whitespace, per Joseph]

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

    ocfs2: mount fails with buffer overflow in strlen

    Starting with kernel 5.11 built with CONFIG_FORTIFY_SOURCE mouting an     ocfs2 filesystem with either o2cb or pcmk cluster stack fails with the     trace below.  Problem seems to be that strings for cluster stack and     cluster name are not guaranteed to be null terminated in the disk     representation, while strlcpy assumes that the source string is always     null terminated.  This causes a read outside of the source string     triggering the buffer overflow detection.

    detected buffer overflow in strlen
    ------------[ cut here ]------------     kernel BUG at lib/string.c:1149!     invalid opcode: 0000 [#1] SMP PTI     CPU: 1 PID: 910 Comm: mount.ocfs2 Not tainted 5.14.0-1-amd64 #1       Debian 5.14.6-2     RIP: 0010:fortify_panic+0xf/0x11     ...
    Call Trace:
     ocfs2_initialize_super.isra.0.cold+0xc/0x18 [ocfs2]      ocfs2_fill_super+0x359/0x19b0 [ocfs2]      mount_bdev+0x185/0x1b0      legacy_get_tree+0x27/0x40      vfs_get_tree+0x25/0xb0      path_mount+0x454/0xa20
     __x64_sys_mount+0x103/0x140      do_syscall_64+0x3b/0xc0      entry_SYSCALL_64_after_hwframe+0x44/0xae

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.

Detections

Analytics

TencentOS Server 3: kernel (TSSA-2024:1035)

high Nessus Plugin ID 239865

Version 1.2

Version 1.1

Version 1.2 Nov 21, 2025, 2:12 PM CVE (set "CVE" coverage to "CVE-2021-47458,CVE-2021-47460,CVE-2021-47478,CVE-2021-47506,CVE-2021-47507,CVE-2024-26764,CVE-2024-26993,CVE-2024-35807,CVE-2024-35815,CVE-2024-35849") CVSS metrics ("CVSSv2 score" set to 6.8) CVSS metrics ("CVSSv2 vector" set to "CVSS2#AV:L/AC:L/Au:S/C:C/I:C/A:C") CVSS metrics ("CVSSv3 score" set to 7.8) CVSS metrics ("CVSSv3 vector" set to "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H") CVSS temporal metrics ("CVSSv2 temporal vector" set to "CVSS2#E:U/RL:OF/RC:C") CVSS temporal metrics ("CVSSv3 temporal vector" set to "CVSS:3.0/E:U/RL:O/RC:C") CVSSv2 score source (set to "CVE-2021-47506") CVSSv2 severity (based on CVE-2021-47506, severity decreased from "High" to "Medium") Plugin metadata Plugin Feed: 202511211412
Version 1.1 Jun 17, 2025, 2:02 AM New Plugin Feed: 202506170202