Detections
Analytics

TencentOS Server 4: kernel (TSSA-2024:0981)

high Nessus Plugin ID 239342

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-2024:0981 advisory.

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

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

 btrfs: zoned: fix use-after-free due to race with dev replace

 While loading a zone's info during creation of a block group, we can race with a device replace operation and then trigger a use-after-free on the device that was just replaced (source device of the replace operation).

 This happens because at btrfs_load_zone_info() we extract a device from the chunk map into a local variable and then use the device while not under the protection of the device replace rwsem. So if there's a device replace operation happening when we extract the device and that device is the source of the replace operation, we will trigger a use-after-free if before we finish using the device the replace operation finishes and frees the device.

 Fix this by enlarging the critical section under the protection of the device replace rwsem so that all uses of the device are done inside the critical section.

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

 thermal/drivers/tsens: Fix null pointer dereference

 compute_intercept_slope() is called from calibrate_8960() (in tsens-8960.c) as compute_intercept_slope(priv, p1, NULL, ONE_PT_CALIB) which lead to null pointer dereference (if DEBUG or DYNAMIC_DEBUG set).
 Fix this bug by adding null pointer check.

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

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

 drivers/perf: hisi_pcie: Fix out-of-bound access when valid event group

 The perf tool allows users to create event groups through following cmd [1], but the driver does not check whether the array index is out of bounds when writing data to the event_group array. If the number of events in an event_group is greater than HISI_PCIE_MAX_COUNTERS, the memory write overflow of event_group array occurs.

 Add array index check to fix the possible array out of bounds violation, and return directly when write new events are written to array bounds.

 There are 9 different events in an event_group.
 [1] perf stat -e '{pmu/event1/, ... ,pmu/event9/}'

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

 drivers/perf: hisi: hns3: Fix out-of-bound access when valid event group

 The perf tool allows users to create event groups through following cmd [1], but the driver does not check whether the array index is out of bounds when writing data to the event_group array. If the number of events in an event_group is greater than HNS3_PMU_MAX_HW_EVENTS, the memory write overflow of event_group array occurs.

 Add array index check to fix the possible array out of bounds violation, and return directly when write new events are written to array bounds.

 There are 9 different events in an event_group.
 [1] perf stat -e '{pmu/event1/, ... ,pmu/event9/}

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

 drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference

 In cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() is assigned to mhdp_state->current_mode, and there is a dereference of it in drm_mode_set_name(), which will lead to a NULL pointer dereference on failure of drm_mode_duplicate().

 Fix this bug add a check of mhdp_state->current_mode.

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

 media: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binaries

 The allocation failure of mycs->yuv_scaler_binary in load_video_binaries() is followed with a dereference of mycs->yuv_scaler_binary after the following call chain:

 sh_css_pipe_load_binaries() |-> load_video_binaries(mycs->yuv_scaler_binary == NULL) | |-> sh_css_pipe_unload_binaries() |-> unload_video_binaries()

 In unload_video_binaries(), it calls to ia_css_binary_unload with argument &pipe->pipe_settings.video.yuv_scaler_binary[i], which refers to the same memory slot as mycs->yuv_scaler_binary. Thus, a null-pointer dereference is triggered.

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

 drm: vc4: Fix possible null pointer dereference

 In vc4_hdmi_audio_init() of_get_address() may return NULL which is later dereferenced. Fix this bug by adding NULL check.

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

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

 ALSA: hda/cs_dsp_ctl: Use private_free for control cleanup

 Use the control private_free callback to free the associated data block. This ensures that the memory won't leak, whatever way the control gets destroyed.

 The original implementation didn't actually remove the ALSA controls in hda_cs_dsp_control_remove(). It only freed the internal tracking structure. This meant it was possible to remove/unload the amp driver while leaving its ALSA controls still present in the soundcard. Obviously attempting to access them could cause segfaults or at least dereferencing stale pointers.

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

 efi/unaccepted: touch soft lockup during memory accept

 Commit 50e782a86c98 (efi/unaccepted: Fix soft lockups caused by parallel memory acceptance) has released the spinlock so other CPUs can do memory acceptance in parallel and not triggers softlockup on other CPUs.

 However the softlock up was intermittent shown up if the memory of the TD guest is large, and the timeout of softlockup is set to 1 second:

 RIP: 0010:_raw_spin_unlock_irqrestore Call Trace:
 ? __hrtimer_run_queues <IRQ> ? hrtimer_interrupt ? watchdog_timer_fn ? __sysvec_apic_timer_interrupt ? __pfx_watchdog_timer_fn ? sysvec_apic_timer_interrupt </IRQ> ? __hrtimer_run_queues <TASK> ? hrtimer_interrupt ? asm_sysvec_apic_timer_interrupt ? _raw_spin_unlock_irqrestore ? __sysvec_apic_timer_interrupt ? sysvec_apic_timer_interrupt accept_memory try_to_accept_memory do_huge_pmd_anonymous_page get_page_from_freelist
 __handle_mm_fault
 __alloc_pages
 __folio_alloc ? __tdx_hypercall handle_mm_fault vma_alloc_folio do_user_addr_fault do_huge_pmd_anonymous_page exc_page_fault ? __do_huge_pmd_anonymous_page asm_exc_page_fault
 __handle_mm_fault

 When the local irq is enabled at the end of accept_memory(), the softlockup detects that the watchdog on single CPU has not been fed for a while. That is to say, even other CPUs will not be blocked by spinlock, the current CPU might be stunk with local irq disabled for a while, which hurts not only nmi watchdog but also softlockup.

 Chao Gao pointed out that the memory accept could be time costly and there was similar report before. Thus to avoid any softlocup detection during this stage, give the softlockup a flag to skip the timeout check at the end of accept_memory(), by invoking touch_softlockup_watchdog().

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

 spi: fix null pointer dereference within spi_sync

 If spi_sync() is called with the non-empty queue and the same spi_message is then reused, the complete callback for the message remains set while the context is cleared, leading to a null pointer dereference when the callback is invoked from spi_finalize_current_message().

 With function inlining disabled, the call stack might look like this:

 _raw_spin_lock_irqsave from complete_with_flags+0x18/0x58 complete_with_flags from spi_complete+0x8/0xc spi_complete from spi_finalize_current_message+0xec/0x184 spi_finalize_current_message from spi_transfer_one_message+0x2a8/0x474 spi_transfer_one_message from __spi_pump_transfer_message+0x104/0x230
 __spi_pump_transfer_message from __spi_transfer_message_noqueue+0x30/0xc4
 __spi_transfer_message_noqueue from __spi_sync+0x204/0x248
 __spi_sync from spi_sync+0x24/0x3c spi_sync from mcp251xfd_regmap_crc_read+0x124/0x28c [mcp251xfd] mcp251xfd_regmap_crc_read [mcp251xfd] from _regmap_raw_read+0xf8/0x154
 _regmap_raw_read from _regmap_bus_read+0x44/0x70
 _regmap_bus_read from _regmap_read+0x60/0xd8
 _regmap_read from regmap_read+0x3c/0x5c regmap_read from mcp251xfd_alloc_can_err_skb+0x1c/0x54 [mcp251xfd] mcp251xfd_alloc_can_err_skb [mcp251xfd] from mcp251xfd_irq+0x194/0xe70 [mcp251xfd] mcp251xfd_irq [mcp251xfd] from irq_thread_fn+0x1c/0x78 irq_thread_fn from irq_thread+0x118/0x1f4 irq_thread from kthread+0xd8/0xf4 kthread from ret_from_fork+0x14/0x28

 Fix this by also setting message->complete to NULL when the transfer is complete.

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

 scsi: lpfc: Release hbalock before calling lpfc_worker_wake_up()

 lpfc_worker_wake_up() calls the lpfc_work_done() routine, which takes the hbalock. Thus, lpfc_worker_wake_up() should not be called while holding the hbalock to avoid potential deadlock.

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

 scsi: mpi3mr: Avoid memcpy field-spanning write WARNING

 When the storcli2 show command is executed for eHBA-9600, mpi3mr driver prints this WARNING message:

 memcpy: detected field-spanning write (size 128) of single field bsg_reply_buf->reply_buf at drivers/scsi/mpi3mr/mpi3mr_app.c:1658 (size 1) WARNING: CPU: 0 PID: 12760 at drivers/scsi/mpi3mr/mpi3mr_app.c:1658 mpi3mr_bsg_request+0x6b12/0x7f10 [mpi3mr]

 The cause of the WARN is 128 bytes memcpy to the 1 byte size array __u8 replay_buf[1] in the struct mpi3mr_bsg_in_reply_buf. The array is intended to be a flexible length array, so the WARN is a false positive.

 To suppress the WARN, remove the constant number '1' from the array declaration and clarify that it has flexible length. Also, adjust the memory allocation size to match the change.

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

 drm/amd/display: Skip on writeback when it's not applicable

 [WHY] dynamic memory safety error detector (KASAN) catches and generates error messages BUG: KASAN: slab-out-of-bounds as writeback connector does not support certain features which are not initialized.

 [HOW] Skip them when connector type is DRM_MODE_CONNECTOR_WRITEBACK.

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

 Drivers: hv: vmbus: Leak pages if set_memory_encrypted() fails

 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.

 VMBus code could free decrypted pages if set_memory_encrypted()/decrypted() fails. Leak the pages if this happens.

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

 Drivers: hv: vmbus: Track decrypted status in vmbus_gpadl

 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.

 In order to make sure callers of vmbus_establish_gpadl() and vmbus_teardown_gpadl() don't return decrypted/shared pages to allocators, add a field in struct vmbus_gpadl to keep track of the decryption status of the buffers. This will allow the callers to know if they should free or leak the pages.

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

 mm/slab: make __free(kfree) accept error pointers

 Currently, if an automatically freed allocation is an error pointer that will lead to a crash. An example of this is in wm831x_gpio_dbg_show().

 171 char *label __free(kfree) = gpiochip_dup_line_label(chip, i);
 172 if (IS_ERR(label)) { 173 dev_err(wm831x->dev, Failed to duplicate label\n);
 174 continue;
 175 }

 The auto clean up function should check for error pointers as well, otherwise we're going to keep hitting issues like this.

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

 drm/nouveau/firmware: Fix SG_DEBUG error with nvkm_firmware_ctor()

 Currently, enabling SG_DEBUG in the kernel will cause nouveau to hit a BUG() on startup:

 kernel BUG at include/linux/scatterlist.h:187! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 7 PID: 930 Comm: (udev-worker) Not tainted 6.9.0-rc3Lyude-Test+ #30 Hardware name: MSI MS-7A39/A320M GAMING PRO (MS-7A39), BIOS 1.I0 01/22/2019 RIP: 0010:sg_init_one+0x85/0xa0 Code: 69 88 32 01 83 e1 03 f6 c3 03 75 20 a8 01 75 1e 48 09 cb 41 89 54 24 08 49 89 1c 24 41 89 6c 24 0c 5b 5d 41 5c e9 7b b9 88 00 <0f> 0b 0f 0b 0f 0b 48 8b 05 5e 46 9a 01 eb b2 66 66 2e 0f 1f 84 00 RSP: 0018:ffffa776017bf6a0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa77600d87000 RCX: 000000000000002b RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffffa77680d87000 RBP: 000000000000e000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff98f4c46aa508 R11: 0000000000000000 R12: ffff98f4c46aa508 R13: ffff98f4c46aa008 R14: ffffa77600d4a000 R15: ffffa77600d4a018 FS: 00007feeb5aae980(0000) GS:ffff98f5c4dc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f22cb9a4520 CR3: 00000001043ba000 CR4: 00000000003506f0 Call Trace:
 <TASK> ? die+0x36/0x90 ? do_trap+0xdd/0x100 ? sg_init_one+0x85/0xa0 ? do_error_trap+0x65/0x80 ? sg_init_one+0x85/0xa0 ? exc_invalid_op+0x50/0x70 ? sg_init_one+0x85/0xa0 ? asm_exc_invalid_op+0x1a/0x20 ? sg_init_one+0x85/0xa0 nvkm_firmware_ctor+0x14a/0x250 [nouveau] nvkm_falcon_fw_ctor+0x42/0x70 [nouveau] ga102_gsp_booter_ctor+0xb4/0x1a0 [nouveau] r535_gsp_oneinit+0xb3/0x15f0 [nouveau] ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? nvkm_udevice_new+0x95/0x140 [nouveau] ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? ktime_get+0x47/0xb0 ? srso_return_thunk+0x5/0x5f nvkm_subdev_oneinit_+0x4f/0x120 [nouveau] nvkm_subdev_init_+0x39/0x140 [nouveau] ? srso_return_thunk+0x5/0x5f nvkm_subdev_init+0x44/0x90 [nouveau] nvkm_device_init+0x166/0x2e0 [nouveau] nvkm_udevice_init+0x47/0x70 [nouveau] nvkm_object_init+0x41/0x1c0 [nouveau] nvkm_ioctl_new+0x16a/0x290 [nouveau] ? __pfx_nvkm_client_child_new+0x10/0x10 [nouveau] ? __pfx_nvkm_udevice_new+0x10/0x10 [nouveau] nvkm_ioctl+0x126/0x290 [nouveau] nvif_object_ctor+0x112/0x190 [nouveau] nvif_device_ctor+0x23/0x60 [nouveau] nouveau_cli_init+0x164/0x640 [nouveau] nouveau_drm_device_init+0x97/0x9e0 [nouveau] ? srso_return_thunk+0x5/0x5f ? pci_update_current_state+0x72/0xb0 ? srso_return_thunk+0x5/0x5f nouveau_drm_probe+0x12c/0x280 [nouveau] ? srso_return_thunk+0x5/0x5f local_pci_probe+0x45/0xa0 pci_device_probe+0xc7/0x270 really_probe+0xe6/0x3a0
 __driver_probe_device+0x87/0x160 driver_probe_device+0x1f/0xc0
 __driver_attach+0xec/0x1f0 ? __pfx___driver_attach+0x10/0x10 bus_for_each_dev+0x88/0xd0 bus_add_driver+0x116/0x220 driver_register+0x59/0x100 ? __pfx_nouveau_drm_init+0x10/0x10 [nouveau] do_one_initcall+0x5b/0x320 do_init_module+0x60/0x250 init_module_from_file+0x86/0xc0 idempotent_init_module+0x120/0x2b0
 __x64_sys_finit_module+0x5e/0xb0 do_syscall_64+0x83/0x160 ? srso_return_thunk+0x5/0x5f entry_SYSCALL_64_after_hwframe+0x71/0x79 RIP: 0033:0x7feeb5cc20cd Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1b cd 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffcf220b2c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 000055fdd2916aa0 RCX: 00007feeb5cc20cd RDX: 0000000000000000 RSI: 000055fdd29161e0 RDI: 0000000000000035 RBP: 00007ffcf220b380 R08: 00007feeb5d8fb20 R09: 00007ffcf220b310 R10: 000055fdd2909dc0 R11: 0000000000000246 R12: 000055
 ---truncated---

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

 mm: use memalloc_nofs_save() in page_cache_ra_order()

 See commit f2c817bed58d (mm: use memalloc_nofs_save in readahead path), ensure that page_cache_ra_order() do not attempt to reclaim file-backed pages too, or it leads to a deadlock, found issue when test ext4 large folio.

 INFO: task DataXceiver for:7494 blocked for more than 120 seconds.
 echo 0 > /proc/sys/kernel/hung_task_timeout_secs disables this message.
 task:DataXceiver for state:D stack:0 pid:7494 ppid:1 flags:0x00000200 Call trace:
 __switch_to+0x14c/0x240
 __schedule+0x82c/0xdd0 schedule+0x58/0xf0 io_schedule+0x24/0xa0
 __folio_lock+0x130/0x300 migrate_pages_batch+0x378/0x918 migrate_pages+0x350/0x700 compact_zone+0x63c/0xb38 compact_zone_order+0xc0/0x118 try_to_compact_pages+0xb0/0x280
 __alloc_pages_direct_compact+0x98/0x248
 __alloc_pages+0x510/0x1110 alloc_pages+0x9c/0x130 folio_alloc+0x20/0x78 filemap_alloc_folio+0x8c/0x1b0 page_cache_ra_order+0x174/0x308 ondemand_readahead+0x1c8/0x2b8 page_cache_async_ra+0x68/0xb8 filemap_readahead.isra.0+0x64/0xa8 filemap_get_pages+0x3fc/0x5b0 filemap_splice_read+0xf4/0x280 ext4_file_splice_read+0x2c/0x48 [ext4] vfs_splice_read.part.0+0xa8/0x118 splice_direct_to_actor+0xbc/0x288 do_splice_direct+0x9c/0x108 do_sendfile+0x328/0x468
 __arm64_sys_sendfile64+0x8c/0x148 invoke_syscall+0x4c/0x118 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x4c/0x1f8 el0t_64_sync_handler+0xc0/0xc8 el0t_64_sync+0x188/0x190

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

 tls: fix missing memory barrier in tls_init

 In tls_init(), a write memory barrier is missing, and store-store reordering may cause NULL dereference in tls_{setsockopt,getsockopt}.

 CPU0 CPU1
 ----- ----- // In tls_init() // In tls_ctx_create() ctx = kzalloc() ctx->sk_proto = READ_ONCE(sk->sk_prot) -(1)

 // In update_sk_prot() WRITE_ONCE(sk->sk_prot, tls_prots) -(2)

 // In sock_common_setsockopt() READ_ONCE(sk->sk_prot)->setsockopt()

 // In tls_{setsockopt,getsockopt}() ctx->sk_proto->setsockopt() -(3)

 In the above scenario, when (1) and (2) are reordered, (3) can observe the NULL value of ctx->sk_proto, causing NULL dereference.

 To fix it, we rely on rcu_assign_pointer() which implies the release barrier semantic. By moving rcu_assign_pointer() after ctx->sk_proto is initialized, we can ensure that ctx->sk_proto are visible when changing sk->sk_prot.

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

 net: relax socket state check at accept time.

 Christoph reported the following splat:

 WARNING: CPU: 1 PID: 772 at net/ipv4/af_inet.c:761 __inet_accept+0x1f4/0x4a0 Modules linked in:
 CPU: 1 PID: 772 Comm: syz-executor510 Not tainted 6.9.0-rc7-g7da7119fe22b #56 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 RIP: 0010:__inet_accept+0x1f4/0x4a0 net/ipv4/af_inet.c:759 Code: 04 38 84 c0 0f 85 87 00 00 00 41 c7 04 24 03 00 00 00 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ec b7 da fd <0f> 0b e9 7f fe ff ff e8 e0 b7 da fd 0f 0b e9 fe fe ff ff 89 d9 80 RSP: 0018:ffffc90000c2fc58 EFLAGS: 00010293 RAX: ffffffff836bdd14 RBX: 0000000000000000 RCX: ffff888104668000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: dffffc0000000000 R08: ffffffff836bdb89 R09: fffff52000185f64 R10: dffffc0000000000 R11: fffff52000185f64 R12: dffffc0000000000 R13: 1ffff92000185f98 R14: ffff88810754d880 R15: ffff8881007b7800 FS: 000000001c772880(0000) GS:ffff88811b280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb9fcf2e178 CR3: 00000001045d2002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace:
 <TASK> inet_accept+0x138/0x1d0 net/ipv4/af_inet.c:786 do_accept+0x435/0x620 net/socket.c:1929
 __sys_accept4_file net/socket.c:1969 [inline]
 __sys_accept4+0x9b/0x110 net/socket.c:1999
 __do_sys_accept net/socket.c:2016 [inline]
 __se_sys_accept net/socket.c:2013 [inline]
 __x64_sys_accept+0x7d/0x90 net/socket.c:2013 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x58/0x100 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x4315f9 Code: fd ff 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 ab b4 fd ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007ffdb26d9c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002b RAX: ffffffffffffffda RBX: 0000000000400300 RCX: 00000000004315f9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004 RBP: 00000000006e1018 R08: 0000000000400300 R09: 0000000000400300 R10: 0000000000400300 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000040cdf0 R14: 000000000040ce80 R15: 0000000000000055 </TASK>

 The reproducer invokes shutdown() before entering the listener status.
 After commit 94062790aedb (tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets), the above causes the child to reach the accept syscall in FIN_WAIT1 status.

 Eric noted we can relax the existing assertion in __inet_accept()

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

 netfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu()

 syzbot reported that nf_reinject() could be called without rcu_read_lock() :

 WARNING: suspicious RCU usage 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not tainted

 net/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage!

 other info that might help us debug this:

 rcu_scheduler_active = 2, debug_locks = 1 2 locks held by syz-executor.4/13427:
 #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline] #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline] #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471 #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172

 stack backtrace:
 CPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Call Trace:
 <IRQ>
 __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712 nf_reinject net/netfilter/nfnetlink_queue.c:323 [inline] nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397 nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline] instance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172 rcu_do_batch kernel/rcu/tree.c:2196 [inline] rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471 handle_softirqs+0x2d6/0x990 kernel/softirq.c:554
 __do_softirq kernel/softirq.c:588 [inline] invoke_softirq kernel/softirq.c:428 [inline]
 __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637 irq_exit_rcu+0x9/0x30 kernel/softirq.c:649 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043 </IRQ> <TASK>

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

 net/mlx5: Use mlx5_ipsec_rx_status_destroy to correctly delete status rules

 rx_create no longer allocates a modify_hdr instance that needs to be cleaned up. The mlx5_modify_header_dealloc call will lead to a NULL pointer dereference. A leak in the rules also previously occurred since there are now two rules populated related to status.

 BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 109907067 P4D 109907067 PUD 116890067 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 484 Comm: ip Not tainted 6.9.0-rc2-rrameshbabu+ #254 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Arch Linux 1.16.3-1-1 04/01/2014 RIP: 0010:mlx5_modify_header_dealloc+0xd/0x70 <snip> Call Trace:
 <TASK> ? show_regs+0x60/0x70 ? __die+0x24/0x70 ? page_fault_oops+0x15f/0x430 ? free_to_partial_list.constprop.0+0x79/0x150 ? do_user_addr_fault+0x2c9/0x5c0 ? exc_page_fault+0x63/0x110 ? asm_exc_page_fault+0x27/0x30 ? mlx5_modify_header_dealloc+0xd/0x70 rx_create+0x374/0x590 rx_add_rule+0x3ad/0x500 ? rx_add_rule+0x3ad/0x500 ? mlx5_cmd_exec+0x2c/0x40 ? mlx5_create_ipsec_obj+0xd6/0x200 mlx5e_accel_ipsec_fs_add_rule+0x31/0xf0 mlx5e_xfrm_add_state+0x426/0xc00 <snip>

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

 netfilter: tproxy: bail out if IP has been disabled on the device

 syzbot reports:
 general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] [..] RIP: 0010:nf_tproxy_laddr4+0xb7/0x340 net/ipv4/netfilter/nf_tproxy_ipv4.c:62 Call Trace:
 nft_tproxy_eval_v4 net/netfilter/nft_tproxy.c:56 [inline] nft_tproxy_eval+0xa9a/0x1a00 net/netfilter/nft_tpro ...

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

Plugin Details

Severity: High

ID: 239342

File Name: tencentos_TSSA_2024_0981.nasl

Version: 1.3

Type: local

Published: 6/16/2025

Updated: 12/4/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-2020-14381

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

Vulnerability Information

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

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: 1/17/2025

Vulnerability Publication Date: 1/17/2025

Reference Information

CVE: CVE-2020-14381, CVE-2020-35513, CVE-2020-36322, CVE-2021-3428, CVE-2021-3635, CVE-2021-38205, CVE-2021-38207, CVE-2021-38208, CVE-2021-3923, CVE-2021-47069, CVE-2021-47076, CVE-2021-47091, CVE-2021-47103, CVE-2021-47194, CVE-2021-47201, CVE-2021-47207, CVE-2021-47211, CVE-2021-47212, CVE-2021-47217, CVE-2021-47226, CVE-2021-47227, CVE-2021-47228, CVE-2021-47230, CVE-2021-47254, CVE-2021-47255, CVE-2021-47259, CVE-2021-47260, CVE-2021-47262, CVE-2021-47264, CVE-2021-47281, CVE-2021-47292, CVE-2021-47301, CVE-2021-47306, CVE-2021-47310, CVE-2021-47311, CVE-2021-47316, CVE-2021-47320, CVE-2021-47322, CVE-2021-47332, CVE-2021-47335, CVE-2021-47339, CVE-2021-47340, CVE-2021-47351, CVE-2021-47353, CVE-2021-47359, CVE-2021-47365, CVE-2021-47366, CVE-2021-47389, CVE-2021-47390, CVE-2021-47406, CVE-2021-47407, CVE-2021-47430, CVE-2021-47432, CVE-2021-47439, CVE-2021-47442, CVE-2021-47443, CVE-2021-47448, CVE-2021-47467, CVE-2021-47470, CVE-2021-47492, CVE-2021-47502, CVE-2021-47522, CVE-2021-47526, CVE-2021-47577, CVE-2021-47579, CVE-2021-47585, CVE-2021-47599, CVE-2022-3577, CVE-2022-3903, CVE-2022-48648, CVE-2022-48651, CVE-2022-48652, CVE-2022-48653, CVE-2022-48654, CVE-2022-48657, CVE-2022-48673, CVE-2022-48687, CVE-2022-48702, CVE-2022-48712, CVE-2022-48731, CVE-2022-48751, CVE-2022-48754, CVE-2022-48757, CVE-2022-48763, CVE-2022-48765, CVE-2022-48855, CVE-2022-48856, CVE-2022-48860, CVE-2022-48865, CVE-2023-52463, CVE-2023-52530, CVE-2023-52585, CVE-2023-52616, CVE-2023-52638, CVE-2023-52642, CVE-2023-52648, CVE-2023-52649, CVE-2023-52652, CVE-2023-52657, CVE-2023-52659, CVE-2023-52660, CVE-2023-52661, CVE-2023-52662, CVE-2023-52670, CVE-2023-52671, CVE-2023-52672, CVE-2023-52678, CVE-2023-52681, CVE-2023-52683, CVE-2023-52687, CVE-2023-52691, CVE-2023-52693, CVE-2023-52694, CVE-2023-52697, CVE-2023-52699, CVE-2023-52748, CVE-2023-52751, CVE-2023-52752, CVE-2023-52755, CVE-2023-52757, CVE-2023-52760, CVE-2023-52784, CVE-2023-52791, CVE-2023-52792, CVE-2023-52795, CVE-2023-52799, CVE-2023-52805, CVE-2023-52806, CVE-2023-52821, CVE-2023-52825, CVE-2023-52826, CVE-2023-52833, CVE-2023-52837, CVE-2023-52838, CVE-2023-52839, CVE-2023-52840, CVE-2023-52841, CVE-2023-52844, CVE-2023-52847, CVE-2023-52848, CVE-2023-52849, CVE-2023-52850, CVE-2023-52851, CVE-2023-52853, CVE-2023-52855, CVE-2023-52856, CVE-2023-52857, CVE-2023-52859, CVE-2023-52860, CVE-2023-52861, CVE-2023-52862, CVE-2023-52863, CVE-2023-52866, CVE-2023-52870, CVE-2023-52871, CVE-2023-52872, CVE-2023-52881, CVE-2024-25742, CVE-2024-26592, CVE-2024-26634, CVE-2024-26679, CVE-2024-26680, CVE-2024-26681, CVE-2024-26690, CVE-2024-26691, CVE-2024-26693, CVE-2024-26694, CVE-2024-26698, CVE-2024-26705, CVE-2024-26707, CVE-2024-26708, CVE-2024-26722, CVE-2024-26723, CVE-2024-26731, CVE-2024-26733, CVE-2024-26734, CVE-2024-26789, CVE-2024-26795, CVE-2024-26799, CVE-2024-26810, CVE-2024-26812, CVE-2024-26814, CVE-2024-26816, CVE-2024-26818, CVE-2024-26823, CVE-2024-26829, CVE-2024-26833, CVE-2024-26838, CVE-2024-26839, CVE-2024-26841, CVE-2024-26842, CVE-2024-26849, CVE-2024-26881, CVE-2024-26882, CVE-2024-26886, CVE-2024-26888, CVE-2024-26889, CVE-2024-26892, CVE-2024-26906, CVE-2024-26930, CVE-2024-26931, CVE-2024-26933, CVE-2024-26934, CVE-2024-26935, CVE-2024-26936, CVE-2024-26937, CVE-2024-26938, CVE-2024-26943, CVE-2024-26946, CVE-2024-26953, CVE-2024-26959, CVE-2024-26962, CVE-2024-26963, CVE-2024-26964, CVE-2024-26966, CVE-2024-26968, CVE-2024-26969, CVE-2024-26970, CVE-2024-26971, CVE-2024-26974, CVE-2024-26975, CVE-2024-26976, CVE-2024-26978, CVE-2024-26984, CVE-2024-26986, CVE-2024-26988, CVE-2024-26990, CVE-2024-26992, CVE-2024-26994, CVE-2024-26997, CVE-2024-26998, CVE-2024-26999, CVE-2024-27000, CVE-2024-27020, CVE-2024-27024, CVE-2024-27026, CVE-2024-27030, CVE-2024-27046, CVE-2024-27047, CVE-2024-27048, CVE-2024-27050, CVE-2024-27061, CVE-2024-27393, CVE-2024-27395, CVE-2024-27400, CVE-2024-27402, CVE-2024-27403, CVE-2024-27404, CVE-2024-27406, CVE-2024-27407, CVE-2024-27408, CVE-2024-27409, CVE-2024-27412, CVE-2024-27413, CVE-2024-27414, CVE-2024-27415, CVE-2024-27417, CVE-2024-27433, CVE-2024-27435, CVE-2024-33621, CVE-2024-35785, CVE-2024-35786, CVE-2024-35787, CVE-2024-35790, CVE-2024-35791, CVE-2024-35792, CVE-2024-35801, CVE-2024-35803, CVE-2024-35804, CVE-2024-35818, CVE-2024-35842, CVE-2024-35871, CVE-2024-35872, CVE-2024-35875, CVE-2024-35903, CVE-2024-35917, CVE-2024-35947, CVE-2024-35972, CVE-2024-35980, CVE-2024-35981, CVE-2024-35987, CVE-2024-35988, CVE-2024-35996, CVE-2024-36017, CVE-2024-36020, CVE-2024-36021, CVE-2024-36028, CVE-2024-36030, CVE-2024-36031, CVE-2024-36033, CVE-2024-36270, CVE-2024-36281, CVE-2024-36286, CVE-2024-36484, CVE-2024-36489, CVE-2024-36882, CVE-2024-36890, CVE-2024-36912, CVE-2024-36913, CVE-2024-36914, CVE-2024-36920, CVE-2024-36924, CVE-2024-36930, CVE-2024-36936, CVE-2024-38388, CVE-2024-38546, CVE-2024-38547, CVE-2024-38548, CVE-2024-38568, CVE-2024-38569, CVE-2024-38571, CVE-2024-39496