Detections
Analytics
Alibaba Cloud Linux 3 : 0075: cloud-kernel bugfix, enhancement and (ALINUX3-SA-2025:0075)
critical Nessus Plugin ID 237278
Synopsis
The remote Alibaba Cloud Linux host is missing one or more security updates.Description
The remote Alibaba Cloud Linux 3 host has packages installed that are affected by multiple vulnerabilities as referenced in the ALINUX3-SA-2025:0075 advisory.Package updates are available for Alibaba Cloud Linux 3 that fix the following vulnerabilities:
CVE-2022-48635:
In the Linux kernel, the following vulnerability has been resolved:
fsdax: Fix infinite loop in dax_iomap_rw() I got an infinite loop and a WARNING report when executing a tail command in virtiofs.
WARNING: CPU: 10 PID: 964 at fs/iomap/iter.c:34 iomap_iter+0x3a2/0x3d0 Modules linked in:
CPU: 10 PID: 964 Comm: tail Not tainted 5.19.0-rc7 Call Trace:
<TASK> dax_iomap_rw+0xea/0x620 ? __this_cpu_preempt_check+0x13/0x20 fuse_dax_read_iter+0x47/0x80 fuse_file_read_iter+0xae/0xd0 new_sync_read+0xfe/0x180 ? 0xffffffff81000000 vfs_read+0x14d/0x1a0 ksys_read+0x6d/0xf0
__x64_sys_read+0x1a/0x20 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd The tail command will call read() with a count of 0. In this case, iomap_iter() will report this WARNING, and always return 1 which casuing the infinite loop in dax_iomap_rw().
Fixing by checking count whether is 0 in dax_iomap_rw().
CVE-2022-48639:
In the Linux kernel, the following vulnerability has been resolved:
net: sched: fix possible refcount leak in tc_new_tfilter() tfilter_put need to be called to put the refount got by tp->ops->get to avoid possible refcount leak when chain->tmplt_ops != NULL and chain->tmplt_ops != tp->ops.
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 incredibly strange API design decision, qdisc->destroy() gets called even if qdisc->init() never succeeded, not exclusively since commit 87b60cfacf9f (net_sched: fix error recovery at qdisc creation), but apparently also earlier (in the case of qdisc_create_dflt()).
The taprio qdisc does not fully acknowledge this when it attempts full offload, because it starts off with q->flags = TAPRIO_FLAGS_INVALID in taprio_init(), then it replaces q->flags with TCA_TAPRIO_ATTR_FLAGS parsed from netlink (in taprio_change(), tail called from taprio_init()).
determines what to do based on FULL_OFFLOAD_IS_ENABLED(q->flags).
But looking at the implementation of FULL_OFFLOAD_IS_ENABLED() (a bitwise check of bit 1 in q->flags), it is invalid to call this macro on q->flags when it contains TAPRIO_FLAGS_INVALID, because that is set to U32_MAX, and therefore FULL_OFFLOAD_IS_ENABLED() will return true on
CVE-2022-48651:
In the Linux kernel, the following vulnerability has been resolved:
ipvlan: Fix out-of-bound bugs caused by unset skb->mac_header If an AF_PACKET socket is used to send packets through ipvlan and the default xmit function of the AF_PACKET socket is changed from dev_queue_xmit() to packet_direct_xmit() via setsockopt() with the option name of PACKET_QDISC_BYPASS, the skb->mac_header may not be reset and remains as the initial value of 65535, this may trigger slab-out-of-bounds bugs as following:
================================================================= UG: KASAN: slab-out-of-bounds in ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan] PU: 2 PID: 1768 Comm: raw_send Kdump: loaded Not tainted 6.0.0-rc4+ #6 ardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 all Trace:
print_address_description.constprop.0+0x1d/0x160 print_report.cold+0x4f/0x112 kasan_report+0xa3/0x130 ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan] ipvlan_start_xmit+0x29/0xa0 [ipvlan]
__dev_direct_xmit+0x2e2/0x380 packet_direct_xmit+0x22/0x60 packet_snd+0x7c9/0xc40 sock_sendmsg+0x9a/0xa0
__sys_sendto+0x18a/0x230
__x64_sys_sendto+0x74/0x90 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd The root cause is:
1. packet_snd() only reset skb->mac_header when sock->type is SOCK_RAW and skb->protocol is not specified as in packet_parse_headers() 2. packet_direct_xmit() doesn't reset skb->mac_header as dev_queue_xmit() In this case, skb->mac_header is 65535 when ipvlan_xmit_mode_l2() is called. So when ipvlan_xmit_mode_l2() gets mac header with eth_hdr() which use skb->head + skb->mac_header, out-of-bound access occurs.
This patch replaces eth_hdr() with skb_eth_hdr() in ipvlan_xmit_mode_l2() and reset mac header in multicast to solve this out-of-bound bug.
CVE-2022-48675:
In the Linux kernel, the following vulnerability has been resolved:
IB/core: Fix a nested dead lock as part of ODP flow Fix a nested dead lock as part of ODP flow by using mmput_async().
From the below call trace [1] can see that calling mmput() once we have the umem_odp->umem_mutex locked as required by ib_umem_odp_map_dma_and_lock() might trigger in the same task the exit_mmap()->__mmu_notifier_release()->mlx5_ib_invalidate_range() which may dead lock when trying to lock the same mutex.
Moving to use mmput_async() will solve the problem as the above exit_mmap() flow will be called in other task and will be executed once the lock will be available.
CVE-2022-48828:
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Fix ia_size underflow iattr::ia_size is a loff_t, which is a signed 64-bit type. NFSv3 and NFSv4 both define file size as an unsigned 64-bit type. Thus there is a range of valid file size values an NFS client can send that is already larger than Linux can handle.
Currently decode_fattr4() dumps a full u64 value into ia_size. If that value happens to be larger than S64_MAX, then ia_size underflows. I'm about to fix up the NFSv3 behavior as well, so let's catch the underflow in the common code path: nfsd_setattr().
CVE-2022-48946:
In the Linux kernel, the following vulnerability has been resolved:
udf: Fix preallocation discarding at indirect extent boundary When preallocation extent is the first one in the extent block, the code would corrupt extent tree header instead. Fix the problem and use udf_delete_aext() for deleting extent to avoid some code duplication.
CVE-2022-48981:
In the Linux kernel, the following vulnerability has been resolved:
drm/shmem-helper: Remove errant put in error path drm_gem_shmem_mmap() doesn't own this reference, resulting in the GEM object getting prematurely freed leading to a later use-after-free.
CVE-2022-48993:
[REJECTED CVE] A memory initialization vulnerability in the Linux Kernel's fbcon module allows uninitialized memory in the save variable to be copied during operations in fbcon_prepare_logo(). This can result in unpredictable behavior, including kernel crashes or memory corruption, when handling frame buffer devices.
CVE-2022-49014:
In the Linux kernel, the following vulnerability has been resolved:
net: tun: Fix use-after-free in tun_detach() syzbot reported use-after-free in tun_detach() [1]. This causes call trace like below:
================================================================== BUG: KASAN: use-after-free in notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75 Read of size 8 at addr ffff88807324e2a8 by task syz-executor.0/3673 CPU: 0 PID: 3673 Comm: syz-executor.0 Not tainted 6.1.0-rc5-syzkaller-00044-gcc675d22e422 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x15e/0x461 mm/kasan/report.c:395 kasan_report+0xbf/0x1f0 mm/kasan/report.c:495 notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75 call_netdevice_notifiers_info+0x86/0x130 net/core/dev.c:1942 call_netdevice_notifiers_extack net/core/dev.c:1983 [inline] call_netdevice_notifiers net/core/dev.c:1997 [inline] netdev_wait_allrefs_any net/core/dev.c:10237 [inline]
CVE-2022-49046:
In the Linux kernel, the following vulnerability has been resolved:
i2c: dev: check return value when calling dev_set_name() If dev_set_name() fails, the dev_name() is null, check the return value of dev_set_name() to avoid the null-ptr-deref.
CVE-2022-49190:
In the Linux kernel, the following vulnerability has been resolved:
kernel/resource: fix kfree() of bootmem memory again Since commit ebff7d8f270d (mem hotunplug: fix kfree() of bootmem memory), we could get a resource allocated during boot via alloc_resource(). And it's required to release the resource using free_resource(). Howerver, many people use kfree directly which will result in kernel BUG. In order to fix this without fixing every call site, just leak a couple of bytes in such corner case.
CVE-2022-49219:
In the Linux kernel, the following vulnerability has been resolved:
vfio/pci: fix memory leak during D3hot to D0 transition If 'vfio_pci_core_device::needs_pm_restore' is set (PCI device does not have No_Soft_Reset bit set in its PMCSR config register), then the current PCI state will be saved locally in 'vfio_pci_core_device::pm_save' during D0->D3hot transition and same will be restored back during D3hot->D0 transition.
For saving the PCI state locally, pci_store_saved_state() is being used and the pci_load_and_free_saved_state() will free the allocated memory.
But for reset related IOCTLs, vfio driver calls PCI reset-related API's which will internally change the PCI power state back to D0. So, when the guest resumes, then it will get the current state as D0 and it will skip the call to vfio_pci_set_power_state() for changing the power state to D0 explicitly. In this case, the memory pointed by 'pm_save' will never be freed. In a malicious sequence, the state changing to D3hot followed by VFIO_DEVICE_RESET/VFIO_DEVICE_PCI_HOT_RESET can be run in a loop and it can cause an OOM situation.
This patch frees the earlier allocated memory first before overwriting 'pm_save' to prevent the mentioned memory leak.
CVE-2022-49398:
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc3: gadget: Replace list_for_each_entry_safe() if using giveback The list_for_each_entry_safe() macro saves the current item (n) and the item after (n+1), so that n can be safely removed without corrupting the list. However, when traversing the list and removing items using gadget giveback, the DWC3 lock is briefly released, allowing other routines to execute. There is a situation where, while items are being removed from the cancelled_list using dwc3_gadget_ep_cleanup_cancelled_requests(), the pullup disable routine is running in parallel (due to UDC unbind). As the cleanup routine removes n, and the pullup disable removes n+1, once the
CVE-2022-49443:
In the Linux kernel, the following vulnerability has been resolved:
list: fix a data-race around ep->rdllist ep_poll() first calls ep_events_available() with no lock held and checks if ep->rdllist is empty by list_empty_careful(), which reads rdllist->prev. Thus all accesses to it need some protection to avoid store/load-tearing.
Note INIT_LIST_HEAD_RCU() already has the annotation for both prev and next.
Commit bf3b9f6372c4 (epoll: Add busy poll support to epoll with socket fds.) added the first lockless ep_events_available(), and commit c5a282e9635e (fs/epoll: reduce the scope of wq lock in epoll_wait()) made some ep_events_available() calls lockless and added single call under a lock, finally commit e59d3c64cba6 (epoll: eliminate unnecessary lock for zero timeout) made the last ep_events_available() lockless.
BUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0:
INIT_LIST_HEAD include/linux/list.h:38 [inline] list_splice_init include/linux/list.h:492 [inline] ep_start_scan fs/eventpoll.c:622 [inline] ep_send_events fs/eventpoll.c:1656 [inline] ep_poll fs/eventpoll.c:1806 [inline] do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline]
__do_sys_epoll_pwait fs/eventpoll.c:2281 [inline]
__se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275
__x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1:
list_empty_careful include/linux/list.h:329 [inline] ep_events_available fs/eventpoll.c:381 [inline] ep_poll fs/eventpoll.c:1797 [inline] do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline]
__do_sys_epoll_pwait fs/eventpoll.c:2281 [inline]
__se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275
__x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0xffff88810480c7d0 -> 0xffff888103c15098 Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted: G W 5.17.0-rc7-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
CVE-2022-49444:
In the Linux kernel, the following vulnerability has been resolved:
module: fix [e_shstrndx].sh_size=0 OOB access It is trivial to craft a module to trigger OOB access in this line:
if (info->secstrings[strhdr->sh_size - 1] != '\0') { BUG: unable to handle page fault for address: ffffc90000aa0fff PGD 100000067 P4D 100000067 PUD 100066067 PMD 10436f067 PTE 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 7 PID: 1215 Comm: insmod Not tainted 5.18.0-rc5-00007-g9bf578647087-dirty #10 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014 RIP: 0010:load_module+0x19b/0x2391 [rebased patch onto modules-next]
CVE-2022-49562:
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Use __try_cmpxchg_user() to update guest PTE A/D bits Use the recently introduced __try_cmpxchg_user() to update guest PTE A/D bits instead of mapping the PTE into kernel address space. The VM_PFNMAP path is broken as it assumes that vm_pgoff is the base pfn of the mapped VMA range, which is conceptually wrong as vm_pgoff is the offset relative to the file and has nothing to do with the pfn. The horrific hack worked for the original use case (backing guest memory with /dev/mem), but leads to accessing random pfns for pretty much any other VM_PFNMAP case.
CVE-2022-49711:
In the Linux kernel, the following vulnerability has been resolved:
bus: fsl-mc-bus: fix KASAN use-after-free in fsl_mc_bus_remove() In fsl_mc_bus_remove(), mc->root_mc_bus_dev->mc_io is passed to fsl_destroy_mc_io(). However, mc->root_mc_bus_dev is already freed in fsl_mc_device_remove(). Then reference to mc->root_mc_bus_dev->mc_io triggers KASAN use-after-free. To avoid the use-after-free, keep the reference to mc->root_mc_bus_dev->mc_io in a local variable and pass to fsl_destroy_mc_io().
This patch needs rework to apply to kernels older than v5.15.
CVE-2023-52448:
In the Linux kernel, the following vulnerability has been resolved:
gfs2: Fix kernel NULL pointer dereference in gfs2_rgrp_dump Syzkaller has reported a NULL pointer dereference when accessing rgd->rd_rgl in gfs2_rgrp_dump(). This can happen when creating rgd->rd_gl fails in read_rindex_entry(). Add a NULL pointer check in gfs2_rgrp_dump() to prevent that.
CVE-2023-52463:
In the Linux kernel, the following vulnerability has been resolved:
efivarfs: force RO when remounting if SetVariable is not supported If SetVariable at runtime is not supported by the firmware we never assign a callback for that function. At the same time mount the efivarfs as RO so no one can call that. However, we never check the permission flags when someone remounts the filesystem as RW. As a result this leads to a
CVE-2023-52464:
In the Linux kernel, the following vulnerability has been resolved:
EDAC/thunderx: Fix possible out-of-bounds string access Enabling -Wstringop-overflow globally exposes a warning for a common bug in the usage of strncat():
drivers/edac/thunderx_edac.c: In function 'thunderx_ocx_com_threaded_isr':
drivers/edac/thunderx_edac.c:1136:17: error: 'strncat' specified bound 1024 equals destination size [-Werror=stringop-overflow=] 1136 | strncat(msg, other, OCX_MESSAGE_SIZE);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...
1145 | strncat(msg, other, OCX_MESSAGE_SIZE);
...
1150 | strncat(msg, other, OCX_MESSAGE_SIZE);
...
Apparently the author of this driver expected strncat() to behave the way that strlcat() does, which uses the size of the destination buffer as its third argument rather than the length of the source buffer. The result is that there is no check on the size of the allocated buffer.
Change it to strlcat().
[ bp: Trim compiler output, fixup commit message. ]
CVE-2023-52477:
In the Linux kernel, the following vulnerability has been resolved:
usb: hub: Guard against accesses to uninitialized BOS descriptors Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h access fields inside udev->bos without checking if it was allocated and initialized. If usb_get_bos_descriptor() fails for whatever reason, udev->bos will be NULL and those accesses will result in a crash:
BUG: kernel NULL pointer dereference, address: 0000000000000018 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1> Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:hub_port_reset+0x193/0x788 Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9 RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310 RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840 RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0 Call Trace:
hub_event+0x73f/0x156e ? hub_activate+0x5b7/0x68f process_one_work+0x1a2/0x487
CVE-2023-52486:
In the Linux kernel, the following vulnerability has been resolved:
drm: Don't unref the same fb many times by mistake due to deadlock handling If we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl() we proceed to unref the fb and then retry the whole thing from the top.
But we forget to reset the fb pointer back to NULL, and so if we then get another error during the retry, before the fb lookup, we proceed the unref the same fb again without having gotten another reference.
The end result is that the fb will (eventually) end up being freed while it's still in use.
Reset fb to NULL once we've unreffed it to avoid doing it again until we've done another fb lookup.
This turned out to be pretty easy to hit on a DG2 when doing async flips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I saw that drm_closefb() simply got stuck in a busy loop while walking the framebuffer list. Fortunately I was able to convince it to oops instead, and from there it was easier to track down the culprit.
CVE-2023-52503:
In the Linux kernel, the following vulnerability has been resolved:
tee: amdtee: fix use-after-free vulnerability in amdtee_close_session There is a potential race condition in amdtee_close_session that may cause use-after-free in amdtee_open_session. For instance, if a session has refcount == 1, and one thread tries to free this session via:
kref_put(&sess->refcount, destroy_session);
the reference count will get decremented, and the next step would be to call destroy_session(). However, if in another thread, amdtee_open_session() is called before destroy_session() has completed execution, alloc_session() may return 'sess' that will be freed up later in destroy_session() leading to use-after-free in amdtee_open_session.
To fix this issue, treat decrement of sess->refcount and removal of 'sess' from session list in destroy_session() as a critical section, so that it is executed atomically.
CVE-2023-52618:
In the Linux kernel, the following vulnerability has been resolved:
block/rnbd-srv: Check for unlikely string overflow Since dev_search_path can technically be as large as PATH_MAX, there was a risk of truncation when copying it and a second string into full_path since it was also PATH_MAX sized. The W=1 builds were reporting this warning:
drivers/block/rnbd/rnbd-srv.c: In function 'process_msg_open.isra':
drivers/block/rnbd/rnbd-srv.c:616:51: warning: '%s' directive output may be truncated writing up to 254 bytes into a region of size between 0 and 4095 [-Wformat-truncation=] 616 | snprintf(full_path, PATH_MAX, %s/%s, | ^~ In function 'rnbd_srv_get_full_path', inlined from 'process_msg_open.isra' at drivers/block/rnbd/rnbd-srv.c:721:14: drivers/block/rnbd/rnbd- srv.c:616:17: note: 'snprintf' output between 2 and 4351 bytes into a destination of size 4096 616 | snprintf(full_path, PATH_MAX, %s/%s, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CVE-2023-52756:
[REJECTED CVE] A double shift vulnerability was identified in the Linux kernel's pwm subsystem. The issue involves passing a shifted value instead of a bit number to set/test_bit() functions, resulting in a double shift (e.g., BIT(BIT(1))). While this doesn't cause problems for values 0 or 1, values of 5 or higher could lead to a buffer overflow, potentially allowing attackers to cause a denial of service.
CVE-2023-52759:
[REJECTED CVE] In the Linux kernel, the following vulnerability has been resolved:
gfs2: ignore negated quota changes The Linux kernel CVE team has assigned CVE-2023-52759 to this issue.
CVE-2023-52789:
In the Linux kernel, the following vulnerability has been resolved:
tty: vcc: Add check for kstrdup() in vcc_probe() Add check for the return value of kstrdup() and return the error, if it fails in order to avoid NULL pointer dereference.
CVE-2023-52836:
In the Linux kernel, the following vulnerability has been resolved:
locking/ww_mutex/test: Fix potential workqueue corruption In some cases running with the test-ww_mutex code, I was seeing odd behavior where sometimes it seemed flush_workqueue was returning before all the work threads were finished.
Often this would cause strange crashes as the mutexes would be freed while they were being used.
Looking at the code, there is a lifetime problem as the controlling thread that spawns the work allocates the struct stress structures that are passed to the workqueue threads. Then when the workqueue threads are finished, they free the stress struct that was passed to them.
Unfortunately the workqueue work_struct node is in the stress struct. Which means the work_struct is freed before the work thread returns and while flush_workqueue is waiting.
It seems like a better idea to have the controlling thread both allocate and free the stress structures, so that we can be sure we don't corrupt the workqueue by freeing the structure prematurely.
So this patch reworks the test to do so, and with this change I no longer see the early flush_workqueue returns.
CVE-2023-52880:
In the Linux kernel, the following vulnerability has been resolved:
tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc Any unprivileged user can attach N_GSM0710 ldisc, but it requires CAP_NET_ADMIN to create a GSM network anyway.
Require initial namespace CAP_NET_ADMIN to do that.
CVE-2023-52898:
In the Linux kernel, the following vulnerability has been resolved:
xhci: Fix null pointer dereference when host dies Make sure xhci_free_dev() and xhci_kill_endpoint_urbs() do not race and cause null pointer dereference when host suddenly dies.
Usb core may call xhci_free_dev() which frees the xhci->devs[slot_id]
CVE-2023-52917:
[REJECTED CVE] In the Linux kernel, the following vulnerability has been resolved:
ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.
CVE-2024-26591:
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix re-attachment branch in bpf_tracing_prog_attach The following case can cause a crash due to missing attach_btf:
1) load rawtp program 2) load fentry program with rawtp as target_fd 3) create tracing link for fentry program with target_fd = 0 4) repeat 3 In the end we have:
- prog->aux->dst_trampoline == NULL
- tgt_prog == NULL (because we did not provide target_fd to link_create)
- prog->aux->attach_btf == NULL (the program was loaded with attach_prog_fd=X)
- the program was loaded for tgt_prog but we have no way to find out which one BUG: kernel NULL pointer dereference, address: 0000000000000058 Call Trace:
<TASK> ? __die+0x20/0x70 ? page_fault_oops+0x15b/0x430 ? fixup_exception+0x22/0x330 ? exc_page_fault+0x6f/0x170 ? asm_exc_page_fault+0x22/0x30 ? bpf_tracing_prog_attach+0x279/0x560 ? btf_obj_id+0x5/0x10 bpf_tracing_prog_attach+0x439/0x560
__sys_bpf+0x1cf4/0x2de0
CVE-2024-26598:
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: vgic-its: Avoid potential UAF in LPI translation cache
CVE-2024-26629:
In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix RELEASE_LOCKOWNER
CVE-2024-26641:
In the Linux kernel, the following vulnerability has been resolved:
ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv() syzbot found __ip6_tnl_rcv() could access unitiliazed data [1].
CVE-2024-26642:
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: disallow anonymous set with timeout flag Anonymous sets are never used with timeout from userspace, reject this.
CVE-2024-26718:
In the Linux kernel, the following vulnerability has been resolved:
dm-crypt, dm-verity: disable tasklets Tasklets have an inherent problem with memory corrupti ...
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 Alibaba Cloud 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
http://mirrors.aliyun.com/alinux/3/cve/alinux3-sa-20250075.xml
Plugin Details
Severity: Critical
ID: 237278
File Name: alinux3_sa_2025-0075.nasl
Version: 1.2
Type: local
Published: 5/27/2025
Updated: 9/23/2025
Supported Sensors: Nessus
Risk Information
VPR
Risk Factor: Critical
Score: 9.0
CVSS v2
Risk Factor: High
Base Score: 9.4
Temporal Score: 7.8
Vector: CVSS2#AV:N/AC:L/Au:N/C:C/I:N/A:C
CVSS Score Source: CVE-2024-47685
CVSS v3
Risk Factor: Critical
Base Score: 9.1
Temporal Score: 8.4
Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
Temporal Vector: CVSS:3.0/E:F/RL:O/RC:C
Vulnerability Information
CPE: p-cpe:/a:alibabacloud:alibaba_cloud_linux_3:kernel-debug-core, p-cpe:/a:alibabacloud:alibaba_cloud_linux_3:kernel-tools, p-cpe:/a:alibabacloud:alibaba_cloud_linux_3:bpftool, p-cpe:/a:alibabacloud:alibaba_cloud_linux_3:kernel-debuginfo-common-aarch64, p-cpe:/a:alibabacloud:alibaba_cloud_linux_3:bpftool-debuginfo, p-cpe:/a:alibabacloud:alibaba_cloud_linux_3:kernel-debuginfo, p-cpe:/a:alibabacloud:alibaba_cloud_linux_3:kernel-core, p-cpe:/a:alibabacloud:alibaba_cloud_linux_3:kernel-tools-libs-devel, p-cpe:/a:alibabacloud:alibaba_cloud_linux_3:perf, p-cpe:/a:alibabacloud:alibaba_cloud_linux_3:kernel-devel, p-cpe:/a:alibabacloud:alibaba_cloud_linux_3:kernel-modules, p-cpe:/a:alibabacloud:alibaba_cloud_linux_3:kernel-debug-modules-internal, p-cpe:/a:alibabacloud:alibaba_cloud_linux_3:kernel-debuginfo-common-x86_64, p-cpe:/a:alibabacloud:alibaba_cloud_linux_3:kernel-tools-debuginfo, p-cpe:/a:alibabacloud:alibaba_cloud_linux_3:python3-perf-debuginfo, p-cpe:/a:alibabacloud:alibaba_cloud_linux_3:python3-perf, p-cpe:/a:alibabacloud:alibaba_cloud_linux_3:kernel-debug, p-cpe:/a:alibabacloud:alibaba_cloud_linux_3:perf-debuginfo, p-cpe:/a:alibabacloud:alibaba_cloud_linux_3:kernel-debug-modules, p-cpe:/a:alibabacloud:alibaba_cloud_linux_3:kernel-debug-devel, p-cpe:/a:alibabacloud:alibaba_cloud_linux_3:kernel-tools-libs, cpe:/o:alibabacloud:alibaba_cloud_linux_3, p-cpe:/a:alibabacloud:alibaba_cloud_linux_3:kernel-modules-extra, p-cpe:/a:alibabacloud:alibaba_cloud_linux_3:kernel-debug-debuginfo, p-cpe:/a:alibabacloud:alibaba_cloud_linux_3:kernel-headers, p-cpe:/a:alibabacloud:alibaba_cloud_linux_3:kernel-debug-modules-extra, p-cpe:/a:alibabacloud:alibaba_cloud_linux_3:kernel, p-cpe:/a:alibabacloud:alibaba_cloud_linux_3:kernel-modules-internal
Required KB Items: Host/local_checks_enabled, Host/cpu, Host/Alibaba/release, Host/Alibaba/rpm-list
Exploit Available: true
Exploit Ease: Exploits are available
Patch Publication Date: 5/21/2025
Vulnerability Publication Date: 7/21/2021
CISA Known Exploited Vulnerability Due Dates: 2/26/2025
Reference Information
CVE: CVE-2022-48635, CVE-2022-48639, CVE-2022-48644, CVE-2022-48651, CVE-2022-48675, CVE-2022-48828, CVE-2022-48946, CVE-2022-48981, CVE-2022-49014, CVE-2022-49046, CVE-2022-49190, CVE-2022-49219, CVE-2022-49398, CVE-2022-49443, CVE-2022-49444, CVE-2022-49562, CVE-2022-49711, CVE-2023-52448, CVE-2023-52463, CVE-2023-52464, CVE-2023-52477, CVE-2023-52486, CVE-2023-52503, CVE-2023-52618, CVE-2023-52702, CVE-2023-52789, CVE-2023-52836, CVE-2023-52880, CVE-2023-52898, CVE-2024-26591, CVE-2024-26598, CVE-2024-26629, CVE-2024-26641, CVE-2024-26642, CVE-2024-26718, CVE-2024-26749, CVE-2024-26778, CVE-2024-26808, CVE-2024-26810, CVE-2024-26812, CVE-2024-26934, CVE-2024-26970, CVE-2024-26977, CVE-2024-26988, CVE-2024-27020, CVE-2024-27389, CVE-2024-27437, CVE-2024-35791, CVE-2024-35947, CVE-2024-36476, CVE-2024-36489, CVE-2024-36953, CVE-2024-37356, CVE-2024-38577, CVE-2024-38601, CVE-2024-38605, CVE-2024-39468, CVE-2024-39480, CVE-2024-41004, CVE-2024-41023, CVE-2024-41045, CVE-2024-42084, CVE-2024-42161, CVE-2024-42239, CVE-2024-42246, CVE-2024-42283, CVE-2024-42312, CVE-2024-43098, CVE-2024-43817, CVE-2024-43846, CVE-2024-43883, CVE-2024-43889, CVE-2024-43890, CVE-2024-43892, CVE-2024-43893, CVE-2024-43894, CVE-2024-43914, CVE-2024-44944, CVE-2024-44989, CVE-2024-44990, CVE-2024-45006, CVE-2024-46674, CVE-2024-46675, CVE-2024-46707, CVE-2024-46719, CVE-2024-46735, CVE-2024-46743, CVE-2024-46750, CVE-2024-46763, CVE-2024-46782, CVE-2024-46787, CVE-2024-46829, CVE-2024-47667, CVE-2024-47668, CVE-2024-47671, CVE-2024-47679, CVE-2024-47685, CVE-2024-47692, CVE-2024-47695, CVE-2024-47705, CVE-2024-47706, CVE-2024-47707, CVE-2024-47736, CVE-2024-47737, CVE-2024-47739, CVE-2024-47742, CVE-2024-48881, CVE-2024-49569, CVE-2024-49851, CVE-2024-49858, CVE-2024-49878, CVE-2024-49924, CVE-2024-49933, CVE-2024-49948, CVE-2024-49949, CVE-2024-49952, CVE-2024-49954, CVE-2024-49963, CVE-2024-49975, CVE-2024-49978, CVE-2024-50002, CVE-2024-50036, CVE-2024-50045, CVE-2024-50046, CVE-2024-50059, CVE-2024-50082, CVE-2024-50083, CVE-2024-50115, CVE-2024-50131, CVE-2024-50150, CVE-2024-50151, CVE-2024-50153, CVE-2024-50179, CVE-2024-50180, CVE-2024-50251, CVE-2024-50256, CVE-2024-50258, CVE-2024-50264, CVE-2024-50267, CVE-2024-50269, CVE-2024-50301, CVE-2024-50304, CVE-2024-53066, CVE-2024-53068, CVE-2024-53103, CVE-2024-53104, CVE-2024-53119, CVE-2024-53122, CVE-2024-53124, CVE-2024-53125, CVE-2024-53140, CVE-2024-53141, CVE-2024-53146, CVE-2024-53157, CVE-2024-53161, CVE-2024-53172, CVE-2024-53174, CVE-2024-53194, CVE-2024-53214, CVE-2024-53234, CVE-2024-56558, CVE-2024-56569, CVE-2024-56570, CVE-2024-56583, CVE-2024-56600, CVE-2024-56602, CVE-2024-56605, CVE-2024-56606, CVE-2024-56610, CVE-2024-56614, CVE-2024-56636, CVE-2024-56637, CVE-2024-56642, CVE-2024-56644, CVE-2024-56664, CVE-2024-56672, CVE-2024-56688, CVE-2024-56694, CVE-2024-56698, CVE-2024-56739, CVE-2024-56747, CVE-2024-56751, CVE-2024-56756, CVE-2024-56779, CVE-2024-56780, CVE-2024-57807, CVE-2024-57888, CVE-2024-57889, CVE-2024-57903, CVE-2024-57913, CVE-2024-57917, CVE-2024-57929, CVE-2024-57951, CVE-2024-57981, CVE-2024-58010, CVE-2025-21656, CVE-2025-21664, CVE-2025-21683, CVE-2025-21689, CVE-2025-21699, CVE-2025-21704, CVE-2025-21724, CVE-2025-21726, CVE-2025-21727, CVE-2025-21728, CVE-2025-21731, CVE-2025-21734, CVE-2025-21745, CVE-2025-21787, CVE-2025-21804, CVE-2025-21814, CVE-2025-21844, CVE-2025-21853, CVE-2025-21887