Detections
Analytics

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

critical Nessus Plugin ID 239227

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

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

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

 nvme-pci: fix race condition between reset and nvme_dev_disable()

 nvme_dev_disable() modifies the dev->online_queues field, therefore nvme_pci_update_nr_queues() should avoid racing against it, otherwise we could end up passing invalid values to blk_mq_update_nr_hw_queues().

 WARNING: CPU: 39 PID: 61303 at drivers/pci/msi/api.c:347 pci_irq_get_affinity+0x187/0x210 Workqueue: nvme-reset-wq nvme_reset_work [nvme] RIP: 0010:pci_irq_get_affinity+0x187/0x210 Call Trace:
 <TASK> ? blk_mq_pci_map_queues+0x87/0x3c0 ? pci_irq_get_affinity+0x187/0x210 blk_mq_pci_map_queues+0x87/0x3c0 nvme_pci_map_queues+0x189/0x460 [nvme] blk_mq_update_nr_hw_queues+0x2a/0x40 nvme_reset_work+0x1be/0x2a0 [nvme]

 Fix the bug by locking the shutdown_lock mutex before using dev->online_queues. Give up if nvme_dev_disable() is running or if it has been executed already.

 CVE-2022-27950:
 rpmsg_virtio_add_ctrl_dev in drivers/rpmsg/virtio_rpmsg_bus.c in the Linux kernel before 5.18.4 has a double free.

 CVE-2024-49947:
 An issue was discovered in the Linux kernel through 5.16-rc6. There is a lack of check after calling vzalloc() and lack of free after allocation in drivers/media/test-drivers/vidtv/vidtv_s302m.c.

 CVE-2024-26752:
 A buffer overflow vulnerability was found in the Linux kernel Intels iSMT SMBus host controller driver in the way it handled the I2C_SMBUS_BLOCK_PROC_CALL case (via the ioctl I2C_SMBUS) with malicious input data. This flaw could allow a local user to crash the system.

 CVE-2022-3077:
 A heap-based buffer overflow was found in the Linux kernel's LightNVM subsystem. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a fixed-length heap-based buffer. This vulnerability allows a local attacker to escalate privileges and execute arbitrary code in the context of the kernel. The attacker must first obtain the ability to execute high-privileged code on the target system to exploit this vulnerability.

 CVE-2023-39179:
 In drivers/hid/hid-elo.c in the Linux kernel before 5.16.11, a memory leak exists for a certain hid_parse error condition.

 CVE-2021-47168:
 In drivers/usb/gadget/udc/udc-xilinx.c in the Linux kernel before 5.16.12, the endpoint index is not validated and might be manipulated by the host for out-of-array access.

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

 ext4: fix possible UAF when remounting r/o a mmp-protected file system

 After commit 618f003199c6 (ext4: fix memory leak in ext4_fill_super), after the file system is remounted read-only, there is a race where the kmmpd thread can exit, causing sbi->s_mmp_tsk to point at freed memory, which the call to ext4_stop_mmpd() can trip over.

 Fix this by only allowing kmmpd() to exit when it is stopped via ext4_stop_mmpd().

 Bug-Report-Link: <[email protected]>

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

 HID: magicmouse: fix NULL-deref on disconnect

 Commit 9d7b18668956 (HID: magicmouse: add support for Apple Magic Trackpad 2) added a sanity check for an Apple trackpad but returned success instead of -ENODEV when the check failed. This means that the remove callback will dereference the never-initialised driver data pointer when the driver is later unbound (e.g. on USB disconnect).

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

 usb: dwc3: core: Do core softreset when switch mode


 According to the programming guide, to switch mode for DRD controller, the driver needs to do the following.

 To switch from device to host:
 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(host mode) 3. Reset the host with USBCMD.HCRESET 4. Then follow up with the initializing host registers sequence

 To switch from host to device:
 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(device mode) 3. Reset the device with DCTL.CSftRst 4. Then follow up with the initializing registers sequence

 Currently we're missing step 1) to do GCTL.CoreSoftReset and step 3) of switching from host to device. John Stult reported a lockup issue seen with HiKey960 platform without these steps[1]. Similar issue is observed with Ferry's testing platform[2].

 So, apply the required steps along with some fixes to Yu Chen's and John Stultz's version. The main fixes to their versions are the missing wait for clocks synchronization before clearing GCTL.CoreSoftReset and only apply DCTL.CSftRst when switching from host to device.

 [1] https://lore.kernel.org/linux-usb/[email protected]/ [2] https://lore.kernel.org/linux-usb/[email protected]/

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

 security/keys: fix slab-out-of-bounds in key_task_permission

 KASAN reports an out of bounds read:
 BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362

 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace:
 __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400
 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585
 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793

 This issue was also reported by syzbot.

 It can be reproduced by following these steps(more details [1]):
 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'.
 2. Reboot and add the keys obtained in step 1.

 The reproducer demonstrates how this issue happened:
 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring.
 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function.
 However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK.
 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut.

 NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+

 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read.

 To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not.

 [1] https://lore.kernel.org/linux-kernel/[email protected]/

 [jarkko: tweaked the commit message a bit to have an appropriate closes tag.]

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

 smb: client: fix OOBs when building SMB2_IOCTL request

 When using encryption, either enforced by the server or when using 'seal' mount option, the client will squash all compound request buffers down for encryption into a single iov in smb2_set_next_command().

 SMB2_ioctl_init() allocates a small buffer (448 bytes) to hold the SMB2_IOCTL request in the first iov, and if the user passes an input buffer that is greater than 328 bytes, smb2_set_next_command() will end up writing off the end of @rqst->iov[0].iov_base as shown below:

 mount.cifs //srv/share /mnt -o ...,seal ln -s $(perl -e print('a')for 1..1024) /mnt/link

 BUG: KASAN: slab-out-of-bounds in smb2_set_next_command.cold+0x1d6/0x24c [cifs] Write of size 4116 at addr ffff8881148fcab8 by task ln/859

 CPU: 1 UID: 0 PID: 859 Comm: ln Not tainted 6.12.0-rc3 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Call Trace:
 <TASK> dump_stack_lvl+0x5d/0x80 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] print_report+0x156/0x4d9 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] ? __virt_addr_valid+0x145/0x310 ? __phys_addr+0x46/0x90 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_report+0xda/0x110 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_check_range+0x10f/0x1f0
 __asan_memcpy+0x3c/0x60 smb2_set_next_command.cold+0x1d6/0x24c [cifs] smb2_compound_op+0x238c/0x3840 [cifs] ? kasan_save_track+0x14/0x30 ? kasan_save_free_info+0x3b/0x70 ? vfs_symlink+0x1a1/0x2c0 ? do_symlinkat+0x108/0x1c0 ? __pfx_smb2_compound_op+0x10/0x10 [cifs] ? kmem_cache_free+0x118/0x3e0 ? cifs_get_writable_path+0xeb/0x1a0 [cifs] smb2_get_reparse_inode+0x423/0x540 [cifs] ? __pfx_smb2_get_reparse_inode+0x10/0x10 [cifs] ? rcu_is_watching+0x20/0x50 ? __kmalloc_noprof+0x37c/0x480 ? smb2_create_reparse_symlink+0x257/0x490 [cifs] ? smb2_create_reparse_symlink+0x38f/0x490 [cifs] smb2_create_reparse_symlink+0x38f/0x490 [cifs] ? __pfx_smb2_create_reparse_symlink+0x10/0x10 [cifs] ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? __build_path_from_dentry_optional_prefix+0x19d/0x2e0 [cifs] cifs_symlink+0x24f/0x960 [cifs] ? __pfx_make_vfsuid+0x10/0x10 ? __pfx_cifs_symlink+0x10/0x10 [cifs] ? make_vfsgid+0x6b/0xc0 ? generic_permission+0x96/0x2d0 vfs_symlink+0x1a1/0x2c0 do_symlinkat+0x108/0x1c0 ? __pfx_do_symlinkat+0x10/0x10 ? strncpy_from_user+0xaa/0x160
 __x64_sys_symlinkat+0xb9/0xf0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f08d75c13bb

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

 nilfs2: fix kernel bug due to missing clearing of buffer delay flag

 Syzbot reported that after nilfs2 reads a corrupted file system image and degrades to read-only, the BUG_ON check for the buffer delay flag in submit_bh_wbc() may fail, causing a kernel bug.

 This is because the buffer delay flag is not cleared when clearing the buffer state flags to discard a page/folio or a buffer head. So, fix this.

 This became necessary when the use of nilfs2's own page clear routine was expanded. This state inconsistency does not occur if the buffer is written normally by log writing.

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

 smb: client: Handle kstrdup failures for passwords

 In smb3_reconfigure(), after duplicating ctx->password and ctx->password2 with kstrdup(), we need to check for allocation failures.

 If ses->password allocation fails, return -ENOMEM.
 If ses->password2 allocation fails, free ses->password, set it to NULL, and return -ENOMEM.

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

 drm/amd: Guard against bad data for ATIF ACPI method

 If a BIOS provides bad data in response to an ATIF method call this causes a NULL pointer dereference in the caller.

 ``` ? show_regs (arch/x86/kernel/dumpstack.c:478 (discriminator 1)) ? __die (arch/x86/kernel/dumpstack.c:423 arch/x86/kernel/dumpstack.c:434) ? page_fault_oops (arch/x86/mm/fault.c:544 (discriminator 2) arch/x86/mm/fault.c:705 (discriminator 2)) ? do_user_addr_fault (arch/x86/mm/fault.c:440 (discriminator 1) arch/x86/mm/fault.c:1232 (discriminator 1)) ? acpi_ut_update_object_reference (drivers/acpi/acpica/utdelete.c:642) ? exc_page_fault (arch/x86/mm/fault.c:1542) ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:387 (discriminator 2)) amdgpu ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:386 (discriminator 1)) amdgpu ```

 It has been encountered on at least one system, so guard for it.

 (cherry picked from commit c9b7c809b89f24e9372a4e7f02d64c950b07fdee)

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

 cifs: Fix server re-repick on subrequest retry

 When a subrequest is marked for needing retry, netfs will call cifs_prepare_write() which will make cifs repick the server for the op before renegotiating credits; it then calls cifs_issue_write() which invokes smb2_async_writev() - which re-repicks the server.

 If a different server is then selected, this causes the increment of server->in_flight to happen against one record and the decrement to happen against another, leading to misaccounting.

 Fix this by just removing the repick code in smb2_async_writev(). As this is only called from netfslib-driven code, cifs_prepare_write() should always have been called first, and so server should never be NULL and the preparatory step is repeated in the event that we do a retry.

 The problem manifests as a warning looking something like:

 WARNING: CPU: 4 PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ...
 RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ...
 smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30

 Which may be triggered by a number of different xfstests running against an Azure server in multichannel mode. generic/249 seems the most repeatable, but generic/215, generic/249 and generic/308 may also show it.

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

 misc: microchip: pci1xxxx: fix double free in the error handling of gp_aux_bus_probe()

 When auxiliary_device_add() returns error and then calls auxiliary_device_uninit(), callback function gp_auxiliary_device_release() calls ida_free() and kfree(aux_device_wrapper) to free memory. We should't call them again in the error handling path.

 Fix this by skipping the redundant cleanup functions.

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

 uio_hv_generic: Don't free decrypted memory

 In CoCo VMs it is possible for the untrusted host to cause set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues.

 The VMBus device UIO driver could free decrypted/shared pages if set_memory_decrypted() fails. Check the decrypted field in the gpadl to decide whether to free the memory.

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

 Drivers: hv: vmbus: Don't free ring buffers that couldn't be re-encrypted

 In CoCo VMs it is possible for the untrusted host to cause set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues.

 The VMBus ring buffer code could free decrypted/shared pages if set_memory_decrypted() fails. Check the decrypted field in the struct vmbus_gpadl for the ring buffers to decide whether to free the memory.

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

 gpiolib: cdev: Fix use after free in lineinfo_changed_notify

 The use-after-free issue occurs as follows: when the GPIO chip device file is being closed by invoking gpio_chrdev_release(), watched_lines is freed by bitmap_free(), but the unregistration of lineinfo_changed_nb notifier chain failed due to waiting write rwsem. Additionally, one of the GPIO chip's lines is also in the release process and holds the notifier chain's read rwsem. Consequently, a race condition leads to the use-after-free of watched_lines.

 Here is the typical stack when issue happened:

 [free] gpio_chrdev_release()
 --> bitmap_free(cdev->watched_lines) <-- freed
 --> blocking_notifier_chain_unregister()
 --> down_write(&nh->rwsem) <-- waiting rwsem
 --> __down_write_common()
 --> rwsem_down_write_slowpath()
 --> schedule_preempt_disabled()
 --> schedule()

 [use] st54spi_gpio_dev_release()
 --> gpio_free()
 --> gpiod_free()
 --> gpiod_free_commit()
 --> gpiod_line_state_notify()
 --> blocking_notifier_call_chain()
 --> down_read(&nh->rwsem); <-- held rwsem
 --> notifier_call_chain()
 --> lineinfo_changed_notify()
 --> test_bit(xxxx, cdev->watched_lines) <-- use after free

 The side effect of the use-after-free issue is that a GPIO line event is being generated for userspace where it shouldn't. However, since the chrdev is being closed, userspace won't have the chance to read that event anyway.

 To fix the issue, call the bitmap_free() function after the unregistration of lineinfo_changed_nb notifier chain.

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

 gpiolib: cdev: fix uninitialised kfifo

 If a line is requested with debounce, and that results in debouncing in software, and the line is subsequently reconfigured to enable edge detection then the allocation of the kfifo to contain edge events is overlooked. This results in events being written to and read from an uninitialised kfifo. Read events are returned to userspace.

 Initialise the kfifo in the case where the software debounce is already active.

 CVE-2022-2991:
 A flaw was found within the handling of SMB2 read requests in the kernel ksmbd module. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. An attacker can leverage this to disclose sensitive information on affected installations of Linux. Only systems with ksmbd enabled are vulnerable to this CVE.

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

 NFS: fix an incorrect limit in filelayout_decode_layout()

 The sizeof(struct nfs_fh) is two bytes too large and could lead to memory corruption. It should be NFS_MAXFHSIZE because that's the size of the ->data[] buffer.

 I reversed the size of the arguments to put the variable on the left.

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

 ext4: fix bug on in ext4_es_cache_extent as ext4_split_extent_at failed

 We got follow bug_on when run fsstress with injecting IO fault:
 [130747.323114] kernel BUG at fs/ext4/extents_status.c:762! [130747.323117] Internal error: Oops - BUG: 0 [#1] SMP ......
 [130747.334329] Call trace:
 [130747.334553] ext4_es_cache_extent+0x150/0x168 [ext4] [130747.334975] ext4_cache_extents+0x64/0xe8 [ext4] [130747.335368] ext4_find_extent+0x300/0x330 [ext4] [130747.335759] ext4_ext_map_blocks+0x74/0x1178 [ext4] [130747.336179] ext4_map_blocks+0x2f4/0x5f0 [ext4] [130747.336567] ext4_mpage_readpages+0x4a8/0x7a8 [ext4] [130747.336995] ext4_readpage+0x54/0x100 [ext4] [130747.337359] generic_file_buffered_read+0x410/0xae8 [130747.337767] generic_file_read_iter+0x114/0x190 [130747.338152] ext4_file_read_iter+0x5c/0x140 [ext4] [130747.338556] __vfs_read+0x11c/0x188 [130747.338851] vfs_read+0x94/0x150 [130747.339110] ksys_read+0x74/0xf0

 This patch's modification is according to Jan Kara's suggestion in:
 https://patchwork.ozlabs.org/project/linux-ext4/patch/[email protected]/ I see. Now I understand your patch. Honestly, seeing how fragile is trying to fix extent tree after split has failed in the middle, I would probably go even further and make sure we fix the tree properly in case of ENOSPC and EDQUOT (those are easily user triggerable). Anything else indicates a HW problem or fs corruption so I'd rather leave the extent tree as is and don't try to fix it (which also means we will not create overlapping extents).

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

 ipmi: Fix UAF when uninstall ipmi_si and ipmi_msghandler module

 Hi,

 When testing install and uninstall of ipmi_si.ko and ipmi_msghandler.ko, the system crashed.

 The log as follows:
 [ 141.087026] BUG: unable to handle kernel paging request at ffffffffc09b3a5a [ 141.087241] PGD 8fe4c0d067 P4D 8fe4c0d067 PUD 8fe4c0f067 PMD 103ad89067 PTE 0 [ 141.087464] Oops: 0010 [#1] SMP NOPTI [ 141.087580] CPU: 67 PID: 668 Comm: kworker/67:1 Kdump: loaded Not tainted 4.18.0.x86_64 #47 [ 141.088009] Workqueue: events 0xffffffffc09b3a40 [ 141.088009] RIP: 0010:0xffffffffc09b3a5a [ 141.088009] Code: Bad RIP value.
 [ 141.088009] RSP: 0018:ffffb9094e2c3e88 EFLAGS: 00010246 [ 141.088009] RAX: 0000000000000000 RBX: ffff9abfdb1f04a0 RCX: 0000000000000000 [ 141.088009] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 [ 141.088009] RBP: 0000000000000000 R08: ffff9abfffee3cb8 R09: 00000000000002e1 [ 141.088009] R10: ffffb9094cb73d90 R11: 00000000000f4240 R12: ffff9abfffee8700 [ 141.088009] R13: 0000000000000000 R14: ffff9abfdb1f04a0 R15: ffff9abfdb1f04a8 [ 141.088009] FS: 0000000000000000(0000) GS:ffff9abfffec0000(0000) knlGS:0000000000000000 [ 141.088009] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 141.088009] CR2: ffffffffc09b3a30 CR3: 0000008fe4c0a001 CR4: 00000000007606e0 [ 141.088009] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 141.088009] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 141.088009] PKRU: 55555554 [ 141.088009] Call Trace:
 [ 141.088009] ? process_one_work+0x195/0x390 [ 141.088009] ? worker_thread+0x30/0x390 [ 141.088009] ? process_one_work+0x390/0x390 [ 141.088009] ? kthread+0x10d/0x130 [ 141.088009] ? kthread_flush_work_fn+0x10/0x10 [ 141.088009] ? ret_from_fork+0x35/0x40] BUG: unable to handle kernel paging request at ffffffffc0b28a5a [ 200.223240] PGD 97fe00d067 P4D 97fe00d067 PUD 97fe00f067 PMD a580cbf067 PTE 0 [ 200.223464] Oops: 0010 [#1] SMP NOPTI [ 200.223579] CPU: 63 PID: 664 Comm: kworker/63:1 Kdump: loaded Not tainted 4.18.0.x86_64 #46 [ 200.224008] Workqueue: events 0xffffffffc0b28a40 [ 200.224008] RIP: 0010:0xffffffffc0b28a5a [ 200.224008] Code: Bad RIP value.
 [ 200.224008] RSP: 0018:ffffbf3c8e2a3e88 EFLAGS: 00010246 [ 200.224008] RAX: 0000000000000000 RBX: ffffa0799ad6bca0 RCX: 0000000000000000 [ 200.224008] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 [ 200.224008] RBP: 0000000000000000 R08: ffff9fe43fde3cb8 R09: 00000000000000d5 [ 200.224008] R10: ffffbf3c8cb53d90 R11: 00000000000f4240 R12: ffff9fe43fde8700 [ 200.224008] R13: 0000000000000000 R14: ffffa0799ad6bca0 R15: ffffa0799ad6bca8 [ 200.224008] FS: 0000000000000000(0000) GS:ffff9fe43fdc0000(0000) knlGS:0000000000000000 [ 200.224008] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 200.224008] CR2: ffffffffc0b28a30 CR3: 00000097fe00a002 CR4: 00000000007606e0 [ 200.224008] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 200.224008] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 200.224008] PKRU: 55555554 [ 200.224008] Call Trace:
 [ 200.224008] ? process_one_work+0x195/0x390 [ 200.224008] ? worker_thread+0x30/0x390 [ 200.224008] ? process_one_work+0x390/0x390 [ 200.224008] ? kthread+0x10d/0x130 [ 200.224008] ? kthread_flush_work_fn+0x10/0x10 [ 200.224008] ? ret_from_fork+0x35/0x40 [ 200.224008] kernel fault(0x1) notification starting on CPU 63 [ 200.224008] kernel fault(0x1) notification finished on CPU 63 [ 200.224008] CR2: ffffffffc0b28a5a [ 200.224008] ---[ end trace c82a412d93f57412 ]---

 The reason is as follows:
 T1: rmmod ipmi_si.
 ->ipmi_unregister_smi()
 -> ipmi_bmc_unregister()
 -> __ipmi_bmc_unregister()
 -> kref_put(&bmc->usecount, cleanup_bmc_device);
 -> schedule_work(&bmc->remove_work);

 T2: rmmod ipmi_msghandl
 ---truncated---

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

 NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies()

 On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server.
 Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference crash with the following syslog:

 [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info:
 [232066.588701] ESR = 0x0000000096000007 [232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084] SET = 0, FnV = 0 [232066.589216] EA = 0, S1PTW = 0 [232066.589340] FSC = 0x07: level 3 translation fault [232066.589559] Data abort info:
 [232066.589683] ISV = 0, ISS = 0x00000007 [232066.589842] CM = 0, WnR = 0 [232066.589 ...

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

Plugin Details

Severity: Critical

ID: 239227

File Name: tencentos_TSSA_2025_0048.nasl

Version: 1.2

Type: local

Published: 6/16/2025

Updated: 11/20/2025

Supported Sensors: Nessus

Risk Information

VPR

Risk Factor: High

Score: 7.4

CVSS v2

Risk Factor: Medium

Base Score: 6.5

Temporal Score: 4.8

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

CVSS Score Source: CVE-2022-27223

CVSS v3

Risk Factor: Critical

Base Score: 9.8

Temporal Score: 8.5

Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Temporal Vector: CVSS:3.0/E:U/RL:O/RC:C

CVSS Score Source: CVE-2024-42256

Vulnerability Information

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

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

Exploit Ease: No known exploits are available

Patch Publication Date: 1/22/2025

Vulnerability Publication Date: 1/22/2025

Reference Information

CVE: CVE-2021-46941, CVE-2021-47100, CVE-2021-47117, CVE-2021-47120, CVE-2021-47168, CVE-2021-47342, CVE-2022-26966, CVE-2022-27223, CVE-2022-27950, CVE-2022-2991, CVE-2022-3077, CVE-2022-3078, CVE-2022-34494, CVE-2022-48742, CVE-2022-48967, CVE-2022-48999, CVE-2022-49021, CVE-2023-39179, CVE-2023-52702, CVE-2023-52703, CVE-2023-52735, CVE-2023-52775, CVE-2023-52777, CVE-2023-52778, CVE-2023-52780, CVE-2023-52782, CVE-2023-52783, CVE-2023-52843, CVE-2024-26752, CVE-2024-26910, CVE-2024-35901, CVE-2024-35907, CVE-2024-35908, CVE-2024-35909, CVE-2024-35910, CVE-2024-35911, CVE-2024-35912, CVE-2024-35934, CVE-2024-35937, CVE-2024-35938, CVE-2024-35945, CVE-2024-35946, CVE-2024-35958, CVE-2024-35959, CVE-2024-35960, CVE-2024-35961, CVE-2024-35962, CVE-2024-36011, CVE-2024-36012, CVE-2024-36898, CVE-2024-36899, CVE-2024-36909, CVE-2024-36910, CVE-2024-36938, CVE-2024-36941, CVE-2024-36945, CVE-2024-36954, CVE-2024-36957, CVE-2024-36973, CVE-2024-40980, CVE-2024-40981, CVE-2024-40983, CVE-2024-40993, CVE-2024-40995, CVE-2024-40996, CVE-2024-41005, CVE-2024-41006, CVE-2024-41007, CVE-2024-42256, CVE-2024-43912, CVE-2024-44944, CVE-2024-46673, CVE-2024-46763, CVE-2024-46795, CVE-2024-47730, CVE-2024-47738, CVE-2024-47743, CVE-2024-49938, CVE-2024-49947, CVE-2024-50012, CVE-2024-50046, CVE-2024-50077, CVE-2024-50116, CVE-2024-50117, CVE-2024-50120, CVE-2024-50135, CVE-2024-50151, CVE-2024-50158, CVE-2024-50172, CVE-2024-50216, CVE-2024-50218, CVE-2024-50243, CVE-2024-50247, CVE-2024-50248, CVE-2024-50273, CVE-2024-50286, CVE-2024-50301, CVE-2024-53060, CVE-2024-53109