Detections
Analytics

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

high Nessus Plugin ID 276179

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

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

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

 net/mlx5: Fix command stats access after free

 Command may fail while driver is reloading and can't accept FW commands till command interface is reinitialized. Such command failure is being logged to command stats. This results in NULL pointer access as command stats structure is being freed and reallocated during mlx5 devlink reload (see kernel log below).

 Fix it by making command stats statically allocated on driver probe.

 Kernel log:
 [ 2394.808802] BUG: unable to handle kernel paging request at 000000000002a9c0 [ 2394.810610] PGD 0 P4D 0 [ 2394.811811] Oops: 0002 [#1] SMP NOPTI ...
 [ 2394.815482] RIP: 0010:native_queued_spin_lock_slowpath+0x183/0x1d0 ...
 [ 2394.829505] Call Trace:
 [ 2394.830667] _raw_spin_lock_irq+0x23/0x26 [ 2394.831858] cmd_status_err+0x55/0x110 [mlx5_core] [ 2394.833020] mlx5_access_reg+0xe7/0x150 [mlx5_core] [ 2394.834175] mlx5_query_port_ptys+0x78/0xa0 [mlx5_core] [ 2394.835337] mlx5e_ethtool_get_link_ksettings+0x74/0x590 [mlx5_core] [ 2394.836454] ? kmem_cache_alloc_trace+0x140/0x1c0 [ 2394.837562] __rh_call_get_link_ksettings+0x33/0x100 [ 2394.838663] ? __rtnl_unlock+0x25/0x50 [ 2394.839755] __ethtool_get_link_ksettings+0x72/0x150 [ 2394.840862] duplex_show+0x6e/0xc0 [ 2394.841963] dev_attr_show+0x1c/0x40 [ 2394.843048] sysfs_kf_seq_show+0x9b/0x100 [ 2394.844123] seq_read+0x153/0x410 [ 2394.845187] vfs_read+0x91/0x140 [ 2394.846226] ksys_read+0x4f/0xb0 [ 2394.847234] do_syscall_64+0x5b/0x1a0 [ 2394.848228] entry_SYSCALL_64_after_hwframe+0x65/0xca

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

 drm/vmwgfx: Remove rcu locks from user resources

 User resource lookups used rcu to avoid two extra atomics. Unfortunately the rcu paths were buggy and it was easy to make the driver crash by submitting command buffers from two different threads. Because the lookups never show up in performance profiles replace them with a regular spin lock which fixes the races in accesses to those shared resources.

 Fixes kernel oops'es in IGT's vmwgfx execution_buffer stress test and seen crashes with apps using shared resources.

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

 thermal: int340x: fix memory leak in int3400_notify()

 It is easy to hit the below memory leaks in my TigerLake platform:

 unreferenced object 0xffff927c8b91dbc0 (size 32):
 comm kworker/0:2, pid 112, jiffies 4294893323 (age 83.604s) hex dump (first 32 bytes):
 4e 41 4d 45 3d 49 4e 54 33 34 30 30 20 54 68 65 NAME=INT3400 The 72 6d 61 6c 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 rmal.kkkkkkkkkk.
 backtrace:
 [<ffffffff9c502c3e>] __kmalloc_track_caller+0x2fe/0x4a0 [<ffffffff9c7b7c15>] kvasprintf+0x65/0xd0 [<ffffffff9c7b7d6e>] kasprintf+0x4e/0x70 [<ffffffffc04cb662>] int3400_notify+0x82/0x120 [int3400_thermal] [<ffffffff9c8b7358>] acpi_ev_notify_dispatch+0x54/0x71 [<ffffffff9c88f1a7>] acpi_os_execute_deferred+0x17/0x30 [<ffffffff9c2c2c0a>] process_one_work+0x21a/0x3f0 [<ffffffff9c2c2e2a>] worker_thread+0x4a/0x3b0 [<ffffffff9c2cb4dd>] kthread+0xfd/0x130 [<ffffffff9c201c1f>] ret_from_fork+0x1f/0x30

 Fix it by calling kfree() accordingly.

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

 RDMA/cma: Do not change route.addr.src_addr outside state checks

 If the state is not idle then resolve_prepare_src() should immediately fail and no change to global state should happen. However, it unconditionally overwrites the src_addr trying to build a temporary any address.

 For instance if the state is already RDMA_CM_LISTEN then this will corrupt the src_addr and would cause the test in cma_cancel_operation():

 if (cma_any_addr(cma_src_addr(id_priv)) && !id_priv->cma_dev)

 Which would manifest as this trace from syzkaller:

 BUG: KASAN: use-after-free in __list_add_valid+0x93/0xa0 lib/list_debug.c:26 Read of size 8 at addr ffff8881546491e0 by task syz-executor.1/32204

 CPU: 1 PID: 32204 Comm: syz-executor.1 Not tainted 5.12.0-rc8-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace:
 __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x141/0x1d7 lib/dump_stack.c:120 print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:232
 __kasan_report mm/kasan/report.c:399 [inline] kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:416
 __list_add_valid+0x93/0xa0 lib/list_debug.c:26
 __list_add include/linux/list.h:67 [inline] list_add_tail include/linux/list.h:100 [inline] cma_listen_on_all drivers/infiniband/core/cma.c:2557 [inline] rdma_listen+0x787/0xe00 drivers/infiniband/core/cma.c:3751 ucma_listen+0x16a/0x210 drivers/infiniband/core/ucma.c:1102 ucma_write+0x259/0x350 drivers/infiniband/core/ucma.c:1732 vfs_write+0x28e/0xa30 fs/read_write.c:603 ksys_write+0x1ee/0x250 fs/read_write.c:658 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae

 This is indicating that an rdma_id_private was destroyed without doing cma_cancel_listens().

 Instead of trying to re-use the src_addr memory to indirectly create an any address derived from the dst build one explicitly on the stack and bind to that as any other normal flow would do. rdma_bind_addr() will copy it over the src_addr once it knows the state is valid.

 This is similar to commit bc0bdc5afaa7 (RDMA/cma: Do not change route.addr.src_addr.ss_family)

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

 iio: adc: tsc2046: fix memory corruption by preventing array overflow

 On one side we have indio_dev->num_channels includes all physical channels + timestamp channel. On other side we have an array allocated only for physical channels. So, fix memory corruption by ARRAY_SIZE() instead of num_channels variable.

 Note the first case is a cleanup rather than a fix as the software timestamp channel bit in active_scanmask is never set by the IIO core.

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

 gpio: amd8111: Fix PCI device reference count leak

 for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL.

 If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() after the 'out' label. Since pci_dev_put() can handle NULL input parameter, there is no problem for the 'Device not found' branch.
 For the normal path, add pci_dev_put() in amd_gpio_exit().

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

 char: tpm: Protect tpm_pm_suspend with locks

 Currently tpm transactions are executed unconditionally in tpm_pm_suspend() function, which may lead to races with other tpm accessors in the system.

 Specifically, the hw_random tpm driver makes use of tpm_get_random(), and this function is called in a loop from a kthread, which means it's not frozen alongside userspace, and so can race with the work done during system suspend:

 tpm tpm0: tpm_transmit: tpm_recv: error -52 tpm tpm0: invalid TPM_STS.x 0xff, dumping stack for forensics CPU: 0 PID: 1 Comm: init Not tainted 6.1.0-rc5+ #135 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014 Call Trace:
 tpm_tis_status.cold+0x19/0x20 tpm_transmit+0x13b/0x390 tpm_transmit_cmd+0x20/0x80 tpm1_pm_suspend+0xa6/0x110 tpm_pm_suspend+0x53/0x80
 __pnp_bus_suspend+0x35/0xe0
 __device_suspend+0x10f/0x350

 Fix this by calling tpm_try_get_ops(), which itself is a wrapper around tpm_chip_start(), but takes the appropriate mutex.

 [Jason: reworked commit message, added metadata]

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

 hwmon: (coretemp) Check for null before removing sysfs attrs

 If coretemp_add_core() gets an error then pdata->core_data[indx] is already NULL and has been kfreed. Don't pass that to sysfs_remove_group() as that will crash in sysfs_remove_group().

 [Shortened for readability] [91854.020159] sysfs: cannot create duplicate filename '/devices/platform/coretemp.0/hwmon/hwmon2/temp20_label' <cpu offline> [91855.126115] BUG: kernel NULL pointer dereference, address: 0000000000000188 [91855.165103] #PF: supervisor read access in kernel mode [91855.194506] #PF: error_code(0x0000) - not-present page [91855.224445] PGD 0 P4D 0 [91855.238508] Oops: 0000 [#1] PREEMPT SMP PTI ...
 [91855.342716] RIP: 0010:sysfs_remove_group+0xc/0x80 ...
 [91855.796571] Call Trace:
 [91855.810524] coretemp_cpu_offline+0x12b/0x1dd [coretemp] [91855.841738] ? coretemp_cpu_online+0x180/0x180 [coretemp] [91855.871107] cpuhp_invoke_callback+0x105/0x4b0 [91855.893432] cpuhp_thread_fun+0x8e/0x150 ...

 Fix this by checking for NULL first.

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

 iommu: Don't reserve 0-length IOVA region

 When the bootloader/firmware doesn't setup the framebuffers, their address and size are 0 in iommu-addresses property. If IOVA region is reserved with 0 length, then it ends up corrupting the IOVA rbtree with an entry which has pfn_hi < pfn_lo.
 If we intend to use display driver in kernel without framebuffer then it's causing the display IOMMU mappings to fail as entire valid IOVA space is reserved when address and length are passed as 0.
 An ideal solution would be firmware removing the iommu-addresses property and corresponding memory-region if display is not present.
 But the kernel should be able to handle this by checking for size of IOVA region and skipping the IOVA reservation if size is 0. Also, add a warning if firmware is requesting 0-length IOVA region reservation.

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

 drm/radeon: check the alloc_workqueue return value in radeon_crtc_init()

 check the alloc_workqueue return value in radeon_crtc_init() to avoid null-ptr-deref.

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

 binder: signal epoll threads of self-work

 In (e)poll mode, threads often depend on I/O events to determine when data is ready for consumption. Within binder, a thread may initiate a command via BINDER_WRITE_READ without a read buffer and then make use of epoll_wait() or similar to consume any responses afterwards.

 It is then crucial that epoll threads are signaled via wakeup when they queue their own work. Otherwise, they risk waiting indefinitely for an event leaving their work unhandled. What is worse, subsequent commands won't trigger a wakeup either as the thread has pending work.

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

 dma-mapping: benchmark: fix node id validation

 While validating node ids in map_benchmark_ioctl(), node_possible() may be provided with invalid argument outside of [0,MAX_NUMNODES-1] range leading to:

 BUG: KASAN: wild-memory-access in map_benchmark_ioctl (kernel/dma/map_benchmark.c:214) Read of size 8 at addr 1fffffff8ccb6398 by task dma_map_benchma/971 CPU: 7 PID: 971 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #37 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace:
 <TASK> dump_stack_lvl (lib/dump_stack.c:117) kasan_report (mm/kasan/report.c:603) kasan_check_range (mm/kasan/generic.c:189) variable_test_bit (arch/x86/include/asm/bitops.h:227) [inline] arch_test_bit (arch/x86/include/asm/bitops.h:239) [inline]
 _test_bit at (include/asm-generic/bitops/instrumented-non-atomic.h:142) [inline] node_state (include/linux/nodemask.h:423) [inline] map_benchmark_ioctl (kernel/dma/map_benchmark.c:214) full_proxy_unlocked_ioctl (fs/debugfs/file.c:333)
 __x64_sys_ioctl (fs/ioctl.c:890) do_syscall_64 (arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)

 Compare node ids with sane bounds first. NUMA_NO_NODE is considered a special valid case meaning that benchmarking kthreads won't be bound to a cpuset of a given node.

 Found by Linux Verification Center (linuxtesting.org).

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

 fpga: region: add owner module and take its refcount

 The current implementation of the fpga region assumes that the low-level module registers a driver for the parent device and uses its owner pointer to take the module's refcount. This approach is problematic since it can lead to a null pointer dereference while attempting to get the region during programming if the parent device does not have a driver.

 To address this problem, add a module owner pointer to the fpga_region struct and use it to take the module's refcount. Modify the functions for registering a region to take an additional owner module parameter and rename them to avoid conflicts. Use the old function names for helper macros that automatically set the module that registers the region as the owner. This ensures compatibility with existing low-level control modules and reduces the chances of registering a region without setting the owner.

 Also, update the documentation to keep it consistent with the new interface for registering an fpga region.

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

 fpga: bridge: add owner module and take its refcount

 The current implementation of the fpga bridge assumes that the low-level module registers a driver for the parent device and uses its owner pointer to take the module's refcount. This approach is problematic since it can lead to a null pointer dereference while attempting to get the bridge if the parent device does not have a driver.

 To address this problem, add a module owner pointer to the fpga_bridge struct and use it to take the module's refcount. Modify the function for registering a bridge to take an additional owner module parameter and rename it to avoid conflicts. Use the old function name for a helper macro that automatically sets the module that registers the bridge as the owner.
 This ensures compatibility with existing low-level control modules and reduces the chances of registering a bridge without setting the owner.

 Also, update the documentation to keep it consistent with the new interface for registering an fpga bridge.

 Other changes: opportunistically move put_device() from __fpga_bridge_get() to fpga_bridge_get() and of_fpga_bridge_get() to improve code clarity since the bridge device is taken in these functions.

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

 fpga: manager: add owner module and take its refcount

 The current implementation of the fpga manager assumes that the low-level module registers a driver for the parent device and uses its owner pointer to take the module's refcount. This approach is problematic since it can lead to a null pointer dereference while attempting to get the manager if the parent device does not have a driver.

 To address this problem, add a module owner pointer to the fpga_manager struct and use it to take the module's refcount. Modify the functions for registering the manager to take an additional owner module parameter and rename them to avoid conflicts. Use the old function names for helper macros that automatically set the module that registers the manager as the owner. This ensures compatibility with existing low-level control modules and reduces the chances of registering a manager without setting the owner.

 Also, update the documentation to keep it consistent with the new interface for registering an fpga manager.

 Other changes: opportunistically move put_device() from __fpga_mgr_get() to fpga_mgr_get() and of_fpga_mgr_get() to improve code clarity since the manager device is taken in these functions.

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

 drm/xe: Only use reserved BCS instances for usm migrate exec queue

 The GuC context scheduling queue is 2 entires deep, thus it is possible for a migration job to be stuck behind a fault if migration exec queue shares engines with user jobs. This can deadlock as the migrate exec queue is required to service page faults. Avoid deadlock by only using reserved BCS instances for usm migrate exec queue.

 (cherry picked from commit 04f4a70a183a688a60fe3882d6e4236ea02cfc67)

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

 drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails

 Calling a6xx_destroy() before adreno_gpu_init() leads to a null pointer dereference on:

 msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL);

 as gpu->pdev is only assigned in:

 a6xx_gpu_init() |_ adreno_gpu_init |_ msm_gpu_init()

 Instead of relying on handwavy null checks down the cleanup chain, explicitly de-allocate the LLC data and free a6xx_gpu instead.

 Patchwork: https://patchwork.freedesktop.org/patch/588919/

 CVE-2024-49860:


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

 s390/ap: Fix crash in AP internal function modify_bitmap()

 A system crash like this

 Failing address: 200000cb7df6f000 TEID: 200000cb7df6f403 Fault in home space mode while using kernel ASCE.
 AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d Oops: 0038 ilc:3 [#1] PREEMPT SMP Modules linked in: mlx5_ib ...
 CPU: 8 PID: 7556 Comm: bash Not tainted 6.9.0-rc7 #8 Hardware name: IBM 3931 A01 704 (LPAR) Krnl PSW : 0704e00180000000 0000014b75e7b606 (ap_parse_bitmap_str+0x10e/0x1f8) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 0000000000000001 ffffffffffffffc0 0000000000000001 00000048f96b75d3 000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7df6fce0 000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff 000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8 Krnl Code: 0000014b75e7b5fc: a7840047 brc 8,0000014b75e7b68a 0000014b75e7b600: 18b2 lr %r11,%r2 #0000014b75e7b602: a7f4000a brc 15,0000014b75e7b616 >0000014b75e7b606: eb22d00000e6 laog %r2,%r2,0(%r13) 0000014b75e7b60c: a7680001 lhi %r6,1 0000014b75e7b610: 187b lr %r7,%r11 0000014b75e7b612: 84960021 brxh %r9,%r6,0000014b75e7b654 0000014b75e7b616: 18e9 lr %r14,%r9 Call Trace:
 [<0000014b75e7b606>] ap_parse_bitmap_str+0x10e/0x1f8 ([<0000014b75e7b5dc>] ap_parse_bitmap_str+0xe4/0x1f8) [<0000014b75e7b758>] apmask_store+0x68/0x140 [<0000014b75679196>] kernfs_fop_write_iter+0x14e/0x1e8 [<0000014b75598524>] vfs_write+0x1b4/0x448 [<0000014b7559894c>] ksys_write+0x74/0x100 [<0000014b7618a440>] __do_syscall+0x268/0x328 [<0000014b761a3558>] system_call+0x70/0x98 INFO: lockdep is turned off.
 Last Breaking-Event-Address:
 [<0000014b75e7b636>] ap_parse_bitmap_str+0x13e/0x1f8 Kernel panic - not syncing: Fatal exception: panic_on_oops

 occured when /sys/bus/ap/a[pq]mask was updated with a relative mask value (like +0x10-0x12,+60,-90) with one of the numeric values exceeding INT_MAX.

 The fix is simple: use unsigned long values for the internal variables. The correct checks are already in place in the function but a simple int for the internal variables was used with the possibility to overflow.

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

 drm: zynqmp_dpsub: Always register bridge

 We must always register the DRM bridge, since zynqmp_dp_hpd_work_func calls drm_bridge_hpd_notify, which in turn expects hpd_mutex to be initialized. We do this before zynqmp_dpsub_drm_init since that calls drm_bridge_attach. This fixes the following lockdep warning:

 [ 19.217084] ------------[ cut here ]------------ [ 19.227530] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 19.227768] WARNING: CPU: 0 PID: 140 at kernel/locking/mutex.c:582 __mutex_lock+0x4bc/0x550 [ 19.241696] Modules linked in:
 [ 19.244937] CPU: 0 PID: 140 Comm: kworker/0:4 Not tainted 6.6.20+ #96 [ 19.252046] Hardware name: xlnx,zynqmp (DT) [ 19.256421] Workqueue: events zynqmp_dp_hpd_work_func [ 19.261795] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 19.269104] pc : __mutex_lock+0x4bc/0x550 [ 19.273364] lr : __mutex_lock+0x4bc/0x550 [ 19.277592] sp : ffffffc085c5bbe0 [ 19.281066] x29: ffffffc085c5bbe0 x28: 0000000000000000 x27: ffffff88009417f8 [ 19.288624] x26: ffffff8800941788 x25: ffffff8800020008 x24: ffffffc082aa3000 [ 19.296227] x23: ffffffc080d90e3c x22: 0000000000000002 x21: 0000000000000000 [ 19.303744] x20: 0000000000000000 x19: ffffff88002f5210 x18: 0000000000000000 [ 19.311295] x17: 6c707369642e3030 x16: 3030613464662072 x15: 0720072007200720 [ 19.318922] x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 0000000000000001 [ 19.326442] x11: 0001ffc085c5b940 x10: 0001ff88003f388b x9 : 0001ff88003f3888 [ 19.334003] x8 : 0001ff88003f3888 x7 : 0000000000000000 x6 : 0000000000000000 [ 19.341537] x5 : 0000000000000000 x4 : 0000000000001668 x3 : 0000000000000000 [ 19.349054] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff88003f3880 [ 19.356581] Call trace:
 [ 19.359160] __mutex_lock+0x4bc/0x550 [ 19.363032] mutex_lock_nested+0x24/0x30 [ 19.367187] drm_bridge_hpd_notify+0x2c/0x6c [ 19.371698] zynqmp_dp_hpd_work_func+0x44/0x54 [ 19.376364] process_one_work+0x3ac/0x988 [ 19.380660] worker_thread+0x398/0x694 [ 19.384736] kthread+0x1bc/0x1c0 [ 19.388241] ret_from_fork+0x10/0x20 [ 19.392031] irq event stamp: 183 [ 19.395450] hardirqs last enabled at (183): [<ffffffc0800b9278>] finish_task_switch.isra.0+0xa8/0x2d4 [ 19.405140] hardirqs last disabled at (182): [<ffffffc081ad3754>] __schedule+0x714/0xd04 [ 19.413612] softirqs last enabled at (114): [<ffffffc080133de8>] srcu_invoke_callbacks+0x158/0x23c [ 19.423128] softirqs last disabled at (110): [<ffffffc080133de8>] srcu_invoke_callbacks+0x158/0x23c [ 19.432614] ---[ end trace 0000000000000000 ]---

 (cherry picked from commit 61ba791c4a7a09a370c45b70a81b8c7d4cf6b2ae)

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

 drm/amdgpu: Fix buffer size in gfx_v9_4_3_init_ cp_compute_microcode() and rlc_microcode()

 The function gfx_v9_4_3_init_microcode in gfx_v9_4_3.c was generating about potential truncation of output when using the snprintf function.
 The issue was due to the size of the buffer 'ucode_prefix' being too small to accommodate the maximum possible length of the string being written into it.

 The string being written is amdgpu/%s_mec.bin or amdgpu/%s_rlc.bin, where %s is replaced by the value of 'chip_name'. The length of this string without the %s is 16 characters. The warning message indicated that 'chip_name' could be up to 29 characters long, resulting in a total of 45 characters, which exceeds the buffer size of 30 characters.

 To resolve this issue, the size of the 'ucode_prefix' buffer has been reduced from 30 to 15. This ensures that the maximum possible length of the string being written into the buffer will not exceed its size, thus preventing potential buffer overflow and truncation issues.

 Fixes the below with gcc W=1:
 drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c: In function gfx_v9_4_3_early_init:
 drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:379:52: warning: %s directive output may be truncated writing up to 29 bytes into a region of size 23 [-Wformat-truncation=] 379 | snprintf(fw_name, sizeof(fw_name), amdgpu/%s_rlc.bin, chip_name);
 | ^~ ......
 439 | r = gfx_v9_4_3_init_rlc_microcode(adev, ucode_prefix);
 | ~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:379:9: note: snprintf output between 16 and 45 bytes into a destination of size 30 379 | snprintf(fw_name, sizeof(fw_name), amdgpu/%s_rlc.bin, chip_name);
 | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:413:52: warning: %s directive output may be truncated writing up to 29 bytes into a region of size 23 [-Wformat-truncation=] 413 | snprintf(fw_name, sizeof(fw_name), amdgpu/%s_mec.bin, chip_name);
 | ^~ ......
 443 | r = gfx_v9_4_3_init_cp_compute_microcode(adev, ucode_prefix);
 | ~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:413:9: note: snprintf output between 16 and 45 bytes into a destination of size 30 413 | snprintf(fw_name, sizeof(fw_name), amdgpu/%s_mec.bin, chip_name);
 | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

 clk: bcm: rpi: Assign ->num before accessing ->hws

 Commit f316cdff8d67 (clk: Annotate struct clk_hw_onecell_data with
 __counted_by) annotated the hws member of 'struct clk_hw_onecell_data' with __counted_by, which informs the bounds sanitizer about the number of elements in hws, so that it can warn when hws is accessed out of bounds. As noted in that change, the __counted_by member must be initialized with the number of elements before the first array access happens, otherwise there will be a warning from each access prior to the initialization because the number of elements is zero. This occurs in raspberrypi_discover_clocks() due to ->num being assigned after ->hws has been accessed:

 UBSAN: array-index-out-of-bounds in drivers/clk/bcm/clk-raspberrypi.c:374:4 index 3 is out of range for type 'struct clk_hw *[] __counted_by(num)' (aka 'struct clk_hw *[]')

 Move the ->num initialization to before the first access of ->hws, which clears up the ...

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

Plugin Details

Severity: High

ID: 276179

File Name: tencentos_TSSA_2025_0046.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: Low

Base Score: 2.1

Temporal Score: 1.6

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

CVSS Score Source: CVE-2022-26878

CVSS v3

Risk Factor: High

Base Score: 7.8

Temporal Score: 6.8

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

CVSS Score Source: CVE-2024-50283

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 Ease: No known exploits are available

Patch Publication Date: 1/22/2025

Vulnerability Publication Date: 6/16/2021

Reference Information

CVE: CVE-2022-26878, CVE-2022-48884, CVE-2022-48887, CVE-2022-48924, CVE-2022-48925, CVE-2022-48927, CVE-2022-48973, CVE-2022-48997, CVE-2022-49010, CVE-2023-1075, CVE-2023-52455, CVE-2023-52470, CVE-2024-26606, CVE-2024-34777, CVE-2024-35247, CVE-2024-36479, CVE-2024-37021, CVE-2024-37026, CVE-2024-38390, CVE-2024-38661, CVE-2024-38664, CVE-2024-39291, CVE-2024-39461, CVE-2024-39462, CVE-2024-39464, CVE-2024-39465, CVE-2024-39466, CVE-2024-39471, CVE-2024-39475, CVE-2024-39476, CVE-2024-39479, CVE-2024-39484, CVE-2024-40901, CVE-2024-42100, CVE-2024-42101, CVE-2024-42128, CVE-2024-42129, CVE-2024-42146, CVE-2024-42152, CVE-2024-42223, CVE-2024-42248, CVE-2024-43883, CVE-2024-43900, CVE-2024-43906, CVE-2024-43909, CVE-2024-44956, CVE-2024-44976, CVE-2024-44983, CVE-2024-44984, CVE-2024-44985, CVE-2024-44993, CVE-2024-45009, CVE-2024-45011, CVE-2024-45013, CVE-2024-46689, CVE-2024-46703, CVE-2024-46711, CVE-2024-46717, CVE-2024-46719, CVE-2024-46746, CVE-2024-46775, CVE-2024-46800, CVE-2024-46858, CVE-2024-46869, CVE-2024-47664, CVE-2024-47672, CVE-2024-47688, CVE-2024-47693, CVE-2024-47712, CVE-2024-47718, CVE-2024-47749, CVE-2024-47752, CVE-2024-49860, CVE-2024-49879, CVE-2024-49891, CVE-2024-49895, CVE-2024-49911, CVE-2024-49916, CVE-2024-49918, CVE-2024-49936, CVE-2024-49961, CVE-2024-49970, CVE-2024-49986, CVE-2024-50001, CVE-2024-50005, CVE-2024-50026, CVE-2024-50033, CVE-2024-50038, CVE-2024-50048, CVE-2024-50062, CVE-2024-50071, CVE-2024-50095, CVE-2024-50101, CVE-2024-50267, CVE-2024-50276, CVE-2024-50283, CVE-2024-50285, CVE-2024-50299