Detections
Analytics

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

high Nessus Plugin ID 239541

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

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

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

 drm/vmwgfx: Fix invalid reads in fence signaled events

 Correctly set the length of the drm_event to the size of the structure that's actually used.

 The length of the drm_event was set to the parent structure instead of to the drm_vmw_event_fence which is supposed to be read. drm_read uses the length parameter to copy the event to the user space thus resuling in oob reads.

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

 i2c: smbus: fix NULL function pointer dereference

 Baruch reported an OOPS when using the designware controller as target only. Target-only modes break the assumption of one transfer function always being available. Fix this by always checking the pointer in
 __i2c_transfer.

 [wsa: dropped the simplification in core-smbus to avoid theoretical regressions]

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

 drm/client: Fully protect modes[] with dev->mode_config.mutex

 The modes[] array contains pointers to modes on the connectors' mode lists, which are protected by dev->mode_config.mutex.
 Thus we need to extend modes[] the same protection or by the time we use it the elements may already be pointing to freed/reused memory.

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

 VMCI: Fix memcpy() run-time warning in dg_dispatch_as_host()

 Syzkaller hit 'WARNING in dg_dispatch_as_host' bug.

 memcpy: detected field-spanning write (size 56) of single field &dg_info->msg at drivers/misc/vmw_vmci/vmci_datagram.c:237 (size 24)

 WARNING: CPU: 0 PID: 1555 at drivers/misc/vmw_vmci/vmci_datagram.c:237 dg_dispatch_as_host+0x88e/0xa60 drivers/misc/vmw_vmci/vmci_datagram.c:237

 Some code commentry, based on my understanding:

 544 #define VMCI_DG_SIZE(_dg) (VMCI_DG_HEADERSIZE + (size_t)(_dg)->payload_size) /// This is 24 + payload_size

 memcpy(&dg_info->msg, dg, dg_size);
 Destination = dg_info->msg ---> this is a 24 byte structure(struct vmci_datagram) Source = dg --> this is a 24 byte structure (struct vmci_datagram) Size = dg_size = 24 + payload_size

 {payload_size = 56-24 =32} -- Syzkaller managed to set payload_size to 32.

 35 struct delayed_datagram_info { 36 struct datagram_entry *entry;
 37 struct work_struct work;
 38 bool in_dg_host_queue;
 39 /* msg and msg_payload must be together. */ 40 struct vmci_datagram msg;
 41 u8 msg_payload[];
 42 };

 So those extra bytes of payload are copied into msg_payload[], a run time warning is seen while fuzzing with Syzkaller.

 One possible way to fix the warning is to split the memcpy() into two parts -- one -- direct assignment of msg and second taking care of payload.

 Gustavo quoted:
 Under FORTIFY_SOURCE we should not copy data across multiple members in a structure.

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

 Bluetooth: btintel: Fix null ptr deref in btintel_read_version

 If hci_cmd_sync_complete() is triggered and skb is NULL, then hdev->req_skb is NULL, which will cause this issue.

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

 scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()

 The call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an unsuccessful status. In such cases, the elsiocb is not issued, the completion is not called, and thus the elsiocb resource is leaked.

 Check return value after calling lpfc_sli4_resume_rpi() and conditionally release the elsiocb resource.

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

 fbmon: prevent division by zero in fb_videomode_from_videomode()

 The expression htotal * vtotal can have a zero value on overflow. It is necessary to prevent division by zero like in fb_var_to_videomode().

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

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

 netfilter: nf_tables: flush pending destroy work before exit_net release

 Similar to 2c9f0293280e (netfilter: nf_tables: flush pending destroy work before netlink notifier) to address a race between exit_net and the destroy workqueue.

 The trace below shows an element to be released via destroy workqueue while exit_net path (triggered via module removal) has already released the set that is used in such transaction.

 [ 1360.547789] BUG: KASAN: slab-use-after-free in nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.547861] Read of size 8 at addr ffff888140500cc0 by task kworker/4:1/152465 [ 1360.547870] CPU: 4 PID: 152465 Comm: kworker/4:1 Not tainted 6.8.0+ #359 [ 1360.547882] Workqueue: events nf_tables_trans_destroy_work [nf_tables] [ 1360.547984] Call Trace:
 [ 1360.547991] <TASK> [ 1360.547998] dump_stack_lvl+0x53/0x70 [ 1360.548014] print_report+0xc4/0x610 [ 1360.548026] ? __virt_addr_valid+0xba/0x160 [ 1360.548040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 1360.548054] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548176] kasan_report+0xae/0xe0 [ 1360.548189] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548312] nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548447] ? __pfx_nf_tables_trans_destroy_work+0x10/0x10 [nf_tables] [ 1360.548577] ? _raw_spin_unlock_irq+0x18/0x30 [ 1360.548591] process_one_work+0x2f1/0x670 [ 1360.548610] worker_thread+0x4d3/0x760 [ 1360.548627] ? __pfx_worker_thread+0x10/0x10 [ 1360.548640] kthread+0x16b/0x1b0 [ 1360.548653] ? __pfx_kthread+0x10/0x10 [ 1360.548665] ret_from_fork+0x2f/0x50 [ 1360.548679] ? __pfx_kthread+0x10/0x10 [ 1360.548690] ret_from_fork_asm+0x1a/0x30 [ 1360.548707] </TASK>

 [ 1360.548719] Allocated by task 192061:
 [ 1360.548726] kasan_save_stack+0x20/0x40 [ 1360.548739] kasan_save_track+0x14/0x30 [ 1360.548750] __kasan_kmalloc+0x8f/0xa0 [ 1360.548760] __kmalloc_node+0x1f1/0x450 [ 1360.548771] nf_tables_newset+0x10c7/0x1b50 [nf_tables] [ 1360.548883] nfnetlink_rcv_batch+0xbc4/0xdc0 [nfnetlink] [ 1360.548909] nfnetlink_rcv+0x1a8/0x1e0 [nfnetlink] [ 1360.548927] netlink_unicast+0x367/0x4f0 [ 1360.548935] netlink_sendmsg+0x34b/0x610 [ 1360.548944] ____sys_sendmsg+0x4d4/0x510 [ 1360.548953] ___sys_sendmsg+0xc9/0x120 [ 1360.548961] __sys_sendmsg+0xbe/0x140 [ 1360.548971] do_syscall_64+0x55/0x120 [ 1360.548982] entry_SYSCALL_64_after_hwframe+0x55/0x5d

 [ 1360.548994] Freed by task 192222:
 [ 1360.548999] kasan_save_stack+0x20/0x40 [ 1360.549009] kasan_save_track+0x14/0x30 [ 1360.549019] kasan_save_free_info+0x3b/0x60 [ 1360.549028] poison_slab_object+0x100/0x180 [ 1360.549036] __kasan_slab_free+0x14/0x30 [ 1360.549042] kfree+0xb6/0x260 [ 1360.549049] __nft_release_table+0x473/0x6a0 [nf_tables] [ 1360.549131] nf_tables_exit_net+0x170/0x240 [nf_tables] [ 1360.549221] ops_exit_list+0x50/0xa0 [ 1360.549229] free_exit_list+0x101/0x140 [ 1360.549236] unregister_pernet_operations+0x107/0x160 [ 1360.549245] unregister_pernet_subsys+0x1c/0x30 [ 1360.549254] nf_tables_module_exit+0x43/0x80 [nf_tables] [ 1360.549345] __do_sys_delete_module+0x253/0x370 [ 1360.549352] do_syscall_64+0x55/0x120 [ 1360.549360] entry_SYSCALL_64_after_hwframe+0x55/0x5d

 (gdb) list *__nft_release_table+0x473 0x1e033 is in __nft_release_table (net/netfilter/nf_tables_api.c:11354).
 11349 list_for_each_entry_safe(flowtable, nf, &table->flowtables, list) { 11350 list_del(&flowtable->list);
 11351 nft_use_dec(&table->use);
 11352 nf_tables_flowtable_destroy(flowtable);
 11353 } 11354 list_for_each_entry_safe(set, ns, &table->sets, list) { 11355 list_del(&set->list);
 11356 nft_use_dec(&table->use);
 11357 if (set->flags & (NFT_SET_MAP | NFT_SET_OBJECT)) 11358 nft_map_deactivat
 ---truncated---

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

 netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get()

 nft_unregister_flowtable_type() within nf_flow_inet_module_exit() can concurrent with __nft_flowtable_type_get() within nf_tables_newflowtable().
 And thhere is not any protection when iterate over nf_tables_flowtables list in __nft_flowtable_type_get(). Therefore, there is pertential data-race of nf_tables_flowtables list entry.

 Use list_for_each_entry_rcu() to iterate over nf_tables_flowtables list in __nft_flowtable_type_get(), and use rcu_read_lock() in the caller nft_flowtable_type_get() to protect the entire type query process.

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

 net/sched: act_skbmod: prevent kernel-infoleak

 syzbot found that tcf_skbmod_dump() was copying four bytes from kernel stack to user space [1].

 The issue here is that 'struct tc_skbmod' has a four bytes hole.

 We need to clear the structure before filling fields.

 [1] BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline] BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline]
 _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 copy_to_iter include/linux/uio.h:196 [inline] simple_copy_to_iter net/core/datagram.c:532 [inline]
 __skb_datagram_iter+0x185/0x1000 net/core/datagram.c:420 skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546 skb_copy_datagram_msg include/linux/skbuff.h:4050 [inline] netlink_recvmsg+0x432/0x1610 net/netlink/af_netlink.c:1962 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x2c4/0x340 net/socket.c:1068
 __sys_recvfrom+0x35a/0x5f0 net/socket.c:2242
 __do_sys_recvfrom net/socket.c:2260 [inline]
 __se_sys_recvfrom net/socket.c:2256 [inline]
 __x64_sys_recvfrom+0x126/0x1d0 net/socket.c:2256 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75

 Uninit was stored to memory at:
 pskb_expand_head+0x30f/0x19d0 net/core/skbuff.c:2253 netlink_trim+0x2c2/0x330 net/netlink/af_netlink.c:1317 netlink_unicast+0x9f/0x1260 net/netlink/af_netlink.c:1351 nlmsg_unicast include/net/netlink.h:1144 [inline] nlmsg_notify+0x21d/0x2f0 net/netlink/af_netlink.c:2610 rtnetlink_send+0x73/0x90 net/core/rtnetlink.c:741 rtnetlink_maybe_send include/linux/rtnetlink.h:17 [inline] tcf_add_notify net/sched/act_api.c:2048 [inline] tcf_action_add net/sched/act_api.c:2071 [inline] tc_ctl_action+0x146e/0x19d0 net/sched/act_api.c:2119 rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559 rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg+0x30f/0x380 net/socket.c:745
 ____sys_sendmsg+0x877/0xb60 net/socket.c:2584
 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
 __sys_sendmsg net/socket.c:2667 [inline]
 __do_sys_sendmsg net/socket.c:2676 [inline]
 __se_sys_sendmsg net/socket.c:2674 [inline]
 __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75

 Uninit was stored to memory at:
 __nla_put lib/nlattr.c:1041 [inline] nla_put+0x1c6/0x230 lib/nlattr.c:1099 tcf_skbmod_dump+0x23f/0xc20 net/sched/act_skbmod.c:256 tcf_action_dump_old net/sched/act_api.c:1191 [inline] tcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227 tcf_action_dump+0x1fd/0x460 net/sched/act_api.c:1251 tca_get_fill+0x519/0x7a0 net/sched/act_api.c:1628 tcf_add_notify_msg net/sched/act_api.c:2023 [inline] tcf_add_notify net/sched/act_api.c:2042 [inline] tcf_action_add net/sched/act_api.c:2071 [inline] tc_ctl_action+0x1365/0x19d0 net/sched/act_api.c:2119 rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595 netlink_rcv_skb+0x375/0x650 net/netlink/af_netli
 ---truncated---

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

 media: v4l2-mem2mem: fix a memleak in v4l2_m2m_register_entity

 The entity->name (i.e. name) is allocated in v4l2_m2m_register_entity but isn't freed in its following error-handling paths. This patch adds such deallocation to prevent memleak of entity->name.

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

 media: imx: csc/scaler: fix v4l2_ctrl_handler memory leak

 Free the memory allocated in v4l2_ctrl_handler_init on release.

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

 USB: usb-storage: Prevent divide-by-0 error in isd200_ata_command

 The isd200 sub-driver in usb-storage uses the HEADS and SECTORS values in the ATA ID information to calculate cylinder and head values when creating a CDB for READ or WRITE commands. The calculation involves division and modulus operations, which will cause a crash if either of these values is 0. While this never happens with a genuine device, it could happen with a flawed or subversive emulation, as reported by the syzbot fuzzer.

 Protect against this possibility by refusing to bind to the device if either the ATA_ID_HEADS or ATA_ID_SECTORS value in the device's ID information is 0. This requires isd200_Initialization() to return a negative error code when initialization fails; currently it always returns 0 (even when there is an error).

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

 cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return value

 cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it and return 0 in case of error.

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

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

 nilfs2: fix OOB in nilfs_set_de_type

 The size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is defined as S_IFMT >> S_SHIFT, but the nilfs_set_de_type() function, which uses this array, specifies the index to read from the array in the same way as (mode & S_IFMT) >> S_SHIFT.

 static void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode
 *inode) { umode_t mode = inode->i_mode;

 de->file_type = nilfs_type_by_mode[(mode & S_IFMT)>>S_SHIFT]; // oob }

 However, when the index is determined this way, an out-of-bounds (OOB) error occurs by referring to an index that is 1 larger than the array size when the condition mode & S_IFMT == S_IFMT is satisfied. Therefore, a patch to resize the nilfs_type_by_mode array should be applied to prevent OOB errors.

 CVE-2023-52864:
 In the Linux kernel, the following vulnerability has been resolved:

 platform/x86: wmi: Fix opening of char device

 Since commit fa1f68db6ca7 (drivers: misc: pass miscdevice pointer via file private data), the miscdevice stores a pointer to itself inside filp->private_data, which means that private_data will not be NULL when wmi_char_open() is called. This might cause memory corruption should wmi_char_open() be unable to find its driver, something which can happen when the associated WMI device is deleted in wmi_free_devices().

 Fix the problem by using the miscdevice pointer to retrieve the WMI device data associated with a char device using container_of(). This also avoids wmi_char_open() picking a wrong WMI device bound to a driver with the same name as the original driver.

 CVE-2023-52832:
 In the Linux kernel, the following vulnerability has been resolved:

 wifi: mac80211: don't return unset power in ieee80211_get_tx_power()

 We can get a UBSAN warning if ieee80211_get_tx_power() returns the INT_MIN value mac80211 internally uses for unset power level.

 UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5
 -2147483648 * 100 cannot be represented in type 'int' CPU: 0 PID: 20433 Comm: insmod Tainted: G WC OE Call Trace:
 dump_stack+0x74/0x92 ubsan_epilogue+0x9/0x50 handle_overflow+0x8d/0xd0
 __ubsan_handle_mul_overflow+0xe/0x10 nl80211_send_iface+0x688/0x6b0 [cfg80211] [...] cfg80211_register_wdev+0x78/0xb0 [cfg80211] cfg80211_netdev_notifier_call+0x200/0x620 [cfg80211] [...] ieee80211_if_add+0x60e/0x8f0 [mac80211] ieee80211_register_hw+0xda5/0x1170 [mac80211]

 In this case, simply return an error instead, to indicate that no data is available.

 CVE-2023-52803:
 In the Linux kernel, the following vulnerability has been resolved:

 SUNRPC: Fix RPC client cleaned up the freed pipefs dentries

 RPC client pipefs dentries cleanup is in separated rpc_remove_pipedir() workqueue,which takes care about pipefs superblock locking.
 In some special scenarios, when kernel frees the pipefs sb of the current client and immediately alloctes a new pipefs sb, rpc_remove_pipedir function would misjudge the existence of pipefs sb which is not the one it used to hold. As a result, the rpc_remove_pipedir would clean the released freed pipefs dentries.

 To fix this issue, rpc_remove_pipedir should check whether the current pipefs sb is consistent with the original pipefs sb.

 This error can be catched by KASAN:
 ========================================================= [ 250.497700] BUG: KASAN: slab-use-after-free in dget_parent+0x195/0x200 [ 250.498315] Read of size 4 at addr ffff88800a2ab804 by task kworker/0:18/106503 [ 250.500549] Workqueue: events rpc_free_client_work [ 250.501001] Call Trace:
 [ 250.502880] kasan_report+0xb6/0xf0 [ 250.503209] ? dget_parent+0x195/0x200 [ 250.503561] dget_parent+0x195/0x200 [ 250.503897] ? __pfx_rpc_clntdir_depopulate+0x10/0x10 [ 250.504384] rpc_rmdir_depopulate+0x1b/0x90 [ 250.504781] rpc_remove_client_dir+0xf5/0x150 [ 250.505195] rpc_free_client_work+0xe4/0x230 [ 250.505598] process_one_work+0x8ee/0x13b0 ...
 [ 22.039056] Allocated by task 244:
 [ 22.039390] kasan_save_stack+0x22/0x50 [ 22.039758] kasan_set_track+0x25/0x30 [ 22.040109] __kasan_slab_alloc+0x59/0x70 [ 22.040487] kmem_cache_alloc_lru+0xf0/0x240 [ 22.040889] __d_alloc+0x31/0x8e0 [ 22.041207] d_alloc+0x44/0x1f0 [ 22.041514] __rpc_lookup_create_exclusive+0x11c/0x140 [ 22.041987] rpc_mkdir_populate.constprop.0+0x5f/0x110 [ 22.042459] rpc_create_client_dir+0x34/0x150 [ 22.042874] rpc_setup_pipedir_sb+0x102/0x1c0 [ 22.043284] rpc_client_register+0x136/0x4e0 [ 22.043689] rpc_new_client+0x911/0x1020 [ 22.044057] rpc_create_xprt+0xcb/0x370 [ 22.044417] rpc_create+0x36b/0x6c0 ...
 [ 22.049524] Freed by task 0:
 [ 22.049803] kasan_save_stack+0x22/0x50 [ 22.050165] kasan_set_track+0x25/0x30 [ 22.050520] kasan_save_free_info+0x2b/0x50 [ 22.050921] __kasan_slab_free+0x10e/0x1a0 [ 22.051306] kmem_cache_free+0xa5/0x390 [ 22.051667] rcu_core+0x62c/0x1930 [ 22.051995] __do_softirq+0x165/0x52a [ 22.052347] [ 22.052503] Last potentially related work creation:
 [ 22.052952] kasan_save_stack+0x22/0x50 [ 22.053313] __kasan_record_aux_stack+0x8e/0xa0 [ 22.053739] __call_rcu_common.constprop.0+0x6b/0x8b0 [ 22.054209] dentry_free+0xb2/0x140 [ 22.054540] __dentry_kill+0x3be/0x540 [ 22.054900] shrink_dentry_list+0x199/0x510 [ 22.055293] shrink_dcache_parent+0x190/0x240 [ 22.055703] do_one_tree+0x11/0x40 [ 22.056028] shrink_dcache_for_umount+0x61/0x140 [ 22.056461] generic_shutdown_super+0x70/0x590 [ 22.056879] kill_anon_super+0x3a/0x60 [ 22.057234] rpc_kill_sb+0x121/0x200

 CVE-2023-52781:
 In the Linux kernel, the following vulnerability has been resolved:

 usb: config: fix iteration issue in 'usb_get_bos_descriptor()'

 The BOS descriptor defines a root descriptor and is the base descriptor for accessing a family of related descriptors.

 Function 'usb_get_bos_descriptor()' encounters an iteration issue when skipping the 'USB_DT_DEVICE_CAPABILITY' descriptor type. This results in the same descriptor being read repeatedly.

 To address this issue, a 'goto' statement is introduced to ensure that the pointer and the amount read is updated correctly. This ensures that the function iterates to the next descriptor instead of reading the same descriptor repeatedly.

 CVE-2023-52762:
 In the Linux kernel, the following vulnerability has been resolved:

 virtio-blk: fix implicit overflow on virtio_max_dma_size

 The following codes have an implicit conversion from size_t to u32:
 (u32)max_size = (size_t)virtio_max_dma_size(vdev);

 This may lead overflow, Ex (size_t)4G -> (u32)0. Once virtio_max_dma_size() has a larger size than U32_MAX, use U32_MAX instead.

 CVE-2023-52742:
 In the Linux kernel, the following vulnerability has been resolved:

 net: USB: Fix wrong-direction WARNING in plusb.c

 The syzbot fuzzer detected a bug in the plusb network driver: A zero-length control-OUT transfer was treated as a read instead of a write. In modern kernels this error provokes a WARNING:

 usb 1-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType c0 WARNING: CPU: 0 PID: 4645 at drivers/usb/core/urb.c:411 usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411 Modules linked in:
 CPU: 1 PID: 4645 Comm: dhcpcd Not tainted 6.2.0-rc6-syzkaller-00050-g9f266ccaa2f5 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023 RIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411 ...
 Call Trace:
 <TASK> usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [inline] usb_control_msg+0x320/0x4a0 drivers/usb/core/message.c:153
 __usbnet_read_cmd+0xb9/0x390 drivers/net/usb/usbnet.c:2010 usbnet_read_cmd+0x96/0xf0 drivers/net/usb/usbnet.c:2068 pl_vendor_req drivers/net/usb/plusb.c:60 [inline] pl_set_QuickLink_features drivers/net/usb/plusb.c:75 [inline] pl_reset+0x2f/0xf0 drivers/net/usb/plusb.c:85 usbnet_open+0xcc/0x5d0 drivers/net/usb/usbnet.c:889
 __dev_open+0x297/0x4d0 net/core/dev.c:1417
 __dev_change_flags+0x587/0x750 net/core/dev.c:8530 dev_change_flags+0x97/0x170 net/core/dev.c:8602 devinet_ioctl+0x15a2/0x1d70 net/ipv4/devinet.c:1147 inet_ioctl+0x33f/0x380 net/ipv4/af_inet.c:979 sock_do_ioctl+0xcc/0x230 net/socket.c:1169 sock_ioctl+0x1f8/0x680 net/socket.c:1286 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:870 [inline]
 __se_sys_ioctl fs/ioctl.c:856 [inline]
 __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd

 The fix is to call usbnet_write_cmd() instead of usbnet_read_cmd() and remove the USB_DIR_IN flag.

 CVE-2023-52698:
 In the Linux kernel, the following vulnerability has been resolved:

 calipso: fix memory leak in netlbl_calipso_add_pass()

 If IPv6 support is disabled at boot (ipv6.disable=1), the calipso_init() -> netlbl_calipso_ops_register() function isn't called, and the netlbl_calipso_ops_get() function always returns NULL.
 In this case, the netlbl_calipso_add_pass() function allocates memory for the doi_def variable but doesn't free it with the calipso_doi_free().

 BUG: memory leak unreferenced object 0xffff888011d68180 (size 64):
 comm syz-executor.1, pid 10746, jiffies 4295410986 (age 17.928s) hex dump (first 32 bytes):
 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
 backtrace:
 [<...>] kmalloc include/linux/slab.h:552 [inline] [<...>] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [inline] [<...>] netlbl_calipso_add+0x22e/0x4f0 net/netlabel/netlabel_calipso.c:111 [<...>] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739 [<...>] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] [<...>] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800 [<...>] netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2515 [<...>] genl_rcv+0x29/0x40 net/netlink/genetlink.c:811 [<...>] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] [<...>] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1339 [<...>] netlink_sendmsg+0x90a/0xdf0 net/netlink/af_netlink.c:1934 [<...>] sock_sendmsg_nosec net/socket.c:651 [inline] [<...>] sock_sendmsg+0x157/0x190 net/socket.c:671 [<...>] ____sys_sendmsg+0x712/0x870 net/socket.c:2342 [<...>] ___sys_sendmsg+0xf8/0x170 net/socket.c:2396 [<...>] __sys_sendmsg+0xea/0x1b0 net/socket.c:2429 [<...>] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 [<...>] entry_SYSCALL_64_after_hwframe+0x61/0xc6

 Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller

 [PM: merged via the LSM tree at Jakub Kicinski request]

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

 drm/radeon: fix a possible null pointer dereference

 In radeon_fp_native_mode(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.

 The failure status of drm_cvt_mode() on the other path is checked too.

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

 net/sched: taprio: avoid disabling offload when it was never enabled

 In an in ...

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

Plugin Details

Severity: High

ID: 239541

File Name: tencentos_TSSA_2024_1029.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: 4.6

Temporal Score: 3.6

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

CVSS Score Source: CVE-2021-41864

CVSS v3

Risk Factor: High

Base Score: 7.8

Temporal Score: 7

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

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

CVSS Score Source: CVE-2024-26981

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: 12/4/2024

Vulnerability Publication Date: 12/4/2024

Reference Information

CVE: CVE-2021-34693, CVE-2021-41864, CVE-2021-47223, CVE-2021-47232, CVE-2021-47235, CVE-2021-47236, CVE-2021-47238, CVE-2021-47239, CVE-2021-47243, CVE-2021-47245, CVE-2021-47246, CVE-2021-47248, CVE-2021-47249, CVE-2021-47250, CVE-2021-47252, CVE-2021-47257, CVE-2021-47291, CVE-2021-47293, CVE-2021-47297, CVE-2021-47319, CVE-2021-47347, CVE-2021-47372, CVE-2021-47397, CVE-2021-47400, CVE-2021-47402, CVE-2021-47416, CVE-2021-47418, CVE-2021-47419, CVE-2021-47424, CVE-2021-47515, CVE-2021-47516, CVE-2021-47518, CVE-2021-47538, CVE-2021-47541, CVE-2021-47542, CVE-2022-48639, CVE-2022-48644, CVE-2022-48710, CVE-2023-52698, CVE-2023-52742, CVE-2023-52762, CVE-2023-52781, CVE-2023-52803, CVE-2023-52832, CVE-2023-52864, CVE-2024-26981, CVE-2024-27051, CVE-2024-27059, CVE-2024-27076, CVE-2024-27077, CVE-2024-35893, CVE-2024-35898, CVE-2024-35899, CVE-2024-35922, CVE-2024-35930, CVE-2024-35933, CVE-2024-35944, CVE-2024-35950, CVE-2024-35984, CVE-2024-36960