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

high Nessus Plugin ID 276342

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

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

CVE-2020-36775:
In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to avoid potential deadlock

Using f2fs_trylock_op() in f2fs_write_compressed_pages() to avoid potential deadlock like we did in f2fs_write_single_data_page().

CVE-2021-3493:
The overlayfs implementation in the linux kernel did not properly validate with respect to user namespaces the setting of file capabilities on files in an underlying file system. Due to the combination of unprivileged user namespaces along with a patch carried in the Ubuntu kernel to allow unprivileged overlay mounts, an attacker could use this to gain elevated privileges.

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

usb: gadget: f_fs: Clear ffs_eventfd in ffs_data_clear.

ffs_data_clear is indirectly called from both ffs_fs_kill_sb and ffs_ep0_release, so it ends up being called twice when userland closes ep0 and then unmounts f_fs.
If userland provided an eventfd along with function's USB descriptors, it ends up calling eventfd_ctx_put as many times, causing a refcount underflow.
NULL-ify ffs_eventfd to prevent these extraneous eventfd_ctx_put calls.

Also, set epfiles to NULL right after de-allocating it, for readability.

For completeness, ffs_data_clear actually ends up being called thrice, the last call being before the whole ffs structure gets freed, so when this specific sequence happens there is a second underflow happening (but not being reported):

/sys/kernel/debug/tracing# modprobe usb_f_fs /sys/kernel/debug/tracing# echo ffs_data_clear > set_ftrace_filter /sys/kernel/debug/tracing# echo function > current_tracer /sys/kernel/debug/tracing# echo 1 > tracing_on (setup gadget, run and kill function userland process, teardown gadget) /sys/kernel/debug/tracing# echo 0 > tracing_on /sys/kernel/debug/tracing# cat trace smartcard-openp-436 [000] ..... 1946.208786: ffs_data_clear <-ffs_data_closed smartcard-openp-431 [000] ..... 1946.279147: ffs_data_clear <-ffs_data_closed smartcard-openp-431 [000] .n... 1946.905512: ffs_data_clear <-ffs_data_put

Warning output corresponding to above trace:
[ 1946.284139] WARNING: CPU: 0 PID: 431 at lib/refcount.c:28 refcount_warn_saturate+0x110/0x15c [ 1946.293094] refcount_t: underflow; use-after-free.
[ 1946.298164] Modules linked in: usb_f_ncm(E) u_ether(E) usb_f_fs(E) hci_uart(E) btqca(E) btrtl(E) btbcm(E) btintel(E) bluetooth(E) nls_ascii(E) nls_cp437(E) vfat(E) fat(E) bcm2835_v4l2(CE) bcm2835_mmal_vchiq(CE) videobuf2_vmalloc(E) videobuf2_memops(E) sha512_generic(E) videobuf2_v4l2(E) sha512_arm(E) videobuf2_common(E) videodev(E) cpufreq_dt(E) snd_bcm2835(CE) brcmfmac(E) mc(E) vc4(E) ctr(E) brcmutil(E) snd_soc_core(E) snd_pcm_dmaengine(E) drbg(E) snd_pcm(E) snd_timer(E) snd(E) soundcore(E) drm_kms_helper(E) cec(E) ansi_cprng(E) rc_core(E) syscopyarea(E) raspberrypi_cpufreq(E) sysfillrect(E) sysimgblt(E) cfg80211(E) max17040_battery(OE) raspberrypi_hwmon(E) fb_sys_fops(E) regmap_i2c(E) ecdh_generic(E) rfkill(E) ecc(E) bcm2835_rng(E) rng_core(E) vchiq(CE) leds_gpio(E) libcomposite(E) fuse(E) configfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) sdhci_iproc(E) sdhci_pltfm(E) sdhci(E) [ 1946.399633] CPU: 0 PID: 431 Comm: smartcard-openp Tainted: G C OE 5.15.0-1-rpi #1 Debian 5.15.3-1 [ 1946.417950] Hardware name: BCM2835 [ 1946.425442] Backtrace:
[ 1946.432048] [<c08d60a0>] (dump_backtrace) from [<c08d62ec>] (show_stack+0x20/0x24) [ 1946.448226] r7:00000009 r6:0000001c r5:c04a948c r4:c0a64e2c [ 1946.458412] [<c08d62cc>] (show_stack) from [<c08d9ae0>] (dump_stack+0x28/0x30) [ 1946.470380] [<c08d9ab8>] (dump_stack) from [<c0123500>] (__warn+0xe8/0x154) [ 1946.482067] r5:c04a948c r4:c0a71dc8 [ 1946.490184] [<c0123418>] (__warn) from [<c08d6948>] (warn_slowpath_fmt+0xa0/0xe4) [ 1946.506758] r7:00000009 r6:0000001c r5:c0a71dc8 r4:c0a71e04 [ 1946.517070] [<c08d68ac>] (warn_slowpath_fmt) from [<c04a948c>] (refcount_warn_saturate+0x110/0x15c) [ 1946.535309] r8:c0100224 r7:c0dfcb84 r6:ffffffff r5:c3b84c00 r4:c24a17c0 [ 1946.546708] [<c04a937c>] (refcount_warn_saturate) from [<c0380134>] (eventfd_ctx_put+0x48/0x74) [ 1946.564476] [<c03800ec>] (eventfd_ctx_put) from [<bf5464e8>] (ffs_data_clear+0xd0/0x118 [usb_f_fs]) [ 1946.582664] r5:c3b84c00 r4:c2695b00 [ 1946.590668] [<bf546418>] (ffs_data_clear [usb_f_fs]) from [<bf547cc0>] (ffs_data_closed+0x9c/0x150 [usb_f_fs]) [ 1946.609608] r5:bf54d014 r4:c2695b00 [ 1946.617522] [<bf547c24>] (ffs_data_closed [usb_f_fs]) from [<bf547da0>] (ffs_fs_kill_sb+0x2c/0x30 [usb_f_fs]) [ 1946.636217] r7:c0dfcb
---truncated---

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

hfsplus: prevent corruption in shrinking truncate

I believe there are some issues introduced by commit 31651c607151 (hfsplus: avoid deadlock on file truncation)

HFS+ has extent records which always contains 8 extents. In case the first extent record in catalog file gets full, new ones are allocated from extents overflow file.

In case shrinking truncate happens to middle of an extent record which locates in extents overflow file, the logic in hfsplus_file_truncate() was changed so that call to hfs_brec_remove() is not guarded any more.

Right action would be just freeing the extents that exceed the new size inside extent record by calling hfsplus_free_extents(), and then check if the whole extent record should be removed. However since the guard (blk_cnt > start) is now after the call to hfs_brec_remove(), this has unfortunate effect that the last matching extent record is removed unconditionally.

To reproduce this issue, create a file which has at least 10 extents, and then perform shrinking truncate into middle of the last extent record, so that the number of remaining extents is not under or divisible by 8. This causes the last extent record (8 extents) to be removed totally instead of truncating into middle of it. Thus this causes corruption, and lost data.

Fix for this is simply checking if the new truncated end is below the start of this extent record, making it safe to remove the full extent record. However call to hfs_brec_remove() can't be moved to it's previous place since we're dropping ->tree_lock and it can cause a race condition and the cached info being invalidated possibly corrupting the node data.

Another issue is related to this one. When entering into the block (blk_cnt > start) we are not holding the ->tree_lock. We break out from the loop not holding the lock, but hfs_find_exit() does unlock it. Not sure if it's possible for someone else to take the lock under our feet, but it can cause hard to debug errors and premature unlocking. Even if there's no real risk of it, the locking should still always be kept in balance. Thus taking the lock now just before the check.

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

ceph: fix inode leak on getattr error in __fh_to_dentry

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

Drivers: hv: vmbus: Use after free in __vmbus_open()

The open_info variable is added to the &vmbus_connection.chn_msg_list, but the error handling frees open_info without removing it from the list. This will result in a use after free. First remove it from the list, and then free it.

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

uio_hv_generic: Fix another memory leak in error handling paths

Memory allocated by 'vmbus_alloc_ring()' at the beginning of the probe function is never freed in the error handling path.

Add the missing 'vmbus_free_ring()' call.

Note that it is already freed in the .remove function.

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

nvme-loop: fix memory leak in nvme_loop_create_ctrl()

When creating loop ctrl in nvme_loop_create_ctrl(), if nvme_init_ctrl() fails, the loop ctrl should be freed before jumping to the out label.

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

tee: optee: Fix incorrect page free bug

Pointer to the allocated pages (struct page *page) has already progressed towards the end of allocation. It is incorrect to perform
__free_pages(page, order) using this pointer as we would free any arbitrary pages. Fix this by stop modifying the page pointer.

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

ipmi: ssif: initialize ssif_info->client early

During probe ssif_info->client is dereferenced in error path. However, it is set when some of the error checking has already been done. This causes following kernel crash if an error path is taken:

[ 30.645593][ T674] ipmi_ssif 0-000e: ipmi_ssif: Not probing, Interface already present [ 30.657616][ T674] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000088 ...
[ 30.657723][ T674] pc : __dev_printk+0x28/0xa0 [ 30.657732][ T674] lr : _dev_err+0x7c/0xa0 ...
[ 30.657772][ T674] Call trace:
[ 30.657775][ T674] __dev_printk+0x28/0xa0 [ 30.657778][ T674] _dev_err+0x7c/0xa0 [ 30.657781][ T674] ssif_probe+0x548/0x900 [ipmi_ssif 62ce4b08badc1458fd896206d9ef69a3c31f3d3e] [ 30.657791][ T674] i2c_device_probe+0x37c/0x3c0 ...

Initialize ssif_info->client before any error path can be taken. Clear i2c_client data in the error path to prevent the dangling pointer from leaking.

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

neighbour: allow NUD_NOARP entries to be forced GCed

IFF_POINTOPOINT interfaces use NUD_NOARP entries for IPv6. It's possible to fill up the neighbour table with enough entries that it will overflow for valid connections after that.

This behaviour is more prevalent after commit 58956317c8de (neighbor:
Improve garbage collection) is applied, as it prevents removal from entries that are not NUD_FAILED, unless they are more than 5s old.

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

drm/amdgpu: Fix a use-after-free

looks like we forget to set ttm->sg to NULL.
Hit panic below

[ 1235.844104] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b7b4b: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI [ 1235.989074] Call Trace:
[ 1235.991751] sg_free_table+0x17/0x20 [ 1235.995667] amdgpu_ttm_backend_unbind.cold+0x4d/0xf7 [amdgpu] [ 1236.002288] amdgpu_ttm_backend_destroy+0x29/0x130 [amdgpu] [ 1236.008464] ttm_tt_destroy+0x1e/0x30 [ttm] [ 1236.013066] ttm_bo_cleanup_memtype_use+0x51/0xa0 [ttm] [ 1236.018783] ttm_bo_release+0x262/0xa50 [ttm] [ 1236.023547] ttm_bo_put+0x82/0xd0 [ttm] [ 1236.027766] amdgpu_bo_unref+0x26/0x50 [amdgpu] [ 1236.032809] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x7aa/0xd90 [amdgpu] [ 1236.040400] kfd_ioctl_alloc_memory_of_gpu+0xe2/0x330 [amdgpu] [ 1236.046912] kfd_ioctl+0x463/0x690 [amdgpu]

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

drm/amd/amdgpu: fix refcount leak

[Why] the gem object rfb->base.obj[0] is get according to num_planes in amdgpufb_create, but is not put according to num_planes

[How] put rfb->base.obj[0] in amdgpu_fbdev_destroy according to num_planes

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

drm/meson: fix shutdown crash when component not probed

When main component is not probed, by example when the dw-hdmi module is not loaded yet or in probe defer, the following crash appears on shutdown:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038 ...
pc : meson_drv_shutdown+0x24/0x50 lr : platform_drv_shutdown+0x20/0x30 ...
Call trace:
meson_drv_shutdown+0x24/0x50 platform_drv_shutdown+0x20/0x30 device_shutdown+0x158/0x360 kernel_restart_prepare+0x38/0x48 kernel_restart+0x18/0x68
__do_sys_reboot+0x224/0x250
__arm64_sys_reboot+0x24/0x30 ...

Simply check if the priv struct has been allocated before using it.

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

NFS: Fix an Oopsable condition in __nfs_pageio_add_request()

Ensure that nfs_pageio_error_cleanup() resets the mirror array contents, so that the structure reflects the fact that it is now empty.
Also change the test in nfs_pageio_do_add_request() to be more robust by checking whether or not the list is empty rather than relying on the value of pg_count.

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

USB: usbfs: Don't WARN about excessively large memory allocations

Syzbot found that the kernel generates a WARNing if the user tries to submit a bulk transfer through usbfs with a buffer that is way too large. This isn't a bug in the kernel; it's merely an invalid request from the user and the usbfs code does handle it correctly.

In theory the same thing can happen with async transfers, or with the packet descriptor table for isochronous transfers.

To prevent the MM subsystem from complaining about these bad allocation requests, add the __GFP_NOWARN flag to the kmalloc calls for these buffers.

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

net: usb: fix memory leak in smsc75xx_bind

Syzbot reported memory leak in smsc75xx_bind().
The problem was is non-freed memory in case of errors after memory allocation.

backtrace:
[<ffffffff84245b62>] kmalloc include/linux/slab.h:556 [inline] [<ffffffff84245b62>] kzalloc include/linux/slab.h:686 [inline] [<ffffffff84245b62>] smsc75xx_bind+0x7a/0x334 drivers/net/usb/smsc75xx.c:1460 [<ffffffff82b5b2e6>] usbnet_probe+0x3b6/0xc30 drivers/net/usb/usbnet.c:1728

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

iommu/vt-d: Fix sysfs leak in alloc_iommu()

iommu_device_sysfs_add() is called before, so is has to be cleaned on subsequent errors.

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

NFSv4: Fix a NULL pointer dereference in pnfs_mark_matching_lsegs_return()

Commit de144ff4234f changes _pnfs_return_layout() to call pnfs_mark_matching_lsegs_return() passing NULL as the struct pnfs_layout_range argument. Unfortunately, pnfs_mark_matching_lsegs_return() doesn't check if we have a value here before dereferencing it, causing an oops.

I'm able to hit this crash consistently when running connectathon basic tests on NFS v4.1/v4.2 against Ontap.

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

scsi: core: Fix scsi_mode_sense() buffer length handling

Several problems exist with scsi_mode_sense() buffer length handling:

1) The allocation length field of the MODE SENSE(10) command is 16-bits, occupying bytes 7 and 8 of the CDB. With this command, access to mode pages larger than 255 bytes is thus possible. However, the CDB allocation length field is set by assigning len to byte 8 only, thus truncating buffer length larger than 255.

2) If scsi_mode_sense() is called with len smaller than 8 with sdev->use_10_for_ms set, or smaller than 4 otherwise, the buffer length is increased to 8 and 4 respectively, and the buffer is zero filled with these increased values, thus corrupting the memory following the buffer.

Fix these 2 problems by using put_unaligned_be16() to set the allocation length field of MODE SENSE(10) CDB and by returning an error when len is too small.

Furthermore, if len is larger than 255B, always try MODE SENSE(10) first, even if the device driver did not set sdev->use_10_for_ms. In case of invalid opcode error for MODE SENSE(10), access to mode pages larger than 255 bytes are not retried using MODE SENSE(6). To avoid buffer length overflows for the MODE_SENSE(10) case, check that len is smaller than 65535 bytes.

While at it, also fix the folowing:

* Use get_unaligned_be16() to retrieve the mode data length and block descriptor length fields of the mode sense reply header instead of using an open coded calculation.

* Fix the kdoc dbd argument explanation: the DBD bit stands for Disable Block Descriptor, which is the opposite of what the dbd argument description was.

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

tty: tty_buffer: Fix the softlockup issue in flush_to_ldisc

When running ltp testcase(ltp/testcases/kernel/pty/pty04.c) with arm64, there is a soft lockup, which look like this one:

Workqueue: events_unbound flush_to_ldisc Call trace:
dump_backtrace+0x0/0x1ec show_stack+0x24/0x30 dump_stack+0xd0/0x128 panic+0x15c/0x374 watchdog_timer_fn+0x2b8/0x304
__run_hrtimer+0x88/0x2c0
__hrtimer_run_queues+0xa4/0x120 hrtimer_interrupt+0xfc/0x270 arch_timer_handler_phys+0x40/0x50 handle_percpu_devid_irq+0x94/0x220
__handle_domain_irq+0x88/0xf0 gic_handle_irq+0x84/0xfc el1_irq+0xc8/0x180 slip_unesc+0x80/0x214 [slip] tty_ldisc_receive_buf+0x64/0x80 tty_port_default_receive_buf+0x50/0x90 flush_to_ldisc+0xbc/0x110 process_one_work+0x1d4/0x4b0 worker_thread+0x180/0x430 kthread+0x11c/0x120

In the testcase pty04, The first process call the write syscall to send data to the pty master. At the same time, the workqueue will do the flush_to_ldisc to pop data in a loop until there is no more data left.
When the sender and workqueue running in different core, the sender sends data fastly in full time which will result in workqueue doing work in loop for a long time and occuring softlockup in flush_to_ldisc with kernel configured without preempt. So I add need_resched check and cond_resched in the flush_to_ldisc loop to avoid it.

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

thermal: Fix NULL pointer dereferences in of_thermal_ functions

of_parse_thermal_zones() parses the thermal-zones node and registers a thermal_zone device for each subnode. However, if a thermal zone is consuming a thermal sensor and that thermal sensor device hasn't probed yet, an attempt to set trip_point_*_temp for that thermal zone device can cause a NULL pointer dereference. Fix it.

console:/sys/class/thermal/thermal_zone87 # echo 120000 > trip_point_0_temp ...
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ...
Call trace:
of_thermal_set_trip_temp+0x40/0xc4 trip_point_temp_store+0xc0/0x1dc dev_attr_store+0x38/0x88 sysfs_kf_write+0x64/0xc0 kernfs_fop_write_iter+0x108/0x1d0 vfs_write+0x2f4/0x368 ksys_write+0x7c/0xec
__arm64_sys_write+0x20/0x30 el0_svc_common.llvm.7279915941325364641+0xbc/0x1bc do_el0_svc+0x28/0xa0 el0_svc+0x14/0x24 el0_sync_handler+0x88/0xec el0_sync+0x1c0/0x200

While at it, fix the possible NULL pointer dereference in other functions as well: of_thermal_get_temp(), of_thermal_set_emul_temp(), of_thermal_get_trend().

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

scsi: lpfc: Fix list_add() corruption in lpfc_drain_txq()

When parsing the txq list in lpfc_drain_txq(), the driver attempts to pass the requests to the adapter. If such an attempt fails, a local fail_msg string is set and a log message output. The job is then added to a completions list for cancellation.

Processing of any further jobs from the txq list continues, but since fail_msg remains set, jobs are added to the completions list regardless of whether a wqe was passed to the adapter. If successfully added to txcmplq, jobs are added to both lists resulting in list corruption.

Fix by clearing the fail_msg string after adding a job to the completions list. This stops the subsequent jobs from being added to the completions list unless they had an appropriate failure.

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

usb: host: ohci-tmio: check return value after calling platform_get_resource()

It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value.

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

usb: typec: tipd: Remove WARN_ON in tps6598x_block_read

Calling tps6598x_block_read with a higher than allowed len can be handled by just returning an error. There's no need to crash systems with panic-on-warn enabled.

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

scsi: advansys: Fix kernel pointer leak

Pointers should be printed with %p or %px rather than cast to 'unsigned long' and printed with %lx.

Change %lx to %p to print the hashed pointer.

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

scsi: scsi_debug: Fix out-of-bound read in resp_report_tgtpgs()

The following issue was observed running syzkaller:

BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:377 [inline] BUG: KASAN: slab-out-of-bounds in sg_copy_buffer+0x150/0x1c0 lib/scatterlist.c:831 Read of size 2132 at addr ffff8880aea95dc8 by task syz-executor.0/9815

CPU: 0 PID: 9815 Comm: syz-executor.0 Not tainted 4.19.202-00874-gfc0fe04215a9 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Call Trace:
__dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xe4/0x14a lib/dump_stack.c:118 print_address_description+0x73/0x280 mm/kasan/report.c:253 kasan_report_error mm/kasan/report.c:352 [inline] kasan_report+0x272/0x370 mm/kasan/report.c:410 memcpy+0x1f/0x50 mm/kasan/kasan.c:302 memcpy include/linux/string.h:377 [inline] sg_copy_buffer+0x150/0x1c0 lib/scatterlist.c:831 fill_from_dev_buffer+0x14f/0x340 drivers/scsi/scsi_debug.c:1021 resp_report_tgtpgs+0x5aa/0x770 drivers/scsi/scsi_debug.c:1772 schedule_resp+0x464/0x12f0 drivers/scsi/scsi_debug.c:4429 scsi_debug_queuecommand+0x467/0x1390 drivers/scsi/scsi_debug.c:5835 scsi_dispatch_cmd+0x3fc/0x9b0 drivers/scsi/scsi_lib.c:1896 scsi_request_fn+0x1042/0x1810 drivers/scsi/scsi_lib.c:2034
__blk_run_queue_uncond block/blk-core.c:464 [inline]
__blk_run_queue+0x1a4/0x380 block/blk-core.c:484 blk_execute_rq_nowait+0x1c2/0x2d0 block/blk-exec.c:78 sg_common_write.isra.19+0xd74/0x1dc0 drivers/scsi/sg.c:847 sg_write.part.23+0x6e0/0xd00 drivers/scsi/sg.c:716 sg_write+0x64/0xa0 drivers/scsi/sg.c:622
__vfs_write+0xed/0x690 fs/read_write.c:485 kill_bdev:block_device:00000000e138492c vfs_write+0x184/0x4c0 fs/read_write.c:549 ksys_write+0x107/0x240 fs/read_write.c:599 do_syscall_64+0xc2/0x560 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x49/0xbe

We get 'alen' from command its type is int. If userspace passes a large length we will get a negative 'alen'.

Switch n, alen, and rlen to u32.

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

ocfs2: mount fails with buffer overflow in strlen

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

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

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

ocfs2: fix data corruption after conversion from inline format

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

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

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

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

Simple reproducer for the problem is:

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

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

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

[[email protected]: fix whitespace, per Joseph]

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

isofs: Fix out of bound access for corrupted isofs image

When isofs image is su ...

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.

Plugin Details

Severity: High

ID: 276342

File Name: tencentos_TSSA_2024_0557.nasl

Version: 1.1

Type: local

Family: Tencent Local Security Checks

Published: 11/20/2025

Updated: 11/20/2025

Supported Sensors: Nessus

Risk Information

VPR

Risk Factor: Critical

Score: 9.7

CVSS v2

Risk Factor: High

Base Score: 7.2

Temporal Score: 6.3

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

CVSS Score Source: CVE-2021-3493

CVSS v3

Risk Factor: High

Base Score: 7.8

Temporal Score: 7.5

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

CVSS Score Source: CVE-2024-27008

Vulnerability Information

CPE: cpe:/o:tencent:tencentos_server:2, 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 Available: true

Exploit Ease: Exploits are available

Patch Publication Date: 10/12/2024

Vulnerability Publication Date: 4/15/2021

CISA Known Exploited Vulnerability Due Dates: 11/10/2022

Reference Information

CVE: CVE-2020-36775, CVE-2021-3493, CVE-2021-46933, CVE-2021-46989, CVE-2021-47000, CVE-2021-47049, CVE-2021-47070, CVE-2021-47074, CVE-2021-47087, CVE-2021-47095, CVE-2021-47109, CVE-2021-47142, CVE-2021-47165, CVE-2021-47167, CVE-2021-47170, CVE-2021-47171, CVE-2021-47177, CVE-2021-47179, CVE-2021-47182, CVE-2021-47185, CVE-2021-47202, CVE-2021-47203, CVE-2021-47206, CVE-2021-47210, CVE-2021-47216, CVE-2021-47219, CVE-2021-47458, CVE-2021-47460, CVE-2021-47478, CVE-2021-47506, CVE-2021-47507, CVE-2022-42703, CVE-2022-4382, CVE-2022-48627, CVE-2022-48629, CVE-2022-48630, CVE-2022-48664, CVE-2022-48674, CVE-2023-39198, CVE-2023-52436, CVE-2023-52439, CVE-2023-52443, CVE-2023-52444, CVE-2023-52448, CVE-2023-52464, CVE-2023-52500, CVE-2023-52515, CVE-2023-52566, CVE-2023-52585, CVE-2023-52601, CVE-2023-52602, CVE-2023-52603, CVE-2023-52604, CVE-2023-52612, CVE-2023-52622, CVE-2023-52642, CVE-2023-52699, CVE-2024-0841, CVE-2024-23851, CVE-2024-26598, CVE-2024-26622, CVE-2024-26659, CVE-2024-26685, CVE-2024-26688, CVE-2024-26697, CVE-2024-26736, CVE-2024-26744, CVE-2024-26763, CVE-2024-26764, CVE-2024-26773, CVE-2024-26810, CVE-2024-26817, CVE-2024-26878, CVE-2024-26901, CVE-2024-26993, CVE-2024-27008, CVE-2024-35807, CVE-2024-35815, CVE-2024-35821, CVE-2024-35849

Detections

Analytics