The remote CentOS Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the kernel-5.14.0-583.el9 build changelog.

  - In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: Fix class @block_class's     subsystem refcount leakage blkcg_fill_root_iostats() iterates over @block_class's devices by     class_dev_iter_(init|next)(), but does not end iterating with class_dev_iter_exit(), so causes the class's     subsystem refcount leakage. Fix by ending the iterating with class_dev_iter_exit(). (CVE-2025-21745)

  - In the Linux kernel, the following vulnerability has been resolved: io_uring/uring_cmd: unconditionally     copy SQEs at prep time This isn't generally necessary, but conditions have been observed where SQE data is     accessed from the original SQE after prep has been done and outside of the initial issue. Opcode prep     handlers must ensure that any SQE related data is stable beyond the prep phase, but uring_cmd is a bit     special in how it handles the SQE which makes it susceptible to reading stale data. If the application has     reused the SQE before the original completes, then that can lead to data corruption. Down the line we can     relax this again once uring_cmd has been sanitized a bit, and avoid unnecessarily copying the SQE.
    (CVE-2025-21837)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the kernel-5.14.0-582.el9 build changelog.

  - In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix memleak of     nhc_pcpu_rth_output in fib_check_nh_v6_gw(). fib_check_nh_v6_gw() expects that fib6_nh_init() cleans up     everything when it fails. Commit 7dd73168e273 (ipv6: Always allocate pcpu memory in a fib6_nh) moved     fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init() but forgot to add cleanup for     fib6_nh->nh_common.nhc_pcpu_rth_output in case it fails to allocate fib6_nh->rt6i_pcpu, resulting in     memleak. Let's call fib_nh_common_release() and clear nhc_pcpu_rth_output in the error path. Note that we     can remove the fib6_nh_release() call in nh_create_ipv6() later in net-next.git. (CVE-2025-22005)

  - In the Linux kernel, the following vulnerability has been resolved: igb: Fix potential invalid memory     access in igb_init_module() The pci_register_driver() can fail and when this happened, the dca_notifier     needs to be unregistered, otherwise the dca_notifier can be called when igb fails to install, resulting to     invalid memory access. (CVE-2024-52332)

  - In the Linux kernel, the following vulnerability has been resolved: nfsd: release svc_expkey/svc_export     with rcu_work The last reference for `cache_head` can be reduced to zero in `c_show` and `e_show`(using     `rcu_read_lock` and `rcu_read_unlock`). Consequently, `svc_export_put` and `expkey_put` will be invoked,     leading to two issues: 1. The `svc_export_put` will directly free ex_uuid. However, `e_show`/`c_show` will     access `ex_uuid` after `cache_put`, which can trigger a use-after-free issue, shown below.
    ================================================================== BUG: KASAN: slab-use-after-free in     svc_export_show+0x362/0x430 [nfsd] Read of size 1 at addr ff11000010fdc120 by task cat/870 CPU: 1 UID: 0     PID: 870 Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS     1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x53/0x70     print_address_description.constprop.0+0x2c/0x3a0 print_report+0xb9/0x280 kasan_report+0xae/0xe0     svc_export_show+0x362/0x430 [nfsd] c_show+0x161/0x390 [sunrpc] seq_read_iter+0x589/0x770     seq_read+0x1e5/0x270 proc_reg_read+0xe1/0x140 vfs_read+0x125/0x530 ksys_read+0xc1/0x160     do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 830:
    kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0
    __kmalloc_node_track_caller_noprof+0x1bc/0x400 kmemdup_noprof+0x22/0x50 svc_export_parse+0x8a9/0xb80     [nfsd] cache_do_downcall+0x71/0xa0 [sunrpc] cache_write_procfs+0x8e/0xd0 [sunrpc]     proc_reg_write+0xe1/0x140 vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170     entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 868: kasan_save_stack+0x20/0x40     kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kfree+0xf3/0x3e0     svc_export_put+0x87/0xb0 [nfsd] cache_purge+0x17f/0x1f0 [sunrpc] nfsd_destroy_serv+0x226/0x2d0 [nfsd]     nfsd_svc+0x125/0x1e0 [nfsd] write_threads+0x16a/0x2a0 [nfsd] nfsctl_transaction_write+0x74/0xa0 [nfsd]     vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170     entry_SYSCALL_64_after_hwframe+0x76/0x7e 2. We cannot sleep while using `rcu_read_lock`/`rcu_read_unlock`.
    However, `svc_export_put`/`expkey_put` will call path_put, which subsequently triggers a sleeping     operation due to the following `dput`. ============================= WARNING: suspicious RCU usage     5.10.0-dirty #141 Not tainted ----------------------------- ... Call Trace: dump_stack+0x9a/0xd0
    ___might_sleep+0x231/0x240 dput+0x39/0x600 path_put+0x1b/0x30 svc_export_put+0x17/0x80 e_show+0x1c9/0x200     seq_read_iter+0x63f/0x7c0 seq_read+0x226/0x2d0 vfs_read+0x113/0x2c0 ksys_read+0xc9/0x170     do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Fix these issues by using `rcu_work` to     help release `svc_expkey`/`svc_export`. This approach allows for an asynchronous context to invoke     `path_put` and also facilitates the freeing of `uuid/exp/key` after an RCU grace period. (CVE-2024-53216)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: iso: Fix circular lock in     iso_conn_big_sync This fixes the circular locking dependency warning below, by reworking iso_sock_recvmsg,     to ensure that the socket lock is always released before calling a function that locks hdev. [ 561.670344]     ====================================================== [ 561.670346] WARNING: possible circular locking     dependency detected [ 561.670349] 6.12.0-rc6+ #26 Not tainted [ 561.670351]
    ------------------------------------------------------ [ 561.670353] iso-tester/3289 is trying to acquire     lock: [ 561.670355] ffff88811f600078 (&hdev->lock){+.+.}-{3:3}, at: iso_conn_big_sync+0x73/0x260     [bluetooth] [ 561.670405] but task is already holding lock: [ 561.670407] ffff88815af58258 (sk_lock-     AF_BLUETOOTH){+.+.}-{0:0}, at: iso_sock_recvmsg+0xbf/0x500 [bluetooth] [ 561.670450] which lock already     depends on the new lock. [ 561.670452] the existing dependency chain (in reverse order) is: [ 561.670453]
    -> #2 (sk_lock-AF_BLUETOOTH){+.+.}-{0:0}: [ 561.670458] lock_acquire+0x7c/0xc0 [ 561.670463]     lock_sock_nested+0x3b/0xf0 [ 561.670467] bt_accept_dequeue+0x1a5/0x4d0 [bluetooth] [ 561.670510]     iso_sock_accept+0x271/0x830 [bluetooth] [ 561.670547] do_accept+0x3dd/0x610 [ 561.670550]
    __sys_accept4+0xd8/0x170 [ 561.670553] __x64_sys_accept+0x74/0xc0 [ 561.670556] x64_sys_call+0x17d6/0x25f0     [ 561.670559] do_syscall_64+0x87/0x150 [ 561.670563] entry_SYSCALL_64_after_hwframe+0x76/0x7e [     561.670567] -> #1 (sk_lock-AF_BLUETOOTH-BTPROTO_ISO){+.+.}-{0:0}: [ 561.670571] lock_acquire+0x7c/0xc0 [     561.670574] lock_sock_nested+0x3b/0xf0 [ 561.670577] iso_sock_listen+0x2de/0xf30 [bluetooth] [ 561.670617]
    __sys_listen_socket+0xef/0x130 [ 561.670620] __x64_sys_listen+0xe1/0x190 [ 561.670623]     x64_sys_call+0x2517/0x25f0 [ 561.670626] do_syscall_64+0x87/0x150 [ 561.670629]     entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 561.670632] -> #0 (&hdev->lock){+.+.}-{3:3}: [ 561.670636]
    __lock_acquire+0x32ad/0x6ab0 [ 561.670639] lock_acquire.part.0+0x118/0x360 [ 561.670642]     lock_acquire+0x7c/0xc0 [ 561.670644] __mutex_lock+0x18d/0x12f0 [ 561.670647] mutex_lock_nested+0x1b/0x30 [     561.670651] iso_conn_big_sync+0x73/0x260 [bluetooth] [ 561.670687] iso_sock_recvmsg+0x3e9/0x500     [bluetooth] [ 561.670722] sock_recvmsg+0x1d5/0x240 [ 561.670725] sock_read_iter+0x27d/0x470 [ 561.670727]     vfs_read+0x9a0/0xd30 [ 561.670731] ksys_read+0x1a8/0x250 [ 561.670733] __x64_sys_read+0x72/0xc0 [     561.670736] x64_sys_call+0x1b12/0x25f0 [ 561.670738] do_syscall_64+0x87/0x150 [ 561.670741]     entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 561.670744] other info that might help us debug this: [     561.670745] Chain exists of: &hdev->lock --> sk_lock-AF_BLUETOOTH-BTPROTO_ISO --> sk_lock-AF_BLUETOOTH [     561.670751] Possible unsafe locking scenario: [ 561.670753] CPU0 CPU1 [ 561.670754] ---- ---- [     561.670756] lock(sk_lock-AF_BLUETOOTH); [ 561.670758] lock(sk_lock AF_BLUETOOTH-BTPROTO_ISO); [     561.670761] lock(sk_lock-AF_BLUETOOTH); [ 561.670764] lock(&hdev->lock); [ 561.670767] *** DEADLOCK ***     (CVE-2024-54191)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix implicit ODP use after     free Prevent double queueing of implicit ODP mr destroy work by using __xa_cmpxchg() to make sure this is     the only time we are destroying this specific mr. Without this change, we could try to invalidate this mr     twice, which in turn could result in queuing a MR work destroy twice, and eventually the second work could     execute after the MR was freed due to the first work, causing a user after free and trace below.
    refcount_t: underflow; use-after-free. WARNING: CPU: 2 PID: 12178 at lib/refcount.c:28     refcount_warn_saturate+0x12b/0x130 Modules linked in: bonding ib_ipoib vfio_pci ip_gre geneve nf_tables     ip6_gre gre ip6_tunnel tunnel6 ipip tunnel4 ib_umad rdma_ucm mlx5_vfio_pci vfio_pci_core vfio_iommu_type1     mlx5_ib vfio ib_uverbs mlx5_core iptable_raw openvswitch nsh rpcrdma ib_iser libiscsi scsi_transport_iscsi     rdma_cm iw_cm ib_cm ib_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype     iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay zram zsmalloc fuse [last     unloaded: ib_uverbs] CPU: 2 PID: 12178 Comm: kworker/u20:5 Not tainted 6.5.0-rc1_net_next_mlx5_58c644e #1     Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org     04/01/2014 Workqueue: events_unbound free_implicit_child_mr_work [mlx5_ib] RIP:
    0010:refcount_warn_saturate+0x12b/0x130 Code: 48 c7 c7 38 95 2a 82 c6 05 bc c6 fe 00 01 e8 0c 66 aa ff 0f     0b 5b c3 48 c7 c7 e0 94 2a 82 c6 05 a7 c6 fe 00 01 e8 f5 65 aa ff <0f> 0b 5b c3 90 8b 07 3d 00 00 00 c0 74     12 83 f8 01 74 13 8d 50 ff RSP: 0018:ffff8881008e3e40 EFLAGS: 00010286 RAX: 0000000000000000 RBX:
    0000000000000000 RCX: 0000000000000027 RDX: ffff88852c91b5c8 RSI: 0000000000000001 RDI: ffff88852c91b5c0     RBP: ffff8881dacd4e00 R08: 00000000ffffffff R09: 0000000000000019 R10: 000000000000072e R11:
    0000000063666572 R12: ffff88812bfd9e00 R13: ffff8881c792d200 R14: ffff88810011c005 R15: ffff8881002099c0     FS: 0000000000000000(0000) GS:ffff88852c900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000     CR0: 0000000080050033 CR2: 00007f5694b5e000 CR3: 00000001153f6003 CR4: 0000000000370ea0 DR0:
    0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0     DR7: 0000000000000400 Call Trace: <TASK> ? refcount_warn_saturate+0x12b/0x130     free_implicit_child_mr_work+0x180/0x1b0 [mlx5_ib] process_one_work+0x1cc/0x3c0 worker_thread+0x218/0x3c0     kthread+0xc6/0xf0 ret_from_fork+0x1f/0x30 </TASK> (CVE-2025-21714)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the kernel-5.14.0-580.el9 build changelog.

  - In the Linux kernel, the following vulnerability has been resolved: ipvlan: ensure network headers are in     skb linear part syzbot found that ipvlan_process_v6_outbound() was assuming the IPv6 network header isis     present in skb->head [1] Add the needed pskb_network_may_pull() calls for both IPv4 and IPv6 handlers. [1]     BUG: KMSAN: uninit-value in __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47
    __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47 ipv6_addr_type include/net/ipv6.h:555 [inline]     ip6_route_output_flags_noref net/ipv6/route.c:2616 [inline] ip6_route_output_flags+0x51/0x720     net/ipv6/route.c:2651 ip6_route_output include/net/ip6_route.h:93 [inline]     ipvlan_route_v6_outbound+0x24e/0x520 drivers/net/ipvlan/ipvlan_core.c:476 ipvlan_process_v6_outbound     drivers/net/ipvlan/ipvlan_core.c:491 [inline] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:541     [inline] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:605 [inline] ipvlan_queue_xmit+0xd72/0x1780     drivers/net/ipvlan/ipvlan_core.c:671 ipvlan_start_xmit+0x5b/0x210 drivers/net/ipvlan/ipvlan_main.c:223
    __netdev_start_xmit include/linux/netdevice.h:5150 [inline] netdev_start_xmit     include/linux/netdevice.h:5159 [inline] xmit_one net/core/dev.c:3735 [inline]     dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3751 sch_direct_xmit+0x399/0xd40     net/sched/sch_generic.c:343 qdisc_restart net/sched/sch_generic.c:408 [inline] __qdisc_run+0x14da/0x35d0     net/sched/sch_generic.c:416 qdisc_run+0x141/0x4d0 include/net/pkt_sched.h:127 net_tx_action+0x78b/0x940     net/core/dev.c:5484 handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561 __do_softirq+0x14/0x1a     kernel/softirq.c:595 do_softirq+0x9a/0x100 kernel/softirq.c:462 __local_bh_enable_ip+0x9f/0xb0     kernel/softirq.c:389 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh     include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4611 dev_queue_xmit     include/linux/netdevice.h:3311 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd     net/packet/af_packet.c:3132 [inline] packet_sendmsg+0x93e0/0xa7e0 net/packet/af_packet.c:3164     sock_sendmsg_nosec net/socket.c:718 [inline] (CVE-2025-21891)

  - In the Linux kernel, the following vulnerability has been resolved: ima: Fix potential memory leak in     ima_init_crypto() On failure to allocate the SHA1 tfm, IMA fails to initialize and exits without freeing     the ima_algo_array. Add the missing kfree() for ima_algo_array to avoid the potential memory leak.
    (CVE-2022-49627)

  - In the Linux kernel, the following vulnerability has been resolved: pfifo_tail_enqueue: Drop new packet     when sch->limit == 0 Expected behaviour: In case we reach scheduler's limit, pfifo_tail_enqueue() will     drop a packet in scheduler's queue and decrease scheduler's qlen by one. Then, pfifo_tail_enqueue()     enqueue new packet and increase scheduler's qlen by one. Finally, pfifo_tail_enqueue() return     `NET_XMIT_CN` status code. Weird behaviour: In case we set `sch->limit == 0` and trigger     pfifo_tail_enqueue() on a scheduler that has no packet, the 'drop a packet' step will do nothing. This     means the scheduler's qlen still has value equal 0. Then, we continue to enqueue new packet and increase     scheduler's qlen by one. In summary, we can leverage pfifo_tail_enqueue() to increase qlen by one and     return `NET_XMIT_CN` status code. The problem is: Let's say we have two qdiscs: Qdisc_A and Qdisc_B. -     Qdisc_A's type must have '->graft()' function to create parent/child relationship. Let's say Qdisc_A's     type is `hfsc`. Enqueue packet to this qdisc will trigger `hfsc_enqueue`. - Qdisc_B's type is     pfifo_head_drop. Enqueue packet to this qdisc will trigger `pfifo_tail_enqueue`. - Qdisc_B is configured     to have `sch->limit == 0`. - Qdisc_A is configured to route the enqueued's packet to Qdisc_B. Enqueue     packet through Qdisc_A will lead to: - hfsc_enqueue(Qdisc_A) -> pfifo_tail_enqueue(Qdisc_B) -     Qdisc_B->q.qlen += 1 - pfifo_tail_enqueue() return `NET_XMIT_CN` - hfsc_enqueue() check for     `NET_XMIT_SUCCESS` and see `NET_XMIT_CN` => hfsc_enqueue() don't increase qlen of Qdisc_A. The whole     process lead to a situation where Qdisc_A->q.qlen == 0 and Qdisc_B->q.qlen == 1. Replace 'hfsc' with other     type (for example: 'drr') still lead to the same problem. This violate the design where parent's qlen     should equal to the sum of its childrens'qlen. Bug impact: This issue can be used for user->kernel     privilege escalation when it is reachable. (CVE-2025-21702)

  - In the Linux kernel, the following vulnerability has been resolved: ipv6: use RCU protection in     ip6_default_advmss() ip6_default_advmss() needs rcu protection to make sure the net structure it reads     does not disappear. (CVE-2025-21765)

  - In the Linux kernel, the following vulnerability has been resolved: vxlan: check vxlan_vnigroup_init()     return value vxlan_init() must check vxlan_vnigroup_init() success otherwise a crash happens later,     spotted by syzbot. Oops: general protection fault, probably for non-canonical address 0xdffffc000000002c:
    0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000160-0x0000000000000167]     CPU: 0 UID: 0 PID: 7313 Comm: syz-executor147 Not tainted 6.14.0-rc1-syzkaller-00276-g69b54314c975 #0     Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP:
    0010:vxlan_vnigroup_uninit+0x89/0x500 drivers/net/vxlan/vxlan_vnifilter.c:912 Code: 00 48 8b 44 24 08 4c     8b b0 98 41 00 00 49 8d 86 60 01 00 00 48 89 c2 48 89 44 24 10 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03     <80> 3c 02 00 0f 85 4d 04 00 00 49 8b 86 60 01 00 00 48 ba 00 00 00 RSP: 0018:ffffc9000cc1eea8 EFLAGS:
    00010202 RAX: dffffc0000000000 RBX: 0000000000000001 RCX: ffffffff8672effb RDX: 000000000000002c RSI:
    ffffffff8672ecb9 RDI: ffff8880461b4f18 RBP: ffff8880461b4ef4 R08: 0000000000000001 R09: 0000000000000000     R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000020000 R13: ffff8880461b0d80 R14:
    0000000000000000 R15: dffffc0000000000 FS: 00007fecfa95d6c0(0000) GS:ffff88806a600000(0000)     knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fecfa95cfb8 CR3:
    000000004472c000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000     DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK>     vxlan_uninit+0x1ab/0x200 drivers/net/vxlan/vxlan_core.c:2942     unregister_netdevice_many_notify+0x12d6/0x1f30 net/core/dev.c:11824 unregister_netdevice_many     net/core/dev.c:11866 [inline] unregister_netdevice_queue+0x307/0x3f0 net/core/dev.c:11736     register_netdevice+0x1829/0x1eb0 net/core/dev.c:10901 __vxlan_dev_create+0x7c6/0xa30     drivers/net/vxlan/vxlan_core.c:3981 vxlan_newlink+0xd1/0x130 drivers/net/vxlan/vxlan_core.c:4407     rtnl_newlink_create net/core/rtnetlink.c:3795 [inline] __rtnl_newlink net/core/rtnetlink.c:3906 [inline]     (CVE-2025-21790)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the kernel-5.14.0-578.el9 build changelog.

  - In the Linux kernel, the following vulnerability has been resolved: soc: qcom: socinfo: Avoid out of     bounds read of serial number On MSM8916 devices, the serial number exposed in sysfs is constant and does     not change across individual devices. It's always: db410c:/sys/devices/soc0$ cat serial_number 2644893864     The firmware used on MSM8916 exposes SOCINFO_VERSION(0, 8), which does not have support for the serial_num     field in the socinfo struct. There is an existing check to avoid exposing the serial number in that case,     but it's not correct: When checking the item_size returned by SMEM, we need to make sure the *end* of the     serial_num is within bounds, instead of comparing with the *start* offset. The serial_number currently     exposed on MSM8916 devices is just an out of bounds read of whatever comes after the socinfo struct in     SMEM. Fix this by changing offsetof() to offsetofend(), so that the size of the field is also taken into     account. (CVE-2024-58007)

  - In the Linux kernel, the following vulnerability has been resolved: padata: avoid UAF for reorder_work     Although the previous patch can avoid ps and ps UAF for _do_serial, it can not avoid potential UAF issue     for reorder_work. This issue can happen just as below: crypto_request crypto_request crypto_del_alg     padata_do_serial ... padata_reorder // processes all remaining // requests then breaks while (1) { if     (!padata) break; ... } padata_do_serial // new request added list_add // sees the new request     queue_work(reorder_work) padata_reorder queue_work_on(squeue->work) ... <kworker context>     padata_serial_worker // completes new request, // no more outstanding // requests crypto_del_alg // free     pd <kworker context> invoke_padata_reorder // UAF of pd To avoid UAF for 'reorder_work', get 'pd' ref     before put 'reorder_work' into the 'serial_wq' and put 'pd' ref until the 'serial_wq' finish.
    (CVE-2025-21726)

  - In the Linux kernel, the following vulnerability has been resolved: nfsd: clear acl_access/acl_default     after releasing them If getting acl_default fails, acl_access and acl_default will be released     simultaneously. However, acl_access will still retain a pointer pointing to the released posix_acl, which     will trigger a WARNING in nfs3svc_release_getacl like this: ------------[ cut here ]------------     refcount_t: underflow; use-after-free. WARNING: CPU: 26 PID: 3199 at lib/refcount.c:28     refcount_warn_saturate+0xb5/0x170 Modules linked in: CPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted     6.12.0-rc6-00079-g04ae226af01f-dirty #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS     1.16.1-2.fc37 04/01/2014 RIP: 0010:refcount_warn_saturate+0xb5/0x170 Code: cc cc 0f b6 1d b3 20 a5 03 80     fb 01 0f 87 65 48 d8 00 83 e3 01 75 e4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff <0f> 0b eb     cd 0f b6 1d 8a3 RSP: 0018:ffffc90008637cd8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000     RCX: ffffffff83904fde RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380 RBP:
    ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56 R10: ffffc90008637ab7 R11: 0000000000000001     R12: 0000000000000001 R13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0 FS:
    0000000000000000(0000) GS:ffff88871ed00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 CR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0 DR0: 0000000000000000     DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
    0000000000000400 Call Trace: <TASK> ? refcount_warn_saturate+0xb5/0x170 ? __warn+0xa5/0x140 ?     refcount_warn_saturate+0xb5/0x170 ? report_bug+0x1b1/0x1e0 ? handle_bug+0x53/0xa0 ?     exc_invalid_op+0x17/0x40 ? asm_exc_invalid_op+0x1a/0x20 ? tick_nohz_tick_stopped+0x1e/0x40 ?     refcount_warn_saturate+0xb5/0x170 ? refcount_warn_saturate+0xb5/0x170 nfs3svc_release_getacl+0xc9/0xe0     svc_process_common+0x5db/0xb60 ? __pfx_svc_process_common+0x10/0x10 ? __rcu_read_unlock+0x69/0xa0 ?
    __pfx_nfsd_dispatch+0x10/0x10 ? svc_xprt_received+0xa1/0x120 ? xdr_init_decode+0x11d/0x190     svc_process+0x2a7/0x330 svc_handle_xprt+0x69d/0x940 svc_recv+0x180/0x2d0 nfsd+0x168/0x200 ?
    __pfx_nfsd+0x10/0x10 kthread+0x1a2/0x1e0 ? kthread+0xf4/0x1e0 ? __pfx_kthread+0x10/0x10     ret_from_fork+0x34/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Kernel panic - not     syncing: kernel: panic_on_warn set ... Clear acl_access/acl_default after posix_acl_release is called to     prevent UAF from being triggered. (CVE-2025-21796)

  - In the Linux kernel, the following vulnerability has been resolved: tcp: drop secpath at the same time as     we currently drop dst Xiumei reported hitting the WARN in xfrm6_tunnel_net_exit while running tests that     boil down to: - create a pair of netns - run a basic TCP test over ipcomp6 - delete the pair of netns The     xfrm_state found on spi_byaddr was not deleted at the time we delete the netns, because we still have a     reference on it. This lingering reference comes from a secpath (which holds a ref on the xfrm_state),     which is still attached to an skb. This skb is not leaked, it ends up on sk_receive_queue and then gets     defer-free'd by skb_attempt_defer_free. The problem happens when we defer freeing an skb (push it on one     CPU's defer_list), and don't flush that list before the netns is deleted. In that case, we still have a     reference on the xfrm_state that we don't expect at this point. We already drop the skb's dst in the TCP     receive path when it's no longer needed, so let's also drop the secpath. At this point, tcp_filter has     already called into the LSM hooks that may require the secpath, so it should not be needed anymore.
    However, in some of those places, the MPTCP extension has just been attached to the skb, so we cannot     simply drop all extensions. (CVE-2025-21864)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the kernel-5.14.0-575.el9 build changelog.

  - In the Linux kernel, the following vulnerability has been resolved: vrf: use RCU protection in     l3mdev_l3_out() l3mdev_l3_out() can be called without RCU being held: raw_sendmsg()     ip_push_pending_frames() ip_send_skb() ip_local_out() __ip_local_out() l3mdev_ip_out() Add rcu_read_lock()     / rcu_read_unlock() pair to avoid a potential UAF. (CVE-2025-21791)

  - In the Linux kernel, the following vulnerability has been resolved: tpm: Change to kvalloc() in     eventlog/acpi.c The following failure was reported on HPE ProLiant D320: [ 10.693310][ T1] tpm_tis     STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0) [ 10.848132][ T1] ------------[ cut here ]------------ [     10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330 [     10.862827][ T1] Modules linked in: [ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted     6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased)     588cd98293a7c9eba9013378d807364c088c9375 [ 10.882741][ T1] Hardware name: HPE ProLiant DL320     Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024 [ 10.892170][ T1] RIP:
    0010:__alloc_pages_noprof+0x2ca/0x330 [ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe     ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe     ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1 [ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246 [     10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000 [ 10.931727][ T1] RDX:
    0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0 The above transcript shows that ACPI pointed     a 16 MiB buffer for the log events because RSI maps to the 'order' parameter of __alloc_pages_noprof().
    Address the bug by moving from devm_kmalloc() to devm_add_action() and kvmalloc() and devm_add_action().
    (CVE-2024-58005)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the kernel-5.14.0-573.el9 build changelog.

  - In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Fix slab-use-after-free read     in sg_release() Fix a use-after-free bug in sg_release(), detected by syzbot with KASAN: BUG: KASAN: slab-     use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5838
    __mutex_unlock_slowpath+0xe2/0x750 kernel/locking/mutex.c:912 sg_release+0x1f4/0x2e0 drivers/scsi/sg.c:407     In sg_release(), the function kref_put(&sfp->f_ref, sg_remove_sfp) is called before releasing the     open_rel_lock mutex. The kref_put() call may decrement the reference count of sfp to zero, triggering its     cleanup through sg_remove_sfp(). This cleanup includes scheduling deferred work via     sg_remove_sfp_usercontext(), which ultimately frees sfp. After kref_put(), sg_release() continues to     unlock open_rel_lock and may reference sfp or sdp. If sfp has already been freed, this results in a slab-     use-after-free error. Move the kref_put(&sfp->f_ref, sg_remove_sfp) call after unlocking the open_rel_lock     mutex. This ensures: - No references to sfp or sdp occur after the reference count is decremented. -     Cleanup functions such as sg_remove_sfp() and sg_remove_sfp_usercontext() can safely execute without     impacting the mutex handling in sg_release(). The fix has been tested and validated by syzbot. This patch     closes the bug reported at the following syzkaller link and ensures proper sequencing of resource cleanup     and mutex operations, eliminating the risk of use-after-free errors in sg_release(). (CVE-2024-56631)

  - In the Linux kernel, the following vulnerability has been resolved: can: isotp: sanitize CAN ID checks in     isotp_bind() Syzbot created an environment that lead to a state machine status that can not be reached     with a compliant CAN ID address configuration. The provided address information consisted of CAN ID     0x6000001 and 0xC28001 which both boil down to 11 bit CAN IDs 0x001 in sending and receiving. Sanitize the     SFF/EFF CAN ID values before performing the address checks. (CVE-2022-49269)

  - In the Linux kernel, the following vulnerability has been resolved: can: bcm: Fix UAF in bcm_proc_show()     BUG: KASAN: slab-use-after-free in bcm_proc_show+0x969/0xa80 Read of size 8 at addr ffff888155846230 by     task cat/7862 CPU: 1 PID: 7862 Comm: cat Not tainted 6.5.0-rc1-00153-gc8746099c197 #230 Hardware name:
    QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK>     dump_stack_lvl+0xd5/0x150 print_report+0xc1/0x5e0 kasan_report+0xba/0xf0 bcm_proc_show+0x969/0xa80     seq_read_iter+0x4f6/0x1260 seq_read+0x165/0x210 proc_reg_read+0x227/0x300 vfs_read+0x1d5/0x8d0     ksys_read+0x11e/0x240 do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd Allocated by task     7846: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x9e/0xa0     bcm_sendmsg+0x264b/0x44e0 sock_sendmsg+0xda/0x180 ____sys_sendmsg+0x735/0x920 ___sys_sendmsg+0x11d/0x1b0
    __sys_sendmsg+0xfa/0x1d0 do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd Freed by task     7846: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x27/0x40
    ____kasan_slab_free+0x161/0x1c0 slab_free_freelist_hook+0x119/0x220 __kmem_cache_free+0xb4/0x2e0     rcu_core+0x809/0x1bd0 bcm_op is freed before procfs entry be removed in bcm_release(), this lead to     bcm_proc_show() may read the freed bcm_op. (CVE-2023-52922)

  - In the Linux kernel, the following vulnerability has been resolved: x86/xen: don't do PV iret hypercall     through hypercall page Instead of jumping to the Xen hypercall page for doing the iret hypercall, directly     code the required sequence in xen-asm.S. This is done in preparation of no longer using hypercall page at     all, as it has shown to cause problems with speculation mitigations. This is part of XSA-466 /     CVE-2024-53241. (CVE-2024-53241)

  - In the Linux kernel, the following vulnerability has been resolved: scsi: megaraid_sas: Fix for a     potential deadlock This fixes a 'possible circular locking dependency detected' warning CPU0 CPU1 ----
    ---- lock(&instance->reset_mutex); lock(&shost->scan_mutex); lock(&instance->reset_mutex);
    lock(&shost->scan_mutex); Fix this by temporarily releasing the reset_mutex. (CVE-2024-57807)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the kernel-5.14.0-572.el9 build changelog.

  - In the Linux kernel, the following vulnerability has been resolved: arm64: cacheinfo: Avoid out-of-bounds     write to cacheinfo array The loop that detects/populates cache information already has a bounds check on     the array size but does not account for cache levels with separate data/instructions cache. Fix this by     incrementing the index for any populated leaf (instead of any populated level). (CVE-2025-21785)

  - In the Linux kernel, the following vulnerability has been resolved: powerpc/xive/spapr: correct bitmap     allocation size kasan detects access beyond the end of the xibm->bitmap allocation: BUG: KASAN: slab-out-     of-bounds in _find_first_zero_bit+0x40/0x140 Read of size 8 at addr c00000001d1d0118 by task swapper/0/1     CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc2-00001-g90df023b36dd #28 Call Trace:
    [c00000001d98f770] [c0000000012baab8] dump_stack_lvl+0xac/0x108 (unreliable) [c00000001d98f7b0]     [c00000000068faac] print_report+0x37c/0x710 [c00000001d98f880] [c0000000006902c0] kasan_report+0x110/0x354     [c00000001d98f950] [c000000000692324] __asan_load8+0xa4/0xe0 [c00000001d98f970] [c0000000011c6ed0]
    _find_first_zero_bit+0x40/0x140 [c00000001d98f9b0] [c0000000000dbfbc] xive_spapr_get_ipi+0xcc/0x260     [c00000001d98fa70] [c0000000000d6d28] xive_setup_cpu_ipi+0x1e8/0x450 [c00000001d98fb30] [c000000004032a20]     pSeries_smp_probe+0x5c/0x118 [c00000001d98fb60] [c000000004018b44] smp_prepare_cpus+0x944/0x9ac     [c00000001d98fc90] [c000000004009f9c] kernel_init_freeable+0x2d4/0x640 [c00000001d98fd90]     [c0000000000131e8] kernel_init+0x28/0x1d0 [c00000001d98fe10] [c00000000000cd54]     ret_from_kernel_thread+0x5c/0x64 Allocated by task 0: kasan_save_stack+0x34/0x70 __kasan_kmalloc+0xb4/0xf0
    __kmalloc+0x268/0x540 xive_spapr_init+0x4d0/0x77c pseries_init_irq+0x40/0x27c init_IRQ+0x44/0x84     start_kernel+0x2a4/0x538 start_here_common+0x1c/0x20 The buggy address belongs to the object at     c00000001d1d0118 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes     inside of 8-byte region [c00000001d1d0118, c00000001d1d0120) The buggy address belongs to the physical     page: page:c00c000000074740 refcount:1 mapcount:0 mapping:0000000000000000 index:0xc00000001d1d0558     pfn:0x1d1d flags: 0x7ffff000000200(slab|node=0|zone=0|lastcpupid=0x7ffff) raw: 007ffff000000200     c00000001d0003c8 c00000001d0003c8 c00000001d010480 raw: c00000001d1d0558 0000000001e1000a 00000001ffffffff     0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address:
    c00000001d1d0000: fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0080: fc fc 00 fc fc fc fc     fc fc fc fc fc fc fc fc fc >c00000001d1d0100: fc fc fc 02 fc fc fc fc fc fc fc fc fc fc fc fc ^     c00000001d1d0180: fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0200: fc fc fc fc fc 04 fc     fc fc fc fc fc fc fc fc fc This happens because the allocation uses the wrong unit (bits) when it should     pass (BITS_TO_LONGS(count) * sizeof(long)) or equivalent. With small numbers of bits, the allocated object     can be smaller than sizeof(long), which results in invalid accesses. Use bitmap_zalloc() to allocate and     initialize the irq bitmap, paired with bitmap_free() for consistency. (CVE-2022-49623)

  - In the Linux kernel, the following vulnerability has been resolved: soc: qcom: cmd-db: Map shared memory     as WC, not WB Linux does not write into cmd-db region. This region of memory is write protected by XPU.
    XPU may sometime falsely detect clean cache eviction as write into the write protected region leading to     secure interrupt which causes an endless loop somewhere in Trust Zone. The only reason it is working right     now is because Qualcomm Hypervisor maps the same region as Non-Cacheable memory in Stage 2 translation     tables. The issue manifests if we want to use another hypervisor (like Xen or KVM), which does not know     anything about those specific mappings. Changing the mapping of cmd-db memory from MEMREMAP_WB to     MEMREMAP_WT/WC removes dependency on correct mappings in Stage 2 tables. This patch fixes the issue by     updating the mapping to MEMREMAP_WC. I tested this on SA8155P with Xen. (CVE-2024-46689)

  - In the Linux kernel, the following vulnerability has been resolved: io_uring: check if we need to     reschedule during overflow flush In terms of normal application usage, this list will always be empty. And     if an application does overflow a bit, it'll have a few entries. However, nothing obviously prevents     syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take     quite a while. Check for needing to reschedule while flushing, and drop our locks and do so if necessary.
    There's no state to maintain here as overflows always prune from head-of-list, hence it's fine to drop and     reacquire the locks at the end of the loop. (CVE-2024-50060)

  - In the Linux kernel, the following vulnerability has been resolved: io_uring/rw: fix missing NOWAIT check     for O_DIRECT start write When io_uring starts a write, it'll call kiocb_start_write() to bump the super     block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will     grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to     finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently     attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes     to complete, but the previous writes cannot complete, as the task that is supposed to complete them is     blocked waiting on starting a new write. This results in the following stuck trace showing that dependency     with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call     trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8
    __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110
    __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238     do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO:
    task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with     the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364     ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0     percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18
    __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238     do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this     by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem     if it isn't set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will     have io_uring core issue a blocking attempt of the write. That will in turn also get completions run,     ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn't something     that can be triggered by a regular user. (CVE-2024-53052)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 9 host has packages installed that are affected by a vulnerability as referenced in the libxml2-2.9.13-9.el9 build changelog.

  - libxml2 before 2.12.10 and 2.13.x before 2.13.6 has a stack-based buffer overflow in xmlSnprintfElements     in valid.c. To exploit this, DTD validation must occur for an untrusted document or untrusted DTD. NOTE:
    this is similar to CVE-2017-9047. (CVE-2025-24928)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 9 host has a package installed that is affected by multiple vulnerabilities as referenced in the microcode_ctl-20250211-1.el9 build changelog.

  - Improper input validation in UEFI firmware for some Intel(R) processors may allow a privileged user to     potentially enable escalation of privilege via local access. (CVE-2023-43758)

  - Improper input validation in UEFI firmware for some Intel(R) Processors may allow a privileged user to     potentially enable escalation of privilege via local access. (CVE-2023-34440, CVE-2024-28127)

  - Improper input validation in XmlCli feature for UEFI firmware for some Intel(R) processors may allow     privileged user to potentially enable escalation of privilege via local access. (CVE-2024-24582)

  - Improper input validation in UEFI firmware for some Intel(R) Processors may allow a privileged user to     potentially enable information disclosure via local access. (CVE-2024-28047)

  - Improper input validation in UEFI firmware CseVariableStorageSmm for some Intel(R) Processors may allow a     privileged user to potentially enable escalation of privilege via local access. (CVE-2024-29214)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 9 host has packages installed that are affected by a vulnerability as referenced in the openssh-8.7p1-45.el9 build changelog.

  - A vulnerability was found in OpenSSH when the VerifyHostKeyDNS option is enabled. A machine-in-the-middle     attack can be performed by a malicious machine impersonating a legit server. This issue occurs due to how     OpenSSH mishandles error codes in specific conditions when verifying the host key. For an attack to be     considered successful, the attacker needs to manage to exhaust the client's memory resource first, turning     the attack complexity high. (CVE-2025-26465)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 9 host has packages installed that are affected by a vulnerability as referenced in the gcc-11.5.0-5.el9 build changelog.

  - In jQuery versions greater than or equal to 1.0.3 and before 3.5.0, passing HTML containing <option>     elements from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods     (i.e. .html(), .append(), and others) may execute untrusted code. This problem is patched in jQuery 3.5.0.
    (CVE-2020-11023)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the kernel-5.14.0-565.el9 build changelog.

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btmtk: avoid UAF in     btmtk_process_coredump hci_devcd_append may lead to the release of the skb, so it cannot be accessed once     it is called. ================================================================== BUG: KASAN: slab-use-     after-free in btmtk_process_coredump+0x2a7/0x2d0 [btmtk] Read of size 4 at addr ffff888033cfabb0 by task     kworker/0:3/82 CPU: 0 PID: 82 Comm: kworker/0:3 Tainted: G U 6.6.40-lockdep-03464-g1d8b4eb3060e #1     b0b3c1cc0c842735643fb411799d97921d1f688c Hardware name: Google Yaviks_Ufs/Yaviks_Ufs, BIOS     Google_Yaviks_Ufs.15217.552.0 05/07/2024 Workqueue: events btusb_rx_work [btusb] Call Trace: <TASK>     dump_stack_lvl+0xfd/0x150 print_report+0x131/0x780 kasan_report+0x177/0x1c0     btmtk_process_coredump+0x2a7/0x2d0 [btmtk 03edd567dd71a65958807c95a65db31d433e1d01]     btusb_recv_acl_mtk+0x11c/0x1a0 [btusb 675430d1e87c4f24d0c1f80efe600757a0f32bec] btusb_rx_work+0x9e/0xe0     [btusb 675430d1e87c4f24d0c1f80efe600757a0f32bec] worker_thread+0xe44/0x2cc0 kthread+0x2ff/0x3a0     ret_from_fork+0x51/0x80 ret_from_fork_asm+0x1b/0x30 </TASK> Allocated by task 82:
    stack_trace_save+0xdc/0x190 kasan_set_track+0x4e/0x80 __kasan_slab_alloc+0x4e/0x60     kmem_cache_alloc+0x19f/0x360 skb_clone+0x132/0xf70 btusb_recv_acl_mtk+0x104/0x1a0 [btusb]     btusb_rx_work+0x9e/0xe0 [btusb] worker_thread+0xe44/0x2cc0 kthread+0x2ff/0x3a0 ret_from_fork+0x51/0x80     ret_from_fork_asm+0x1b/0x30 Freed by task 1733: stack_trace_save+0xdc/0x190 kasan_set_track+0x4e/0x80     kasan_save_free_info+0x28/0xb0 ____kasan_slab_free+0xfd/0x170 kmem_cache_free+0x183/0x3f0     hci_devcd_rx+0x91a/0x2060 [bluetooth] worker_thread+0xe44/0x2cc0 kthread+0x2ff/0x3a0     ret_from_fork+0x51/0x80 ret_from_fork_asm+0x1b/0x30 The buggy address belongs to the object at     ffff888033cfab40 which belongs to the cache skbuff_head_cache of size 232 The buggy address is located 112     bytes inside of freed 232-byte region [ffff888033cfab40, ffff888033cfac28) The buggy address belongs to     the physical page: page:00000000a174ba93 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0     pfn:0x33cfa head:00000000a174ba93 order:1 entire_mapcount:0 nr_pages_mapped:0 pincount:0 anon flags:
    0x4000000000000840(slab|head|zone=1) page_type: 0xffffffff() raw: 4000000000000840 ffff888100848a00     0000000000000000 0000000000000001 raw: 0000000000000000 0000000080190019 00000001ffffffff 0000000000000000     page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888033cfaa80:
    fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc ffff888033cfab00: fc fc fc fc fc fc fc fc fa fb fb fb fb     fb fb fb >ffff888033cfab80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888033cfac00: fb fb fb     fb fb fc fc fc fc fc fc fc fc fc fc fc ffff888033cfac80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb     ================================================================== Check if we need to call     hci_devcd_complete before calling hci_devcd_append. That requires that we check data->cd_info.cnt >=     MTK_COREDUMP_NUM instead of data->cd_info.cnt > MTK_COREDUMP_NUM, as we increment data->cd_info.cnt only     once the call to hci_devcd_append succeeds. (CVE-2024-56653)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix slab-use-after-     free Read in set_powered_sync This fixes the following crash:
    ================================================================== BUG: KASAN: slab-use-after-free in     set_powered_sync+0x3a/0xc0 net/bluetooth/mgmt.c:1353 Read of size 8 at addr ffff888029b4dd18 by task     kworker/u9:0/54 CPU: 1 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted     6.11.0-rc6-syzkaller-01155-gf723224742fc #0 Hardware name: Google Google Compute Engine/Google Compute     Engine, BIOS Google 08/06/2024 Workqueue: hci0 hci_cmd_sync_work Call Trace: <TASK> __dump_stack     lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description     mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 q kasan_report+0x143/0x180     mm/kasan/report.c:601 set_powered_sync+0x3a/0xc0 net/bluetooth/mgmt.c:1353 hci_cmd_sync_work+0x22b/0x400     net/bluetooth/hci_sync.c:328 process_one_work kernel/workqueue.c:3231 [inline]     process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd10     kernel/workqueue.c:3389 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80     arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Allocated     by task 5247: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80     mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:370 [inline] __kasan_kmalloc+0x98/0xb0     mm/kasan/common.c:387 kasan_kmalloc include/linux/kasan.h:211 [inline] __kmalloc_cache_noprof+0x19c/0x2c0     mm/slub.c:4193 kmalloc_noprof include/linux/slab.h:681 [inline] kzalloc_noprof include/linux/slab.h:807     [inline] mgmt_pending_new+0x65/0x250 net/bluetooth/mgmt_util.c:269 mgmt_pending_add+0x36/0x120     net/bluetooth/mgmt_util.c:296 set_powered+0x3cd/0x5e0 net/bluetooth/mgmt.c:1394 hci_mgmt_cmd+0xc47/0x11d0     net/bluetooth/hci_sock.c:1712 hci_sock_sendmsg+0x7b8/0x11c0 net/bluetooth/hci_sock.c:1832     sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745     sock_write_iter+0x2dd/0x400 net/socket.c:1160 new_sync_write fs/read_write.c:497 [inline]     vfs_write+0xa72/0xc90 fs/read_write.c:590 ksys_write+0x1a0/0x2c0 fs/read_write.c:643 do_syscall_x64     arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83     entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 5246: kasan_save_stack mm/kasan/common.c:47     [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50     mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60     mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2256     [inline] slab_free mm/slub.c:4477 [inline] kfree+0x149/0x360 mm/slub.c:4598 settings_rsp+0x2bc/0x390     net/bluetooth/mgmt.c:1443 mgmt_pending_foreach+0xd1/0x130 net/bluetooth/mgmt_util.c:259
    __mgmt_power_off+0x112/0x420 net/bluetooth/mgmt.c:9455 hci_dev_close_sync+0x665/0x11a0     net/bluetooth/hci_sync.c:5191 hci_dev_do_close net/bluetooth/hci_core.c:483 [inline]     hci_dev_close+0x112/0x210 net/bluetooth/hci_core.c:508 sock_do_ioctl+0x158/0x460 net/socket.c:1222     sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907     [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline]     do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83gv entry_SYSCALL_64_after_hwframe+0x77/0x7f     (CVE-2024-53208)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix use-after-free in     device_for_each_child() Syzbot has reported the following KASAN splat: BUG: KASAN: slab-use-after-free in     device_for_each_child+0x18f/0x1a0 Read of size 8 at addr ffff88801f605308 by task kbnepd bnep0/4980 CPU: 0     UID: 0 PID: 4980 Comm: kbnepd bnep0 Not tainted 6.12.0-rc4-00161-gae90f6a6170d #1 Hardware name: QEMU     Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 Call Trace: <TASK>     dump_stack_lvl+0x100/0x190 ? device_for_each_child+0x18f/0x1a0 print_report+0x13a/0x4cb ?
    __virt_addr_valid+0x5e/0x590 ? __phys_addr+0xc6/0x150 ? device_for_each_child+0x18f/0x1a0     kasan_report+0xda/0x110 ? device_for_each_child+0x18f/0x1a0 ? __pfx_dev_memalloc_noio+0x10/0x10     device_for_each_child+0x18f/0x1a0 ? __pfx_device_for_each_child+0x10/0x10     pm_runtime_set_memalloc_noio+0xf2/0x180 netdev_unregister_kobject+0x1ed/0x270     unregister_netdevice_many_notify+0x123c/0x1d80 ? __mutex_trylock_common+0xde/0x250 ?
    __pfx_unregister_netdevice_many_notify+0x10/0x10 ? trace_contention_end+0xe6/0x140 ?
    __mutex_lock+0x4e7/0x8f0 ? __pfx_lock_acquire.part.0+0x10/0x10 ? rcu_is_watching+0x12/0xc0 ?     unregister_netdev+0x12/0x30 unregister_netdevice_queue+0x30d/0x3f0 ?
    __pfx_unregister_netdevice_queue+0x10/0x10 ? __pfx_down_write+0x10/0x10 unregister_netdev+0x1c/0x30     bnep_session+0x1fb3/0x2ab0 ? __pfx_bnep_session+0x10/0x10 ? __pfx_lock_release+0x10/0x10 ?
    __pfx_woken_wake_function+0x10/0x10 ? __kthread_parkme+0x132/0x200 ? __pfx_bnep_session+0x10/0x10 ?     kthread+0x13a/0x370 ? __pfx_bnep_session+0x10/0x10 kthread+0x2b7/0x370 ? __pfx_kthread+0x10/0x10     ret_from_fork+0x48/0x80 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task     4974: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0
    __kmalloc_noprof+0x1d1/0x440 hci_alloc_dev_priv+0x1d/0x2820 __vhci_create_device+0xef/0x7d0     vhci_write+0x2c7/0x480 vfs_write+0x6a0/0xfc0 ksys_write+0x12f/0x260 do_syscall_64+0xc7/0x250     entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 4979: kasan_save_stack+0x30/0x50     kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x4f/0x70 kfree+0x141/0x490     hci_release_dev+0x4d9/0x600 bt_host_release+0x6a/0xb0 device_release+0xa4/0x240 kobject_put+0x1ec/0x5a0     put_device+0x1f/0x30 vhci_release+0x81/0xf0 __fput+0x3f6/0xb30 task_work_run+0x151/0x250     do_exit+0xa79/0x2c30 do_group_exit+0xd5/0x2a0 get_signal+0x1fcd/0x2210     arch_do_signal_or_restart+0x93/0x780 syscall_exit_to_user_mode+0x140/0x290 do_syscall_64+0xd4/0x250     entry_SYSCALL_64_after_hwframe+0x77/0x7f In 'hci_conn_del_sysfs()', 'device_unregister()' may be called     when an underlying (kobject) reference counter is greater than 1. This means that reparenting (happened     when the device is actually freed) is delayed and, during that delay, parent controller device (hciX) may     be deleted. Since the latter may create a dangling pointer to freed parent, avoid that scenario by     reparenting to NULL explicitly. (CVE-2024-53237)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: iso: Always release hdev at     the end of iso_listen_bis Since hci_get_route holds the device before returning, the hdev should be     released with hci_dev_put at the end of iso_listen_bis even if the function returns with an error.
    (CVE-2024-57879)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the kernel-5.14.0-559.el9 build changelog.

  - In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Remove cache tags before     disabling ATS The current implementation removes cache tags after disabling ATS, leading to potential     memory leaks and kernel crashes. Specifically, CACHE_TAG_DEVTLB type cache tags may still remain in the     list even after the domain is freed, causing a use-after-free condition. This issue really shows up when     multiple VFs from different PFs passed through to a single user-space process via vfio-pci. In such cases,     the kernel may crash with kernel messages like: BUG: kernel NULL pointer dereference, address:
    0000000000000014 PGD 19036a067 P4D 1940a3067 PUD 136c9b067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI     CPU: 74 UID: 0 PID: 3183 Comm: testCli Not tainted 6.11.9 #2 RIP: 0010:cache_tag_flush_range+0x9b/0x250     Call Trace: <TASK> ? __die+0x1f/0x60 ? page_fault_oops+0x163/0x590 ? exc_page_fault+0x72/0x190 ?     asm_exc_page_fault+0x22/0x30 ? cache_tag_flush_range+0x9b/0x250 ? cache_tag_flush_range+0x5d/0x250     intel_iommu_tlb_sync+0x29/0x40 intel_iommu_unmap_pages+0xfe/0x160 __iommu_unmap+0xd8/0x1a0     vfio_unmap_unpin+0x182/0x340 [vfio_iommu_type1] vfio_remove_dma+0x2a/0xb0 [vfio_iommu_type1]     vfio_iommu_type1_ioctl+0xafa/0x18e0 [vfio_iommu_type1] Move cache_tag_unassign_domain() before     iommu_disable_pci_caps() to fix it. (CVE-2024-56669)

  - In the Linux kernel, the following vulnerability has been resolved: erofs: fix pcluster use-after-free on     UP platforms During stress testing with CONFIG_SMP disabled, KASAN reports as below:
    ================================================================== BUG: KASAN: use-after-free in
    __mutex_lock+0xe5/0xc30 Read of size 8 at addr ffff8881094223f8 by task stress/7789 CPU: 0 PID: 7789 Comm:
    stress Not tainted 6.0.0-rc1-00002-g0d53d2e882f9 #3 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 Call     Trace: <TASK> .. __mutex_lock+0xe5/0xc30 .. z_erofs_do_read_page+0x8ce/0x1560 ..
    z_erofs_readahead+0x31c/0x580 .. Freed by task 7787 kasan_save_stack+0x1e/0x40 kasan_set_track+0x20/0x30     kasan_set_free_info+0x20/0x40 __kasan_slab_free+0x10c/0x190 kmem_cache_free+0xed/0x380     rcu_core+0x3d5/0xc90 __do_softirq+0x12d/0x389 Last potentially related work creation:
    kasan_save_stack+0x1e/0x40 __kasan_record_aux_stack+0x97/0xb0 call_rcu+0x3d/0x3f0     erofs_shrink_workstation+0x11f/0x210 erofs_shrink_scan+0xdc/0x170 shrink_slab.constprop.0+0x296/0x530     drop_slab+0x1c/0x70 drop_caches_sysctl_handler+0x70/0x80 proc_sys_call_handler+0x20a/0x2f0     vfs_write+0x555/0x6c0 ksys_write+0xbe/0x160 do_syscall_64+0x3b/0x90 The root cause is that     erofs_workgroup_unfreeze() doesn't reset to orig_val thus it causes a race that the pcluster reuses     unexpectedly before freeing. Since UP platforms are quite rare now, such path becomes unnecessary. Let's     drop such specific-designed path directly instead. (CVE-2022-48674)

  - In the Linux kernel, the following vulnerability has been resolved: erofs: fix memory leak of LZMA global     compressed deduplication When stressing microLZMA EROFS images with the new global compressed     deduplication feature enabled (`-Ededupe`), I found some short-lived temporary pages weren't properly     released, which could slowly cause unexpected OOMs hours later. Let's fix it now (LZ4 and DEFLATE don't     have this issue.) (CVE-2023-52526)

  - In the Linux kernel, the following vulnerability has been resolved: iommu/s390: Implement blocking domain     This fixes a crash when surprise hot-unplugging a PCI device. This crash happens because during hot-unplug
    __iommu_group_set_domain_nofail() attaching the default domain fails when the platform no longer     recognizes the device as it has already been removed and we end up with a NULL domain pointer and UAF.
    This is exactly the case referred to in the second comment in __iommu_device_set_domain() and just as     stated there if we can instead attach the blocking domain the UAF is prevented as this can handle the     already removed device. Implement the blocking domain to use this handling. With this change, the crash is     fixed but we still hit a warning attempting to change DMA ownership on a blocked device. (CVE-2024-53232)

  - In the Linux kernel, the following vulnerability has been resolved: i3c: master: Fix miss free     init_dyn_addr at i3c_master_put_i3c_addrs() if (dev->boardinfo && dev->boardinfo->init_dyn_addr) ^^^ here     check init_dyn_addr i3c_bus_set_addr_slot_status(&master->bus, dev->info.dyn_addr, ...) ^^^^ free     dyn_addr Fix copy/paste error dyn_addr by replacing it with init_dyn_addr. (CVE-2024-56562)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the kernel-5.14.0-554.el9 build changelog.

  - In the Linux kernel, the following vulnerability has been resolved: ALSA: asihpi: Fix potential OOB array     access ASIHPI driver stores some values in the static array upon a response from the driver, and its index     depends on the firmware. We shouldn't trust it blindly. This patch adds a sanity check of the array index     to fit in the array size. (CVE-2024-50007)

  - In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Possible null     pointer dereference in cs35l41_hda_unbind() The cs35l41_hda_unbind() function clears the hda_component     entry matching it's index and then dereferences the codec pointer held in the first element of the     hda_component array, this is an issue when the device index was 0. Instead use the codec pointer stashed     in the cs35l41_hda structure as it will still be valid. (CVE-2024-40964)

  - In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: Intel: hda: fix null deref     on system suspend entry When system enters suspend with an active stream, SOF core calls     hw_params_upon_resume(). On Intel platforms with HDA DMA used to manage the link DMA, this leads to call     chain of hda_dsp_set_hw_params_upon_resume() -> hda_dsp_dais_suspend() -> hda_dai_suspend() ->     hda_ipc4_post_trigger() A bug is hit in hda_dai_suspend() as hda_link_dma_cleanup() is run first, which     clears hext_stream->link_substream, and then hda_ipc4_post_trigger() is called with a NULL     snd_pcm_substream pointer. (CVE-2024-41037)

  - In the Linux kernel, the following vulnerability has been resolved: ASoC: topology: Fix references to     freed memory Most users after parsing a topology file, release memory used by it, so having pointer     references directly into topology file contents is wrong. Use devm_kmemdup(), to allocate memory as     needed. (CVE-2024-41069)

  - In the Linux kernel, the following vulnerability has been resolved: ASoC: amd: acp: add a null check for     chip_pdev structure When acp platform device creation is skipped, chip->chip_pdev value will remain NULL.
    Add NULL check for chip->chip_pdev structure in snd_acp_resume() function to avoid null pointer     dereference. (CVE-2024-42074)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 9 host has a package installed that is affected by multiple vulnerabilities as referenced in the microcode_ctl-20241112-1.el9 build changelog.

  - Improper conditions check in some Intel(R) Xeon(R) processor memory controller configurations when using     Intel(R) SGX may allow a privileged user to potentially enable escalation of privilege via local access.
    (CVE-2024-23918)

  - Incorrect default permissions in some Intel(R) Xeon(R) processor memory controller configurations when     using Intel(R) SGX may allow a privileged user to potentially enable escalation of privilege via local     access. (CVE-2024-21820)

  - Improper finite state machines (FSMs) in the hardware logic in some 4th and 5th Generation Intel(R)     Xeon(R) Processors may allow an authorized user to potentially enable denial of service via local access.
    (CVE-2024-21853)

  - Observable discrepancy in RAPL interface for some Intel(R) Processors may allow a privileged user to     potentially enable information disclosure via local access. (CVE-2024-23984)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the kernel-5.14.0-547.el9 build changelog.

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink: Initialise     extack before use in ACKs Add missing extack initialisation when ACKing BATCH_BEGIN and BATCH_END.
    (CVE-2024-44945)

  - In the Linux kernel, the following vulnerability has been resolved: net: fix crash when config small     gso_max_size/gso_ipv4_max_size Config a small gso_max_size/gso_ipv4_max_size will lead to an underflow in     sk_dst_gso_max_size(), which may trigger a BUG_ON crash, because sk->sk_gso_max_size would be much bigger     than device limits. Call Trace: tcp_write_xmit tso_segs = tcp_init_tso_segs(skb, mss_now);
    tcp_set_skb_tso_segs tcp_skb_pcount_set // skb->len = 524288, mss_now = 8 // u16 tso_segs = 524288/8 =     65535 -> 0 tso_segs = DIV_ROUND_UP(skb->len, mss_now) BUG_ON(!tso_segs) Add check for the minimum value of     gso_max_size and gso_ipv4_max_size. (CVE-2024-50258)

  - In the Linux kernel, the following vulnerability has been resolved: mm: resolve faulty mmap_region() error     path behaviour The mmap_region() function is somewhat terrifying, with spaghetti-like control flow and     numerous means by which issues can arise and incomplete state, memory leaks and other unpleasantness can     occur. A large amount of the complexity arises from trying to handle errors late in the process of mapping     a VMA, which forms the basis of recently observed issues with resource leaks and observable inconsistent     state. Taking advantage of previous patches in this series we move a number of checks earlier in the code,     simplifying things by moving the core of the logic into a static internal function __mmap_region(). Doing     this allows us to perform a number of checks up front before we do any real work, and allows us to unwind     the writable unmap check unconditionally as required and to perform a CONFIG_DEBUG_VM_MAPLE_TREE     validation unconditionally also. We move a number of things here: 1. We preallocate memory for the     iterator before we call the file-backed memory hook, allowing us to exit early and avoid having to perform     complicated and error-prone close/free logic. We carefully free iterator state on both success and error     paths. 2. The enclosing mmap_region() function handles the mapping_map_writable() logic early. Previously     the logic had the mapping_map_writable() at the point of mapping a newly allocated file-backed VMA, and a     matching mapping_unmap_writable() on success and error paths. We now do this unconditionally if this is a     file-backed, shared writable mapping. If a driver changes the flags to eliminate VM_MAYWRITE, however     doing so does not invalidate the seal check we just performed, and we in any case always decrement the     counter in the wrapper. We perform a debug assert to ensure a driver does not attempt to do the opposite.
    3. We also move arch_validate_flags() up into the mmap_region() function. This is only relevant on arm64     and sparc64, and the check is only meaningful for SPARC with ADI enabled. We explicitly add a warning for     this arch if a driver invalidates this check, though the code ought eventually to be fixed to eliminate     the need for this. With all of these measures in place, we no longer need to explicitly close the VMA on     error paths, as we place all checks which might fail prior to a call to any driver mmap hook. This     eliminates an entire class of errors, makes the code easier to reason about and more robust.
    (CVE-2024-53096)

  - In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Skip parsing frames     of type UVC_VS_UNDEFINED in uvc_parse_format This can lead to out of bounds writes since frames of this     type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming.
    (CVE-2024-53104)

  - In the Linux kernel, the following vulnerability has been resolved: mm: fix NULL pointer dereference in     alloc_pages_bulk_noprof We triggered a NULL pointer dereference for ac.preferred_zoneref->zone in     alloc_pages_bulk_noprof() when the task is migrated between cpusets. When cpuset is enabled, in     prepare_alloc_pages(), ac->nodemask may be t->mems_allowed. when first_zones_zonelist() is called     to find preferred_zoneref, the ac->nodemask may be modified concurrently if the task is migrated between     different cpusets. Assuming we have 2 NUMA Node, when traversing Node1 in ac->zonelist, the nodemask is 2,     and when traversing Node2 in ac->zonelist, the nodemask is 1. As a result, the ac->preferred_zoneref     points to NULL zone. In alloc_pages_bulk_noprof(), for_each_zone_zonelist_nodemask() finds a allowable     zone and calls zonelist_node_idx(ac.preferred_zoneref), leading to NULL pointer dereference.
    __alloc_pages_noprof() fixes this issue by checking NULL pointer in commit ea57485af8f4 (mm, page_alloc:
    fix check for NULL preferred_zone) and commit df76cee6bbeb (mm, page_alloc: remove redundant checks from     alloc fastpath). To fix it, check NULL pointer for preferred_zoneref->zone. (CVE-2024-53113)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the kernel-5.14.0-542.el9 build changelog.

  - In the Linux kernel, the following vulnerability has been resolved: nfsd: cancel nfsd_shrinker_work using     sync mode in nfs4_state_shutdown_net In the normal case, when we excute `echo 0 > /proc/fs/nfsd/threads`,     the function `nfs4_state_destroy_net` in `nfs4_state_shutdown_net` will release all resources related to     the hashed `nfs4_client`. If the `nfsd_client_shrinker` is running concurrently, the `expire_client`     function will first unhash this client and then destroy it. This can lead to the following warning.
    Additionally, numerous use-after-free errors may occur as well. nfsd_client_shrinker echo 0 >     /proc/fs/nfsd/threads expire_client nfsd_shutdown_net unhash_client ... nfs4_state_shutdown_net /* won't     wait shrinker exit */ /* cancel_work(&nn->nfsd_shrinker_work) * nfsd_file for this /* won't destroy     unhashed client1 */ * client1 still alive nfs4_state_destroy_net */ nfsd_file_cache_shutdown /* trigger     warning */ kmem_cache_destroy(nfsd_file_slab) kmem_cache_destroy(nfsd_file_mark_slab) /* release nfsd_file     and mark */ __destroy_client ==================================================================== BUG     nfsd_file (Not tainted): Objects remaining in nfsd_file on __kmem_cache_shutdown()
    -------------------------------------------------------------------- CPU: 4 UID: 0 PID: 764 Comm: sh Not     tainted 6.12.0-rc3+ #1 dump_stack_lvl+0x53/0x70 slab_err+0xb0/0xf0 __kmem_cache_shutdown+0x15c/0x310     kmem_cache_destroy+0x66/0x160 nfsd_file_cache_shutdown+0xac/0x210 [nfsd] nfsd_destroy_serv+0x251/0x2a0     [nfsd] nfsd_svc+0x125/0x1e0 [nfsd] write_threads+0x16a/0x2a0 [nfsd] nfsctl_transaction_write+0x74/0xa0     [nfsd] vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170     entry_SYSCALL_64_after_hwframe+0x76/0x7e     ==================================================================== BUG nfsd_file_mark (Tainted: G B W ):
    Objects remaining nfsd_file_mark on __kmem_cache_shutdown()
    -------------------------------------------------------------------- dump_stack_lvl+0x53/0x70     slab_err+0xb0/0xf0 __kmem_cache_shutdown+0x15c/0x310 kmem_cache_destroy+0x66/0x160     nfsd_file_cache_shutdown+0xc8/0x210 [nfsd] nfsd_destroy_serv+0x251/0x2a0 [nfsd] nfsd_svc+0x125/0x1e0     [nfsd] write_threads+0x16a/0x2a0 [nfsd] nfsctl_transaction_write+0x74/0xa0 [nfsd] vfs_write+0x1a5/0x6d0     ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e To resolve this     issue, cancel `nfsd_shrinker_work` using synchronous mode in nfs4_state_shutdown_net. (CVE-2024-50121)

  - In the Linux kernel, the following vulnerability has been resolved: fscache: Fix oops due to race with     cookie_lru and use_cookie If a cookie expires from the LRU and the LRU_DISCARD flag is set, but the state     machine has not run yet, it's possible another thread can call fscache_use_cookie and begin to use it.
    When the cookie_worker finally runs, it will see the LRU_DISCARD flag set, transition the cookie->state to     LRU_DISCARDING, which will then withdraw the cookie. Once the cookie is withdrawn the object is removed     the below oops will occur because the object associated with the cookie is now NULL. Fix the oops by     clearing the LRU_DISCARD bit if another thread uses the cookie before the cookie_worker runs. BUG: kernel     NULL pointer dereference, address: 0000000000000008 ... CPU: 31 PID: 44773 Comm: kworker/u130:1 Tainted: G     E 6.0.0-5.dneg.x86_64 #1 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google     08/26/2022 Workqueue: events_unbound netfs_rreq_write_to_cache_work [netfs] RIP:
    0010:cachefiles_prepare_write+0x28/0x90 [cachefiles] ... Call Trace:
    netfs_rreq_write_to_cache_work+0x11c/0x320 [netfs] process_one_work+0x217/0x3e0 worker_thread+0x4a/0x3b0     kthread+0xd6/0x100 (CVE-2022-48989)

  - In the Linux kernel, the following vulnerability has been resolved: scsi: aacraid: Fix double-free on     probe failure aac_probe_one() calls hardware-specific init functions through the aac_driver_ident::init     pointer, all of which eventually call down to aac_init_adapter(). If aac_init_adapter() fails after     allocating memory for aac_dev::queues, it frees the memory but does not clear that member. After the     hardware-specific init function returns an error, aac_probe_one() goes down an error path that frees the     memory pointed to by aac_dev::queues, resulting.in a double-free. (CVE-2024-46673)

  - In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix dentry leak in     cachefiles_open_file() A dentry leak may be caused when a lookup cookie and a cull are concurrent: P1 | P2
    ----------------------------------------------------------- cachefiles_lookup_cookie     cachefiles_look_up_object lookup_one_positive_unlocked // get dentry cachefiles_cull inode->i_flags |=     S_KERNEL_FILE; cachefiles_open_file cachefiles_mark_inode_in_use __cachefiles_mark_inode_in_use can_use =     false if (!(inode->i_flags & S_KERNEL_FILE)) can_use = true return false return false // Returns an error     but doesn't put dentry After that the following WARNING will be triggered when the backend folder is     umounted: ================================================================== BUG: Dentry     000000008ad87947{i=7a,n=Dx_1_1.img} still in use (1) [unmount of ext4 sda] WARNING: CPU: 4 PID: 359261 at     fs/dcache.c:1767 umount_check+0x5d/0x70 CPU: 4 PID: 359261 Comm: umount Not tainted 6.6.0-dirty #25 RIP:
    0010:umount_check+0x5d/0x70 Call Trace: <TASK> d_walk+0xda/0x2b0 do_one_tree+0x20/0x40     shrink_dcache_for_umount+0x2c/0x90 generic_shutdown_super+0x20/0x160 kill_block_super+0x1a/0x40     ext4_kill_sb+0x22/0x40 deactivate_locked_super+0x35/0x80 cleanup_mnt+0x104/0x160     ================================================================== Whether cachefiles_open_file() returns     true or false, the reference count obtained by lookup_positive_unlocked() in cachefiles_look_up_object()     should be released. Therefore release that reference count in cachefiles_look_up_object() to fix the above     issue and simplify the code. (CVE-2024-49870)

  - In the Linux kernel, the following vulnerability has been resolved: uprobes: fix kernel info leak via     [uprobes] vma xol_add_vma() maps the uninitialized page allocated by __create_xol_area() into userspace.
    On some architectures (x86) this memory is readable even without VM_READ, VM_EXEC results in the same     pgprot_t as VM_EXEC|VM_READ, although this doesn't really matter, debugger can read this memory anyway.
    (CVE-2024-49975)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the kernel-5.14.0-539.el9 build changelog.

  - 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-2023-52917)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix possible crash on     mgmt_index_removed If mgmt_index_removed is called while there are commands queued on cmd_sync it could     lead to crashes like the bellow trace: 0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc 0x0000053D:
    mgmt_pending_remove+0x18/0x58 [bluetooth] 0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108     [bluetooth] 0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth] So while handling mgmt_index_removed this     attempts to dequeue commands passed as user_data to cmd_sync. (CVE-2024-49951)

  - In the Linux kernel, the following vulnerability has been resolved: sctp: properly validate chunk size in     sctp_sf_ootb() A size validation fix similar to that in Commit 50619dbf8db7 (sctp: add size validation     when walking chunks) is also required in sctp_sf_ootb() to address a crash reported by syzbot: BUG:
    KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0     net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166     sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380     net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50     net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205     ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233 (CVE-2024-50299)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the kernel-5.14.0-536.el9 build changelog.

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HCI: Fix potential null-     ptr-deref Fix potential null-ptr-deref in hci_le_big_sync_established_evt(). (CVE-2024-36011)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix uaf in     l2cap_connect [Syzbot reported] BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270     net/bluetooth/l2cap_core.c:3949 Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54 CPU: 0     UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Hardware name:
    Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci2 hci_rx_work     Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x116/0x1f0     lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620     mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601     l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 l2cap_connect_req     net/bluetooth/l2cap_core.c:4080 [inline] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline]     l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline] l2cap_recv_frame+0xf0b/0x8eb0     net/bluetooth/l2cap_core.c:6825 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514     hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline] hci_rx_work+0xaab/0x1610     net/bluetooth/hci_core.c:4028 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231     process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389     kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147     ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ... Freed by task 5245:
    kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68     kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:579 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240
    __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline]     slab_free_hook mm/slub.c:2256 [inline] slab_free mm/slub.c:4477 [inline] kfree+0x12a/0x3b0 mm/slub.c:4598     l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline] kref_put include/linux/kref.h:65 [inline]     l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline] l2cap_conn_del+0x59d/0x730     net/bluetooth/l2cap_core.c:1802 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241     hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline] hci_conn_failed+0x1c3/0x370     net/bluetooth/hci_conn.c:1265 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583     abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917 hci_cmd_sync_work+0x1a4/0x410     net/bluetooth/hci_sync.c:328 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works     kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0     kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30     arch/x86/entry/entry_64.S:244 (CVE-2024-49950)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: Fix UAF in     hci_enhanced_setup_sync This checks if the ACL connection remains valid as it could be destroyed while     hci_enhanced_setup_sync is pending on cmd_sync leading to the following trace: BUG: KASAN: slab-use-after-     free in hci_enhanced_setup_sync+0x91b/0xa60 Read of size 1 at addr ffff888002328ffd by task     kworker/u5:2/37 CPU: 0 UID: 0 PID: 37 Comm: kworker/u5:2 Not tainted 6.11.0-rc6-01300-g810be445d8d6 #7099     Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Workqueue: hci0     hci_cmd_sync_work Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 ? hci_enhanced_setup_sync+0x91b/0xa60     print_report+0x152/0x4c0 ? hci_enhanced_setup_sync+0x91b/0xa60 ? __virt_addr_valid+0x1fa/0x420 ?     hci_enhanced_setup_sync+0x91b/0xa60 kasan_report+0xda/0x1b0 ? hci_enhanced_setup_sync+0x91b/0xa60     hci_enhanced_setup_sync+0x91b/0xa60 ? __pfx_hci_enhanced_setup_sync+0x10/0x10 ?
    __pfx___mutex_lock+0x10/0x10 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 ?
    __pfx_lock_acquire+0x10/0x10 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x167/0x240     worker_thread+0x5b7/0xf60 ? __kthread_parkme+0xac/0x1c0 ? __pfx_worker_thread+0x10/0x10 ?
    __pfx_worker_thread+0x10/0x10 kthread+0x293/0x360 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x70 ?
    __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 34:
    kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0
    __hci_conn_add+0x187/0x17d0 hci_connect_sco+0x2e1/0xb90 sco_sock_connect+0x2a2/0xb80
    __sys_connect+0x227/0x2a0 __x64_sys_connect+0x6d/0xb0 do_syscall_64+0x71/0x140     entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 37: kasan_save_stack+0x30/0x50     kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x101/0x160 kfree+0xd0/0x250     device_release+0x9a/0x210 kobject_put+0x151/0x280 hci_conn_del+0x448/0xbf0 hci_abort_conn_sync+0x46f/0x980     hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 worker_thread+0x5b7/0xf60 kthread+0x293/0x360     ret_from_fork+0x2f/0x70 ret_from_fork_asm+0x1a/0x30 (CVE-2024-50029)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: FIX possible     deadlock in rfcomm_sk_state_change rfcomm_sk_state_change attempts to use sock_lock so it must never be     called with it locked but rfcomm_sock_ioctl always attempt to lock it causing the following trace:
    ====================================================== WARNING: possible circular locking dependency     detected 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted
    ------------------------------------------------------ syz-executor386/5093 is trying to acquire lock:
    ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671     [inline] ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at:
    rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73 but task is already holding lock:
    ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0     net/bluetooth/rfcomm/core.c:491 (CVE-2024-50044)

  - In the Linux kernel, the following vulnerability has been resolved: uprobe: avoid out-of-bounds memory     access of fetching args Uprobe needs to fetch args into a percpu buffer, and then copy to ring buffer to     avoid non-atomic context problem. Sometimes user-space strings, arrays can be very large, but the size of     percpu buffer is only page size. And store_trace_args() won't check whether these data exceeds a single     page or not, caused out-of-bounds memory access. It could be reproduced by following steps: 1. build     kernel with CONFIG_KASAN enabled 2. save follow program as test.c ``` \#include <stdio.h> \#include     <stdlib.h> \#include <string.h> // If string length large than MAX_STRING_SIZE, the fetch_store_strlen()     // will return 0, cause __get_data_size() return shorter size, and // store_trace_args() will not trigger     out-of-bounds access. // So make string length less than 4096. \#define STRLEN 4093 void     generate_string(char *str, int n) { int i; for (i = 0; i < n; ++i) { char c = i % 26 + 'a'; str[i] = c; }     str[n-1] = '\0'; } void print_string(char *str) { printf(%s\n, str); } int main() { char tmp[STRLEN];
    generate_string(tmp, STRLEN); print_string(tmp); return 0; } ``` 3. compile program `gcc -o test test.c`     4. get the offset of `print_string()` ``` objdump -t test | grep -w print_string 0000000000401199 g F     .text 000000000000001b print_string ``` 5. configure uprobe with offset 0x1199 ``` off=0x1199 cd     /sys/kernel/debug/tracing/ echo p /root/test:${off} arg1=+0(%di):ustring arg2=\$comm     arg3=+0(%di):ustring > uprobe_events echo 1 > events/uprobes/enable echo 1 > tracing_on ``` 6. run     `test`, and kasan will report error. ==================================================================     BUG: KASAN: use-after-free in strncpy_from_user+0x1d6/0x1f0 Write of size 8 at addr ffff88812311c004 by     task test/499CPU: 0 UID: 0 PID: 499 Comm: test Not tainted 6.12.0-rc3+ #18 Hardware name: Red Hat KVM,     BIOS 1.16.0-4.al8 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x55/0x70     print_address_description.constprop.0+0x27/0x310 kasan_report+0x10f/0x120 ? strncpy_from_user+0x1d6/0x1f0     strncpy_from_user+0x1d6/0x1f0 ? rmqueue.constprop.0+0x70d/0x2ad0 process_fetch_insn+0xb26/0x1470 ?
    __pfx_process_fetch_insn+0x10/0x10 ? _raw_spin_lock+0x85/0xe0 ? __pfx__raw_spin_lock+0x10/0x10 ?
    __pte_offset_map+0x1f/0x2d0 ? unwind_next_frame+0xc5f/0x1f80 ? arch_stack_walk+0x68/0xf0 ?     is_bpf_text_address+0x23/0x30 ? kernel_text_address.part.0+0xbb/0xd0 ? __kernel_text_address+0x66/0xb0 ?     unwind_get_return_address+0x5e/0xa0 ? __pfx_stack_trace_consume_entry+0x10/0x10 ?     arch_stack_walk+0xa2/0xf0 ? _raw_spin_lock_irqsave+0x8b/0xf0 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ?     depot_alloc_stack+0x4c/0x1f0 ? _raw_spin_unlock_irqrestore+0xe/0x30 ? stack_depot_save_flags+0x35d/0x4f0 ?     kasan_save_stack+0x34/0x50 ? kasan_save_stack+0x24/0x50 ? mutex_lock+0x91/0xe0 ?
    __pfx_mutex_lock+0x10/0x10 prepare_uprobe_buffer.part.0+0x2cd/0x500 uprobe_dispatcher+0x2c3/0x6a0 ?
    __pfx_uprobe_dispatcher+0x10/0x10 ? __kasan_slab_alloc+0x4d/0x90 handler_chain+0xdd/0x3e0     handle_swbp+0x26e/0x3d0 ? __pfx_handle_swbp+0x10/0x10 ? uprobe_pre_sstep_notifier+0x151/0x1b0     irqentry_exit_to_user_mode+0xe2/0x1b0 asm_exc_int3+0x39/0x40 RIP: 0033:0x401199 Code: 01 c2 0f b6 45 fb 88     02 83 45 fc 01 8b 45 fc 3b 45 e4 7c b7 8b 45 e4 48 98 48 8d 50 ff 48 8b 45 e8 48 01 d0 ce RSP:
    002b:00007ffdf00576a8 EFLAGS: 00000206 RAX: 00007ffdf00576b0 RBX: 0000000000000000 RCX: 0000000000000ff2     RDX: 0000000000000ffc RSI: 0000000000000ffd RDI: 00007ffdf00576b0 RBP: 00007ffdf00586b0 R08:
    00007feb2f9c0d20 R09: 00007feb2f9c0d20 R10: 0000000000000001 R11: 0000000000000202 R12: 0000000000401040     R13: 00007ffdf0058780 R14: 0000000000000000 R15: 0000000000000000 </TASK> This commit enforces the     buffer's maxlen less than a page-size to avoid store_trace_args() out-of-memory access. (CVE-2024-50067)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix multiple init when     debugfs is disabled If bt_debugfs is not created successfully, which happens if either CONFIG_DEBUG_FS or     CONFIG_DEBUG_FS_ALLOW_ALL is unset, then iso_init() returns early and does not set iso_inited to true.
    This means that a subsequent call to iso_init() will result in duplicate calls to proto_register(),     bt_sock_register(), etc. With CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, the     duplicate call to proto_register() triggers this BUG(): list_add double add: new=ffffffffc0b280d0,     prev=ffffffffbab56250, next=ffffffffc0b280d0. ------------[ cut here ]------------ kernel BUG at     lib/list_debug.c:35! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 2 PID: 887 Comm: bluetoothd Not     tainted 6.10.11-1-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x9a/0xa0 ...
    __list_add_valid_or_report+0x9a/0xa0 proto_register+0x2b5/0x340 iso_init+0x23/0x150 [bluetooth]     set_iso_socket_func+0x68/0x1b0 [bluetooth] kmem_cache_free+0x308/0x330 hci_sock_sendmsg+0x990/0x9e0     [bluetooth] __sock_sendmsg+0x7b/0x80 sock_write_iter+0x9a/0x110 do_iter_readv_writev+0x11d/0x220     vfs_writev+0x180/0x3e0 do_writev+0xca/0x100 ... This change removes the early return. The check for     iso_debugfs being NULL was unnecessary, it is always NULL when iso_inited is false. (CVE-2024-50077)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Call iso_exit() on module     unload If iso_init() has been called, iso_exit() must be called on module unload. Without that, the struct     proto that iso_init() registered with proto_register() becomes invalid, which could cause unpredictable     problems later. In my case, with CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, loading     the module again usually triggers this BUG(): list_add corruption. next->prev should be prev     (ffffffffb5355fd0), but was 0000000000000068. (next=ffffffffc0a010d0). ------------[ cut here     ]------------ kernel BUG at lib/list_debug.c:29! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 1     PID: 4159 Comm: modprobe Not tainted 6.10.11-4+bt2-ao-desktop #1 RIP:
    0010:__list_add_valid_or_report+0x61/0xa0 ... __list_add_valid_or_report+0x61/0xa0     proto_register+0x299/0x320 hci_sock_init+0x16/0xc0 [bluetooth] bt_init+0x68/0xd0 [bluetooth]
    __pfx_bt_init+0x10/0x10 [bluetooth] do_one_initcall+0x80/0x2f0 do_init_module+0x8b/0x230
    __do_sys_init_module+0x15f/0x190 do_syscall_64+0x68/0x110 ... (CVE-2024-50078)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: Fix UAF on     sco_sock_timeout conn->sk maybe have been unlinked/freed while waiting for sco_conn_lock so this checks if     the conn->sk is still valid by checking if it part of sco_sk_list. (CVE-2024-50125)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: fix wild-memory-     access in proto_unregister There's issue as follows: KASAN: maybe wild-memory-access in range     [0xdead...108-0xdead...10f] CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G W RIP:
    0010:proto_unregister+0xee/0x400 Call Trace: <TASK> __do_sys_delete_module+0x318/0x580     do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f As bnep_init() ignore bnep_sock_init()'s     return value, and bnep_sock_init() will cleanup all resource. Then when remove bnep module will call     bnep_sock_cleanup() to cleanup sock's resource. To solve above issue just return bnep_sock_init()'s return     value in bnep_exit(). (CVE-2024-50148)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci: fix null-ptr-deref in     hci_read_supported_codecs Fix __hci_cmd_sync_sk() to return not NULL for unknown opcodes.
    __hci_cmd_sync_sk() returns NULL if a command returns a status event. However, it also returns NULL where     an opcode doesn't exist in the hci_cc table because hci_cmd_complete_evt() assumes status = skb->data[0]     for unknown opcodes. This leads to null-ptr-deref in cmd_sync for HCI_OP_READ_LOCAL_CODECS as there is no     hci_cc for HCI_OP_READ_LOCAL_CODECS, which always assumes status = skb->data[0]. KASAN: null-ptr-deref in     range [0x0000000000000070-0x0000000000000077] CPU: 1 PID: 2000 Comm: kworker/u9:5 Not tainted     6.9.0-ga6bcb805883c-dirty #10 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1     04/01/2014 Workqueue: hci7 hci_power_on RIP: 0010:hci_read_supported_codecs+0xb9/0x870     net/bluetooth/hci_codec.c:138 Code: 08 48 89 ef e8 b8 c1 8f fd 48 8b 75 00 e9 96 00 00 00 49 89 c6 48 ba     00 00 00 00 00 fc ff df 4c 8d 60 70 4c 89 e3 48 c1 eb 03 <0f> b6 04 13 84 c0 0f 85 82 06 00 00 41 83 3c 24     02 77 0a e8 bf 78 RSP: 0018:ffff888120bafac8 EFLAGS: 00010212 RAX: 0000000000000000 RBX: 000000000000000e     RCX: ffff8881173f0040 RDX: dffffc0000000000 RSI: ffffffffa58496c0 RDI: ffff88810b9ad1e4 RBP:
    ffff88810b9ac000 R08: ffffffffa77882a7 R09: 1ffffffff4ef1054 R10: dffffc0000000000 R11: fffffbfff4ef1055     R12: 0000000000000070 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88810b9ac000 FS:
    0000000000000000(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 CR2: 00007f6ddaa3439e CR3: 0000000139764003 CR4: 0000000000770ef0 PKRU: 55555554 Call     Trace: <TASK> hci_read_local_codecs_sync net/bluetooth/hci_sync.c:4546 [inline] hci_init_stage_sync     net/bluetooth/hci_sync.c:3441 [inline] hci_init4_sync net/bluetooth/hci_sync.c:4706 [inline] hci_init_sync     net/bluetooth/hci_sync.c:4742 [inline] hci_dev_init_sync net/bluetooth/hci_sync.c:4912 [inline]     hci_dev_open_sync+0x19a9/0x2d30 net/bluetooth/hci_sync.c:4994 hci_dev_do_open net/bluetooth/hci_core.c:483     [inline] hci_power_on+0x11e/0x560 net/bluetooth/hci_core.c:1015 process_one_work kernel/workqueue.c:3267     [inline] process_scheduled_works+0x8ef/0x14f0 kernel/workqueue.c:3348 worker_thread+0x91f/0xe50     kernel/workqueue.c:3429 kthread+0x2cb/0x360 kernel/kthread.c:388 ret_from_fork+0x4d/0x80     arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 (CVE-2024-50255)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the tuned-2.24.0-2.el9 build changelog.

  - A script injection vulnerability was identified in the Tuned package. The `instance_create()` D-Bus     function can be called by locally logged-in users without authentication. This flaw allows a local non-     privileged user to execute a D-Bus call with `script_pre` or `script_post` options that permit arbitrary     scripts with their absolute paths to be passed. These user or attacker-controlled executable scripts or     programs could then be executed by Tuned with root privileges that could allow attackers to local     privilege escalation. (CVE-2024-52336)

  - A log spoofing flaw was found in the Tuned package due to improper sanitization of some API arguments.
    This flaw allows an attacker to pass a controlled sequence of characters; newlines can be inserted into     the log. Instead of the 'evil' the attacker could mimic a valid TuneD log line and trick the     administrator. The quotes '' are usually used in TuneD logs citing raw user input, so there will always be     the ' character ending the spoofed input, and the administrator can easily overlook this. This logged     string is later used in logging and in the output of utilities, for example, `tuned-adm get_instances` or     other third-party programs that use Tuned's D-Bus interface for such operations. (CVE-2024-52337)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 9 host has packages installed that are affected by a vulnerability as referenced in the pam-1.5.1-23.el9 build changelog.

  - A flaw was found in pam_access, where certain rules in its configuration file are mistakenly treated as     hostnames. This vulnerability allows attackers to trick the system by pretending to be a trusted hostname,     gaining unauthorized access. This issue poses a risk for systems that rely on this feature to control who     can access certain services or terminals. (CVE-2024-10963)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the kernel-5.14.0-529.el9 build changelog.

  - In the Linux kernel, the following vulnerability has been resolved: ipvs: properly dereference pe in     ip_vs_add_service Use pe directly to resolve sparse warning: net/netfilter/ipvs/ip_vs_ctl.c:1471:27:
    warning: dereference of noderef expression (CVE-2024-42322)

  - In the Linux kernel, the following vulnerability has been resolved: fscache: delete     fscache_cookie_lru_timer when fscache exits to avoid UAF The fscache_cookie_lru_timer is initialized when     the fscache module is inserted, but is not deleted when the fscache module is removed. If timer_reduce()     is called before removing the fscache module, the fscache_cookie_lru_timer will be added to the timer list     of the current cpu. Afterwards, a use-after-free will be triggered in the softIRQ after removing the     fscache module, as follows: ================================================================== BUG: unable     to handle page fault for address: fffffbfff803c9e9 PF: supervisor read access in kernel mode PF:
    error_code(0x0000) - not-present page PGD 21ffea067 P4D 21ffea067 PUD 21ffe6067 PMD 110a7c067 PTE 0 Oops:
    Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Tainted: G W 6.11.0-rc3 #855     Tainted: [W]=WARN RIP: 0010:__run_timer_base.part.0+0x254/0x8a0 Call Trace: <IRQ>     tmigr_handle_remote_up+0x627/0x810 __walk_groups.isra.0+0x47/0x140 tmigr_handle_remote+0x1fa/0x2f0     handle_softirqs+0x180/0x590 irq_exit_rcu+0x84/0xb0 sysvec_apic_timer_interrupt+0x6e/0x90 </IRQ> <TASK>     asm_sysvec_apic_timer_interrupt+0x1a/0x20 RIP: 0010:default_idle+0xf/0x20 default_idle_call+0x38/0x60     do_idle+0x2b5/0x300 cpu_startup_entry+0x54/0x60 start_secondary+0x20d/0x280 common_startup_64+0x13e/0x148     </TASK> Modules linked in: [last unloaded: netfs]     ================================================================== Therefore delete     fscache_cookie_lru_timer when removing the fscahe module. (CVE-2024-46786)

  - In the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent     async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients     can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for     a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the     number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements     a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY.
    The requesting client can choose to send the request again after a delay or fall back to a traditional     read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in     future patches. (CVE-2024-49974)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: xtables: avoid     NFPROTO_UNSPEC where needed syzbot managed to call xt_cluster match via ebtables: WARNING: CPU: 0 PID: 11     at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40 Module     registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet processing. As this is only useful to     restrict locally terminating TCP/UDP traffic, register this for ipv4 and ipv6 family only. Pablo points     out that this is a general issue, direct users of the set/getsockopt interface can call into     targets/matches that were only intended for use with ip(6)tables. Check all UNSPEC matches and targets for     similar issues: - matches and targets are fine except if they assume skb_network_header() is valid -- this     is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area. -     targets that return XT_CONTINUE or other xtables verdicts must be restricted too, they are incompatbile     with the ebtables traverser, e.g. EBT_CONTINUE is a completely different value than XT_CONTINUE. Most     matches/targets are changed to register for NFPROTO_IPV4/IPV6, as they are provided for use by     ip(6)tables. The MARK target is also used by arptables, so register for NFPROTO_ARP too. While at it, bail     out if connbytes fails to enable the corresponding conntrack family. This change passes the selftests in     iptables.git. (CVE-2024-50038)

  - In the Linux kernel, the following vulnerability has been resolved: platform/x86/intel/pmc: Fix     pmc_core_iounmap to call iounmap for valid addresses Commit 50c6dbdfd16e (x86/ioremap: Improve iounmap()     address range checks) introduces a WARN when adrress ranges of iounmap are invalid. On Thinkpad P1 Gen 7     (Meteor Lake-P) this caused the following warning to appear: WARNING: CPU: 7 PID: 713 at     arch/x86/mm/ioremap.c:461 iounmap+0x58/0x1f0 Modules linked in: rfkill(+) snd_timer(+) fjes(+) snd     soundcore intel_pmc_core(+) int3403_thermal(+) int340x_thermal_zone intel_vsec pmt_telemetry acpi_pad     pmt_class acpi_tad int3400_thermal acpi_thermal_rel joydev loop nfnetlink zram xe drm_suballoc_helper     nouveau i915 mxm_wmi drm_ttm_helper gpu_sched drm_gpuvm drm_exec drm_buddy i2c_algo_bit crct10dif_pclmul     crc32_pclmul ttm crc32c_intel polyval_clmulni rtsx_pci_sdmmc ucsi_acpi polyval_generic mmc_core     hid_multitouch drm_display_helper ghash_clmulni_intel typec_ucsi nvme sha512_ssse3 video sha256_ssse3     nvme_core intel_vpu sha1_ssse3 rtsx_pci cec typec nvme_auth i2c_hid_acpi i2c_hid wmi pinctrl_meteorlake     serio_raw ip6_tables ip_tables fuse CPU: 7 UID: 0 PID: 713 Comm: (udev-worker) Not tainted     6.12.0-rc2iounmap+ #42 Hardware name: LENOVO 21KWCTO1WW/21KWCTO1WW, BIOS N48ET19W (1.06 ) 07/18/2024 RIP:
    0010:iounmap+0x58/0x1f0 Code: 85 6a 01 00 00 48 8b 05 e6 e2 28 04 48 39 c5 72 19 eb 26 cc cc cc 48 ba 00     00 00 00 00 00 32 00 48 8d 44 02 ff 48 39 c5 72 23 <0f> 0b 48 83 c4 08 5b 5d 41 5c c3 cc cc cc cc 48 ba 00     00 00 00 00 RSP: 0018:ffff888131eff038 EFLAGS: 00010207 RAX: ffffc90000000000 RBX: 0000000000000000 RCX:
    ffff888e33b80000 RDX: dffffc0000000000 RSI: ffff888e33bc29c0 RDI: 0000000000000000 RBP: 0000000000000000     R08: ffff8881598a8000 R09: ffff888e2ccedc10 R10: 0000000000000003 R11: ffffffffb3367634 R12:
    00000000fe000000 R13: ffff888101d0da28 R14: ffffffffc2e437e0 R15: ffff888110b03b28 FS:
    00007f3c1d4b3980(0000) GS:ffff888e33b80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 CR2: 00005651cfc93578 CR3: 0000000124e4c002 CR4: 0000000000f70ef0 DR0: 0000000000000000     DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7:
    0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __warn.cold+0xb6/0x176 ? iounmap+0x58/0x1f0 ?     report_bug+0x1f4/0x2b0 ? handle_bug+0x58/0x90 ? exc_invalid_op+0x17/0x40 ? asm_exc_invalid_op+0x1a/0x20 ?     iounmap+0x58/0x1f0 pmc_core_ssram_get_pmc+0x477/0x6c0 [intel_pmc_core] ?
    __pfx_pmc_core_ssram_get_pmc+0x10/0x10 [intel_pmc_core] ? __pfx_do_pci_enable_device+0x10/0x10 ?     pci_wait_for_pending+0x60/0x110 ? pci_enable_device_flags+0x1e3/0x2e0 ? __pfx_mtl_core_init+0x10/0x10     [intel_pmc_core] pmc_core_ssram_init+0x7f/0x110 [intel_pmc_core] mtl_core_init+0xda/0x130 [intel_pmc_core]     ? __mutex_init+0xb9/0x130 pmc_core_probe+0x27e/0x10b0 [intel_pmc_core] ? _raw_spin_lock_irqsave+0x96/0xf0     ? __pfx_pmc_core_probe+0x10/0x10 [intel_pmc_core] ? __pfx_mutex_unlock+0x10/0x10 ?
    __pfx_mutex_lock+0x10/0x10 ? device_pm_check_callbacks+0x82/0x370 ? acpi_dev_pm_attach+0x234/0x2b0     platform_probe+0x9f/0x150 really_probe+0x1e0/0x8a0 __driver_probe_device+0x18c/0x370 ?
    __pfx___driver_attach+0x10/0x10 driver_probe_device+0x4a/0x120 __driver_attach+0x190/0x4a0 ?
    __pfx___driver_attach+0x10/0x10 bus_for_each_dev+0x103/0x180 ? __pfx_bus_for_each_dev+0x10/0x10 ?     klist_add_tail+0x136/0x270 bus_add_driver+0x2fc/0x540 driver_register+0x1a5/0x360 ?
    __pfx_pmc_core_driver_init+0x10/0x10 [intel_pmc_core] do_one_initcall+0xa4/0x380 ?
    __pfx_do_one_initcall+0x10/0x10 ? kasan_unpoison+0x44/0x70 do_init_module+0x296/0x800     load_module+0x5090/0x6ce0 ? __pfx_load_module+0x10/0x10 ? ima_post_read_file+0x193/0x200 ?
    __pfx_ima_post_read_file+0x10/0x10 ? rw_verify_area+0x152/0x4c0 ? kernel_read_file+0x257/0x750 ?
    __pfx_kernel_read_file+0x10/0x10 ? __pfx_filemap_get_read_batch+0x10/0x10 ?     init_module_from_file+0xd1/0x130 init_module_from_file+0xd1/0x130 ? __pfx_init_module_from_file+0x10/0
    ---truncated--- (CVE-2024-50107)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 9 host has packages installed that are affected by a vulnerability as referenced in the expat-2.5.0-4.el9 build changelog.

  - An issue was discovered in libexpat before 2.6.4. There is a crash within the XML_ResumeParser function     because XML_StopParser can stop/suspend an unstarted parser. (CVE-2024-50602)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the kernel-5.14.0-527.el9 build changelog.

  - In the Linux kernel, the following vulnerability has been resolved: USB: core: Fix duplicate endpoint bug     by clearing reserved bits in the descriptor Syzbot has identified a bug in usbcore (see the Closes: tag     below) caused by our assumption that the reserved bits in an endpoint descriptor's bEndpointAddress field     will always be 0. As a result of the bug, the endpoint_is_duplicate() routine in config.c (and possibly     other routines as well) may believe that two descriptors are for distinct endpoints, even though they have     the same direction and endpoint number. This can lead to confusion, including the bug identified by syzbot     (two descriptors with matching endpoint numbers and directions, where one was interrupt and the other was     bulk). To fix the bug, we will clear the reserved bits in bEndpointAddress when we parse the descriptor.
    (Note that both the USB-2.0 and USB-3.1 specs say these bits are Reserved, reset to zero.) This requires     us to make a copy of the descriptor earlier in usb_parse_endpoint() and use the copy instead of the     original when checking for duplicates. (CVE-2024-41035)

  - In the Linux kernel, the following vulnerability has been resolved: USB: serial: mos7840: fix crash on     resume Since commit c49cfa917025 (USB: serial: use generic method if no alternative is provided in usb     serial layer), USB serial core calls the generic resume implementation when the driver has not provided     one. This can trigger a crash on resume with mos7840 since support for multiple read URBs was added back     in 2011. Specifically, both port read URBs are now submitted on resume for open ports, but the context     pointer of the second URB is left set to the core rather than mos7840 port structure. Fix this by     implementing dedicated suspend and resume functions for mos7840. Tested with Delock 87414 USB 2.0 to 4x     serial adapter. [ johan: analyse crash and rewrite commit message; set busy flag on resume; drop bulk-in     check; drop unnecessary usb_kill_urb() ] (CVE-2024-42244)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the kernel-5.14.0-516.el9 build changelog.

  - In the Linux kernel, the following vulnerability has been resolved: r8169: Fix possible ring buffer     corruption on fragmented Tx packets. An issue was found on the RTL8125b when transmitting small fragmented     packets, whereby invalid entries were inserted into the transmit ring buffer, subsequently leading to     calls to dma_unmap_single() with a null address. This was caused by rtl8169_start_xmit() not noticing     changes to nr_frags which may occur when small packets are padded (to work around hardware quirks) in     rtl8169_tso_csum_v2(). To fix this, postpone inspecting nr_frags until after any padding has been applied.
    (CVE-2024-38586)

  - In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Avoid unnecessary     destruction of file_ida file_ida is allocated during cdev open and is freed accordingly during cdev     release. This sequence is guaranteed by driver file operations. Therefore, there is no need to destroy an     already empty file_ida when the WQ cdev is removed. Worse, ida_free() in cdev release may happen after     destruction of file_ida per WQ cdev. This can lead to accessing an id in file_ida after it has been     destroyed, resulting in a kernel panic. Remove ida_destroy(&file_ida) to address these issues.
    (CVE-2024-38629)

  - In the Linux kernel, the following vulnerability has been resolved: ionic: fix kernel panic in XDP_TX     action In the XDP_TX path, ionic driver sends a packet to the TX path with rx page and corresponding dma     address. After tx is done, ionic_tx_clean() frees that page. But RX ring buffer isn't reset to NULL. So,     it uses a freed page, which causes kernel panic. BUG: unable to handle page fault for address:
    ffff8881576c110c PGD 773801067 P4D 773801067 PUD 87f086067 PMD 87efca067 PTE 800ffffea893e060 Oops: Oops:
    0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI CPU: 1 PID: 25 Comm: ksoftirqd/1 Not tainted 6.9.0+ #11     Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021 RIP:
    0010:bpf_prog_f0b8caeac1068a55_balancer_ingress+0x3b/0x44f Code: 00 53 41 55 41 56 41 57 b8 01 00 00 00 48     8b 5f 08 4c 8b 77 00 4c 89 f7 48 83 c7 0e 48 39 d8 RSP: 0018:ffff888104e6fa28 EFLAGS: 00010283 RAX:
    0000000000000002 RBX: ffff8881576c1140 RCX: 0000000000000002 RDX: ffffffffc0051f64 RSI: ffffc90002d33048     RDI: ffff8881576c110e RBP: ffff888104e6fa88 R08: 0000000000000000 R09: ffffed1027a04a23 R10:
    0000000000000000 R11: 0000000000000000 R12: ffff8881b03a21a8 R13: ffff8881589f800f R14: ffff8881576c1100     R15: 00000001576c1100 FS: 0000000000000000(0000) GS:ffff88881ae00000(0000) knlGS:0000000000000000 CS: 0010     DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff8881576c110c CR3: 0000000767a90000 CR4: 00000000007506f0     PKRU: 55555554 Call Trace: <TASK> ? __die+0x20/0x70 ? page_fault_oops+0x254/0x790 ?
    __pfx_page_fault_oops+0x10/0x10 ? __pfx_is_prefetch.constprop.0+0x10/0x10 ?     search_bpf_extables+0x165/0x260 ? fixup_exception+0x4a/0x970 ? exc_page_fault+0xcb/0xe0 ?     asm_exc_page_fault+0x22/0x30 ? 0xffffffffc0051f64 ? bpf_prog_f0b8caeac1068a55_balancer_ingress+0x3b/0x44f     ? do_raw_spin_unlock+0x54/0x220 ionic_rx_service+0x11ab/0x3010 [ionic     9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? ionic_tx_clean+0x29b/0xc60 [ionic     9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? __pfx_ionic_tx_clean+0x10/0x10 [ionic     9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? __pfx_ionic_rx_service+0x10/0x10 [ionic     9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? ionic_tx_cq_service+0x25d/0xa00 [ionic     9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? __pfx_ionic_rx_service+0x10/0x10 [ionic     9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ionic_cq_service+0x69/0x150 [ionic     9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ionic_txrx_napi+0x11a/0x540 [ionic     9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] __napi_poll.constprop.0+0xa0/0x440 net_rx_action+0x7e7/0xc30 ?
    __pfx_net_rx_action+0x10/0x10 (CVE-2024-40907)

  - In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix missing lock on sync     reset reload On sync reset reload work, when remote host updates devlink on reload actions performed on     that host, it misses taking devlink lock before calling devlink_remote_reload_actions_performed() which     results in triggering lock assert like the following: WARNING: CPU: 4 PID: 1164 at net/devlink/core.c:261     devl_assert_locked+0x3e/0x50  CPU: 4 PID: 1164 Comm: kworker/u96:6 Tainted: G S W 6.10.0-rc2+ #116     Hardware name: Supermicro SYS-2028TP-DECTR/X10DRT-PT, BIOS 2.0 12/18/2015 Workqueue: mlx5_fw_reset_events     mlx5_sync_reset_reload_work [mlx5_core] RIP: 0010:devl_assert_locked+0x3e/0x50  Call Trace: <TASK> ?
    __warn+0xa4/0x210 ? devl_assert_locked+0x3e/0x50 ? report_bug+0x160/0x280 ? handle_bug+0x3f/0x80 ?     exc_invalid_op+0x17/0x40 ? asm_exc_invalid_op+0x1a/0x20 ? devl_assert_locked+0x3e/0x50     devlink_notify+0x88/0x2b0 ? mlx5_attach_device+0x20c/0x230 [mlx5_core] ? __pfx_devlink_notify+0x10/0x10 ?     process_one_work+0x4b6/0xbb0 process_one_work+0x4b6/0xbb0 [] (CVE-2024-42268)

  - In the Linux kernel, the following vulnerability has been resolved: tipc: Return non-zero value from     tipc_udp_addr2str() on error tipc_udp_addr2str() should return non-zero value if the UDP media address is     invalid. Otherwise, a buffer overflow access can occur in tipc_media_addr_printf(). Fix this by returning     1 on an invalid UDP media address. (CVE-2024-42284)

  - In the Linux kernel, the following vulnerability has been resolved: dma: fix call order in     dmam_free_coherent dmam_free_coherent() frees a DMA allocation, which makes the freed vaddr available for     reuse, then calls devres_destroy() to remove and free the data structure used to track the DMA allocation.
    Between the two calls, it is possible for a concurrent task to make an allocation with the same vaddr and     add it to the devres list. If this happens, there will be two entries in the devres list with the same     vaddr and devres_destroy() can free the wrong entry, triggering the WARN_ON() in dmam_match. Fix by     destroying the devres entry before freeing the DMA allocation. kokonut //net/encryption     http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03 (CVE-2024-43856)

  - In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix CT entry update leaks     of modify header context The cited commit allocates a new modify header to replace the old one when     updating CT entry. But if failed to allocate a new one, eg. exceed the max number firmware can support,     modify header will be an error pointer that will trigger a panic when deallocating it. And the old modify     header point is copied to old attr. When the old attr is freed, the old modify header is lost. Fix it by     restoring the old attr to attr when failed to allocate a new modify header context. So when the CT entry     is freed, the right modify header context will be freed. And the panic of accessing error pointer is also     fixed. (CVE-2024-43864)

  - In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Always drain health in     shutdown callback There is no point in recovery during device shutdown. if health work started need to     wait for it to avoid races and NULL pointer access. Hence, drain health WQ on shutdown callback.
    (CVE-2024-43866)

  - In the Linux kernel, the following vulnerability has been resolved: memcg: protect concurrent access to     mem_cgroup_idr Commit 73f576c04b94 (mm: memcontrol: fix cgroup creation failure after many small jobs)     decoupled the memcg IDs from the CSS ID space to fix the cgroup creation failures. It introduced IDR to     maintain the memcg ID space. The IDR depends on external synchronization mechanisms for modifications. For     the mem_cgroup_idr, the idr_alloc() and idr_replace() happen within css callback and thus are protected     through cgroup_mutex from concurrent modifications. However idr_remove() for mem_cgroup_idr was not     protected against concurrency and can be run concurrently for different memcgs when they hit their refcnt     to zero. Fix that. We have been seeing list_lru based kernel crashes at a low frequency in our fleet for a     long time. These crashes were in different part of list_lru code including list_lru_add(), list_lru_del()     and reparenting code. Upon further inspection, it looked like for a given object (dentry and inode), the     super_block's list_lru didn't have list_lru_one for the memcg of that object. The initial suspicions were     either the object is not allocated through kmem_cache_alloc_lru() or somehow memcg_list_lru_alloc() failed     to allocate list_lru_one() for a memcg but returned success. No evidence were found for these cases.
    Looking more deeply, we started seeing situations where valid memcg's id is not present in mem_cgroup_idr     and in some cases multiple valid memcgs have same id and mem_cgroup_idr is pointing to one of them. So,     the most reasonable explanation is that these situations can happen due to race between multiple     idr_remove() calls or race between idr_alloc()/idr_replace() and idr_remove(). These races are causing     multiple memcgs to acquire the same ID and then offlining of one of them would cleanup list_lrus on the     system for all of them. Later access from other memcgs to the list_lru cause crashes due to missing     list_lru_one. (CVE-2024-43892)

  - In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: SHAMPO, Fix invalid WQ     linked list unlink When all the strides in a WQE have been consumed, the WQE is unlinked from the WQ     linked list (mlx5_wq_ll_pop()). For SHAMPO, it is possible to receive CQEs with 0 consumed strides for the     same WQE even after the WQE is fully consumed and unlinked. This triggers an additional unlink for the     same wqe which corrupts the linked list. Fix this scenario by accepting 0 sized consumed strides without     unlinking the WQE again. (CVE-2024-44970)

  - In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix double DMA unmapping for     XDP_REDIRECT Remove the dma_unmap_page_attrs() call in the driver's XDP_REDIRECT code path. This should     have been removed when we let the page pool handle the DMA mapping. This bug causes the warning: WARNING:
    CPU: 7 PID: 59 at drivers/iommu/dma-iommu.c:1198 iommu_dma_unmap_page+0xd5/0x100 CPU: 7 PID: 59 Comm:
    ksoftirqd/7 Tainted: G W 6.8.0-1010-gcp #11-Ubuntu Hardware name: Dell Inc. PowerEdge R7525/0PYVT1, BIOS     2.15.2 04/02/2024 RIP: 0010:iommu_dma_unmap_page+0xd5/0x100 Code: 89 ee 48 89 df e8 cb f2 69 ff 48 83 c4     08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 31 f6 31 ff 45 31 c0 e9 ab 17 71 00 <0f> 0b 48 83 c4 08     5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 RSP: 0018:ffffab1fc0597a48 EFLAGS: 00010246 RAX:
    0000000000000000 RBX: ffff99ff838280c8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000     RDI: 0000000000000000 RBP: ffffab1fc0597a78 R08: 0000000000000002 R09: ffffab1fc0597c1c R10:
    ffffab1fc0597cd3 R11: ffff99ffe375acd8 R12: 00000000e65b9000 R13: 0000000000000050 R14: 0000000000001000     R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff9a06efb80000(0000) knlGS:0000000000000000 CS: 0010     DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000565c34c37210 CR3: 00000005c7e3e000 CR4: 0000000000350ef0     ? show_regs+0x6d/0x80 ? __warn+0x89/0x150 ? iommu_dma_unmap_page+0xd5/0x100 ? report_bug+0x16a/0x190 ?     handle_bug+0x51/0xa0 ? exc_invalid_op+0x18/0x80 ? iommu_dma_unmap_page+0xd5/0x100 ?     iommu_dma_unmap_page+0x35/0x100 dma_unmap_page_attrs+0x55/0x220 ?     bpf_prog_4d7e87c0d30db711_xdp_dispatcher+0x64/0x9f bnxt_rx_xdp+0x237/0x520 [bnxt_en]     bnxt_rx_pkt+0x640/0xdd0 [bnxt_en] __bnxt_poll_work+0x1a1/0x3d0 [bnxt_en] bnxt_poll+0xaa/0x1e0 [bnxt_en]
    __napi_poll+0x33/0x1e0 net_rx_action+0x18a/0x2f0 (CVE-2024-44984)

  - In the Linux kernel, the following vulnerability has been resolved: KVM: s390: fix validity interception     issue when gisa is switched off We might run into a SIE validity if gisa has been disabled either via     using kernel parameter kvm.use_gisa=0 or by setting the related sysfs attribute to N (echo N     >/sys/module/kvm/parameters/use_gisa). The validity is caused by an invalid value in the SIE control     block's gisa designation. That happens because we pass the uninitialized gisa origin to virt_to_phys()     before writing it to the gisa designation. To fix this we return 0 in kvm_s390_get_gisa_desc() if the     origin is 0. kvm_s390_get_gisa_desc() is used to determine which gisa designation to set in the SIE     control block. A value of 0 in the gisa designation disables gisa usage. The issue surfaces in the host     kernel with the following kernel message as soon a new kvm guest start is attemted. kvm: unhandled     validity intercept 0x1011 WARNING: CPU: 0 PID: 781237 at arch/s390/kvm/intercept.c:101     kvm_handle_sie_intercept+0x42e/0x4d0 [kvm] Modules linked in: vhost_net tap tun xt_CHECKSUM xt_MASQUERADE     xt_conntrack ipt_REJECT xt_tcpudp nft_compat x_tables nf_nat_tftp nf_conntrack_tftp vfio_pci_core     irqbypass vhost_vsock vmw_vsock_virtio_transport_common vsock vhost vhost_iotlb kvm nft_fib_inet     nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct     nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables sunrpc mlx5_ib ib_uverbs     ib_core mlx5_core uvdevice s390_trng eadm_sch vfio_ccw zcrypt_cex4 mdev vfio_iommu_type1 vfio sch_fq_codel     drm i2c_core loop drm_panel_orientation_quirks configfs nfnetlink lcs ctcm fsm dm_service_time ghash_s390     prng chacha_s390 libchacha aes_s390 des_s390 libdes sha3_512_s390 sha3_256_s390 sha512_s390 sha256_s390     sha1_s390 sha_common dm_mirror dm_region_hash dm_log zfcp scsi_transport_fc scsi_dh_rdac scsi_dh_emc     scsi_dh_alua pkey zcrypt dm_multipath rng_core autofs4 [last unloaded: vfio_pci] CPU: 0 PID: 781237 Comm:
    CPU 0/KVM Not tainted 6.10.0-08682-gcad9f11498ea #6 Hardware name: IBM 3931 A01 701 (LPAR) Krnl PSW :
    0704c00180000000 000003d93deb0122 (kvm_handle_sie_intercept+0x432/0x4d0 [kvm]) R:0 T:1 IO:1 EX:1 Key:0 M:1     W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 Krnl GPRS: 000003d900000027 000003d900000023 0000000000000028     000002cd00000000 000002d063a00900 00000359c6daf708 00000000000bebb5 0000000000001eff 000002cfd82e9000     000002cfd80bc000 0000000000001011 000003d93deda412 000003ff8962df98 000003d93de77ce0 000003d93deb011e     00000359c6daf960 Krnl Code: 000003d93deb0112: c020fffe7259 larl %r2,000003d93de7e5c4 000003d93deb0118:
    c0e53fa8beac brasl %r14,000003d9bd3c7e70 #000003d93deb011e: af000000 mc 0,0 >000003d93deb0122: a728ffea     lhi %r2,-22 000003d93deb0126: a7f4fe24 brc 15,000003d93deafd6e 000003d93deb012a: 9101f0b0 tm 176(%r15),1     000003d93deb012e: a774fe48 brc 7,000003d93deafdbe 000003d93deb0132: 40a0f0ae sth %r10,174(%r15) Call     Trace: [<000003d93deb0122>] kvm_handle_sie_intercept+0x432/0x4d0 [kvm] ([<000003d93deb011e>]     kvm_handle_sie_intercept+0x42e/0x4d0 [kvm]) [<000003d93deacc10>] vcpu_post_run+0x1d0/0x3b0 [kvm]     [<000003d93deaceda>] __vcpu_run+0xea/0x2d0 [kvm] [<000003d93dead9da>] kvm_arch_vcpu_ioctl_run+0x16a/0x430     [kvm] [<000003d93de93ee0>] kvm_vcpu_ioctl+0x190/0x7c0 [kvm] [<000003d9bd728b4e>] vfs_ioctl+0x2e/0x70     [<000003d9bd72a092>] __s390x_sys_ioctl+0xc2/0xd0 [<000003d9be0e9222>] __do_syscall+0x1f2/0x2e0     [<000003d9be0f9a90>] system_call+0x70/0x98 Last Breaking-Event-Address: [<000003d9bd3c7f58>]
    __warn_printk+0xe8/0xf0 (CVE-2024-45005)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 7 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2020:0028 advisory.

  - Improper invalidation for page table updates by a virtual guest operating system for multiple Intel(R)     Processors may allow an authenticated user to potentially enable denial of service of the host system via     local access. (CVE-2018-12207)

  - TSX Asynchronous Abort condition on some CPUs utilizing speculative execution may allow an authenticated     user to potentially enable information disclosure via a side channel with local access. (CVE-2019-11135)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 7 host has a package installed that is affected by multiple vulnerabilities as referenced in the RHSA-2020:5561 advisory.

  - Uninitialized Use in V8 in Google Chrome prior to 87.0.4280.88 allowed a remote attacker to obtain     potentially sensitive information from process memory via a crafted HTML page. (CVE-2020-16042)

  - Certain blit values provided by the user were not properly constrained leading to a heap buffer overflow     on some video drivers. This vulnerability affects Firefox < 84, Thunderbird < 78.6, and Firefox ESR <     78.6. (CVE-2020-26971)

  - Certain input to the CSS Sanitizer confused it, resulting in incorrect components being removed. This     could have been used as a sanitizer bypass. This vulnerability affects Firefox < 84, Thunderbird < 78.6,     and Firefox ESR < 78.6. (CVE-2020-26973)

  - When flex-basis was used on a table wrapper, a StyleGenericFlexBasis object could have been incorrectly     cast to the wrong type. This resulted in a heap user-after-free, memory corruption, and a potentially     exploitable crash. This vulnerability affects Firefox < 84, Thunderbird < 78.6, and Firefox ESR < 78.6.
    (CVE-2020-26974)

  - Using techniques that built on the slipstream research, a malicious webpage could have exposed both an     internal network's hosts as well as services running on the user's local machine. This vulnerability     affects Firefox < 84, Thunderbird < 78.6, and Firefox ESR < 78.6. (CVE-2020-26978)

  - When an extension with the proxy permission registered to receive <all_urls>, the proxy.onRequest callback     was not triggered for view-source URLs. While web content cannot navigate to such URLs, a user opening     View Source could have inadvertently leaked their IP address. This vulnerability affects Firefox < 84,     Thunderbird < 78.6, and Firefox ESR < 78.6. (CVE-2020-35111)

  - Mozilla developers reported memory safety bugs present in Firefox 83 and Firefox ESR 78.5. Some of these     bugs showed evidence of memory corruption and we presume that with enough effort some of these could have     been exploited to run arbitrary code. This vulnerability affects Firefox < 84, Thunderbird < 78.6, and     Firefox ESR < 78.6. (CVE-2020-35113)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 7 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2021:3381 advisory.

  - A heap out-of-bounds write affecting Linux since v2.6.19-rc1 was discovered in net/netfilter/x_tables.c.
    This allows an attacker to gain privileges or cause a DoS (via heap memory corruption) through user name     space (CVE-2021-22555)

  - net/bluetooth/hci_request.c in the Linux kernel through 5.12.2 has a race condition for removal of the HCI     controller. (CVE-2021-32399)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 7 host has a package installed that is affected by multiple vulnerabilities as referenced in the RHSA-2022:1302 advisory.

  - <code>NSSToken</code> objects were referenced via direct points, and could have been accessed in an unsafe     way on different threads, leading to a use-after-free and potentially exploitable crash. This     vulnerability affects Thunderbird < 91.8, Firefox < 99, and Firefox ESR < 91.8. (CVE-2022-1097)

  - After a VR Process is destroyed, a reference to it may have been retained and used, leading to a use-     after-free and potentially exploitable crash. This vulnerability affects Thunderbird < 91.8 and Firefox     ESR < 91.8. (CVE-2022-1196)

  - When importing a revoked key that specified key compromise as the revocation reason, Thunderbird did not     update the existing copy of the key that was not yet revoked, and the existing key was kept as non-     revoked. Revocation statements that used another revocation reason, or that didn't specify a revocation     reason, were unaffected. This vulnerability affects Thunderbird < 91.8. (CVE-2022-1197)

  - regex is an implementation of regular expressions for the Rust language. The regex crate features built-in     mitigations to prevent denial of service attacks caused by untrusted regexes, or untrusted input matched     by trusted regexes. Those (tunable) mitigations already provide sane defaults to prevent attacks. This     guarantee is documented and it's considered part of the crate's API. Unfortunately a bug was discovered in     the mitigations designed to prevent untrusted regexes to take an arbitrary amount of time during parsing,     and it's possible to craft regexes that bypass such mitigations. This makes it possible to perform denial     of service attacks by sending specially crafted regexes to services accepting user-controlled, untrusted     regexes. All versions of the regex crate before or equal to 1.5.4 are affected by this issue. The fix is     include starting from regex 1.5.5. All users accepting user-controlled regexes are recommended to upgrade     immediately to the latest version of the regex crate. Unfortunately there is no fixed set of problematic     regexes, as there are practically infinite regexes that could be crafted to exploit this vulnerability.
    Because of this, it us not recommend to deny known problematic regexes. (CVE-2022-24713)

  - If a compromised content process sent an unexpected number of WebAuthN Extensions in a Register command to     the parent process, an out of bounds write would have occurred leading to memory corruption and a     potentially exploitable crash. This vulnerability affects Thunderbird < 91.8, Firefox < 99, and Firefox     ESR < 91.8. (CVE-2022-28281)

  - By using a link with <code>rel=localization</code> a use-after-free could have been triggered by     destroying an object during JavaScript execution and then referencing the object through a freed pointer,     leading to a potential exploitable crash. This vulnerability affects Thunderbird < 91.8, Firefox < 99, and     Firefox ESR < 91.8. (CVE-2022-28282)

  - When generating the assembly code for <code>MLoadTypedArrayElementHole</code>, an incorrect AliasSet was     used. In conjunction with another vulnerability this could have been used for an out of bounds memory     read. This vulnerability affects Thunderbird < 91.8, Firefox < 99, and Firefox ESR < 91.8.
    (CVE-2022-28285)

  - Due to a layout change, iframe contents could have been rendered outside of its border. This could have     led to user confusion or spoofing attacks. This vulnerability affects Thunderbird < 91.8, Firefox < 99,     and Firefox ESR < 91.8. (CVE-2022-28286)

  - Mozilla developers and community members Nika Layzell, Andrew McCreight, Gabriele Svelto, and the Mozilla     Fuzzing Team reported memory safety bugs present in Thunderbird 91.7. Some of these bugs showed evidence     of memory corruption and we presume that with enough effort some of these could have been exploited to run     arbitrary code. This vulnerability affects Thunderbird < 91.8, Firefox < 99, and Firefox ESR < 91.8.
    (CVE-2022-28289)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 6 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2020:3548 advisory.

  - The KEYS subsystem in the Linux kernel before 3.18 allows local users to gain privileges or cause a denial     of service (NULL pointer dereference and system crash) via vectors involving a NULL value for a certain     match field, related to the keyring_search_iterator function in keyring.c. (CVE-2017-2647)

  - A heap-based buffer overflow vulnerability was found in the Linux kernel, version kernel-2.6.32, in     Marvell WiFi chip driver. A remote attacker could cause a denial of service (system crash) or, possibly     execute arbitrary code, when the lbs_ibss_join_existing function is called after a STA connects to an AP.
    (CVE-2019-14896)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 6 host has a package installed that is affected by multiple vulnerabilities as referenced in the RHSA-2020:4235 advisory.

  - Use after free in payments in Google Chrome prior to 86.0.4240.75 allowed a remote attacker to potentially     perform a sandbox escape via a crafted HTML page. (CVE-2020-15967)

  - Use after free in Blink in Google Chrome prior to 86.0.4240.75 allowed a remote attacker to potentially     exploit heap corruption via a crafted HTML page. (CVE-2020-15968)

  - Use after free in WebRTC in Google Chrome prior to 86.0.4240.75 allowed a remote attacker to potentially     exploit heap corruption via a crafted HTML page. (CVE-2020-15969)

  - Use after free in NFC in Google Chrome prior to 86.0.4240.75 allowed a remote attacker who had compromised     the renderer process to potentially perform a sandbox escape via a crafted HTML page. (CVE-2020-15970)

  - Use after free in printing in Google Chrome prior to 86.0.4240.75 allowed a remote attacker who had     compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page.
    (CVE-2020-15971)

  - Use after free in audio in Google Chrome prior to 86.0.4240.75 allowed a remote attacker to potentially     exploit heap corruption via a crafted HTML page. (CVE-2020-15972)

  - Insufficient policy enforcement in extensions in Google Chrome prior to 86.0.4240.75 allowed an attacker     who convinced a user to install a malicious extension to bypass same origin policy via a crafted Chrome     Extension. (CVE-2020-15973)

  - Integer overflow in Blink in Google Chrome prior to 86.0.4240.75 allowed a remote attacker to bypass site     isolation via a crafted HTML page. (CVE-2020-15974)

  - Integer overflow in SwiftShader in Google Chrome prior to 86.0.4240.75 allowed a remote attacker to     potentially exploit heap corruption via a crafted HTML page. (CVE-2020-15975)

  - Use after free in WebXR in Google Chrome on Android prior to 86.0.4240.75 allowed a remote attacker to     potentially exploit heap corruption via a crafted HTML page. (CVE-2020-15976)

  - Insufficient data validation in dialogs in Google Chrome on OS X prior to 86.0.4240.75 allowed a remote     attacker to obtain potentially sensitive information from disk via a crafted HTML page. (CVE-2020-15977)

  - Insufficient data validation in navigation in Google Chrome on Android prior to 86.0.4240.75 allowed a     remote attacker who had compromised the renderer process to bypass navigation restrictions via a crafted     HTML page. (CVE-2020-15978)

  - Inappropriate implementation in V8 in Google Chrome prior to 86.0.4240.75 allowed a remote attacker to     potentially exploit heap corruption via a crafted HTML page. (CVE-2020-15979)

  - Insufficient policy enforcement in Intents in Google Chrome on Android prior to 86.0.4240.75 allowed a     local attacker to bypass navigation restrictions via crafted Intents. (CVE-2020-15980)

  - Out of bounds read in audio in Google Chrome prior to 86.0.4240.75 allowed a remote attacker to obtain     potentially sensitive information from process memory via a crafted HTML page. (CVE-2020-15981)

  - Inappropriate implementation in cache in Google Chrome prior to 86.0.4240.75 allowed a remote attacker to     obtain potentially sensitive information from process memory via a crafted HTML page. (CVE-2020-15982)

  - Insufficient data validation in webUI in Google Chrome on ChromeOS prior to 86.0.4240.75 allowed a local     attacker to bypass content security policy via a crafted HTML page. (CVE-2020-15983)

  - Insufficient policy enforcement in Omnibox in Google Chrome on iOS prior to 86.0.4240.75 allowed a remote     attacker to spoof the contents of the Omnibox (URL bar) via a crafted URL. (CVE-2020-15984)

  - Inappropriate implementation in Blink in Google Chrome prior to 86.0.4240.75 allowed a remote attacker to     spoof security UI via a crafted HTML page. (CVE-2020-15985)

  - Integer overflow in media in Google Chrome prior to 86.0.4240.75 allowed a remote attacker to potentially     exploit heap corruption via a crafted HTML page. (CVE-2020-15986)

  - Use after free in WebRTC in Google Chrome prior to 86.0.4240.75 allowed a remote attacker to potentially     exploit heap corruption via a crafted WebRTC stream. (CVE-2020-15987)

  - Insufficient policy enforcement in downloads in Google Chrome on Windows prior to 86.0.4240.75 allowed a     remote attacker who convinced the user to open files to execute arbitrary code via a crafted HTML page.
    (CVE-2020-15988)

  - Uninitialized data in PDFium in Google Chrome prior to 86.0.4240.75 allowed a remote attacker to obtain     potentially sensitive information from process memory via a crafted PDF file. (CVE-2020-15989)

  - Use after free in autofill in Google Chrome prior to 86.0.4240.75 allowed a remote attacker who had     compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page.
    (CVE-2020-15990)

  - Use after free in password manager in Google Chrome prior to 86.0.4240.75 allowed a remote attacker who     had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page.
    (CVE-2020-15991)

  - Insufficient policy enforcement in networking in Google Chrome prior to 86.0.4240.75 allowed a remote     attacker who had compromised the renderer process to bypass same origin policy via a crafted HTML page.
    (CVE-2020-15992)

  - Inappropriate implementation in networking in Google Chrome prior to 86.0.4240.75 allowed a remote     attacker to perform domain spoofing via a crafted HTML page. (CVE-2020-6557)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 7 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2021:0346 advisory.

  - In QEMU through 5.0.0, an assertion failure can occur in the network packet processing. This issue affects     the e1000e and vmxnet3 network devices. A malicious guest user/process could use this flaw to abort the     QEMU process on the host, resulting in a denial of service condition in net_tx_pkt_add_raw_fragment in     hw/net/net_tx_pkt.c. (CVE-2020-16092)

  - A use after free vulnerability in ip_reass() in ip_input.c of libslirp 4.2.0 and prior releases allows     crafted packets to cause a denial of service. (CVE-2020-1983)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 7 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2021:0354 advisory.

  - Use-after-free vulnerability in fs/block_dev.c in the Linux kernel before 5.8 allows local users to gain     privileges or cause a denial of service by leveraging improper access to a certain error field.
    (CVE-2020-15436)

  - A flaw was found in the Linux kernel's implementation of some networking protocols in IPsec, such as VXLAN     and GENEVE tunnels over IPv6. When an encrypted tunnel is created between two hosts, the kernel isn't     correctly routing tunneled data over the encrypted link; rather sending the data unencrypted. This would     allow anyone in between the two endpoints to read the traffic unencrypted. The main threat from this     vulnerability is to data confidentiality. (CVE-2020-1749)

  - A locking issue was discovered in the tty subsystem of the Linux kernel through 5.9.13.
    drivers/tty/tty_jobctrl.c allows a use-after-free attack against TIOCSPGRP, aka CID-54ffccbf053b.
    (CVE-2020-29661)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 6 host has packages installed that are affected by a vulnerability as referenced in the RHSA-2020:2516 advisory.

  - An issue was discovered in libexif before 0.6.22. Several buffer over-reads in EXIF MakerNote handling     could lead to information disclosure and crashes. This is different from CVE-2020-0093. (CVE-2020-13112)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 7 host has a package installed that is affected by multiple vulnerabilities as referenced in the RHSA-2020:4163 advisory.

  - Mozilla developers reported memory safety bugs present in Firefox 80 and Firefox ESR 78.2. Some of these     bugs showed evidence of memory corruption and we presume that with enough effort some of these could have     been exploited to run arbitrary code. This vulnerability affects Firefox < 81, Thunderbird < 78.3, and     Firefox ESR < 78.3. (CVE-2020-15673)

  - Firefox sometimes ran the onload handler for SVG elements that the DOM sanitizer decided to remove,     resulting in JavaScript being executed after pasting attacker-controlled data into a contenteditable     element. This vulnerability affects Firefox < 81, Thunderbird < 78.3, and Firefox ESR < 78.3.
    (CVE-2020-15676)

  - By exploiting an Open Redirect vulnerability on a website, an attacker could have spoofed the site     displayed in the download file dialog to show the original site (the one suffering from the open redirect)     rather than the site the file was actually downloaded from. This vulnerability affects Firefox < 81,     Thunderbird < 78.3, and Firefox ESR < 78.3. (CVE-2020-15677)

  - When recursing through graphical layers while scrolling, an iterator may have become invalid, resulting in     a potential use-after-free. This occurs because the function     APZCTreeManager::ComputeClippedCompositionBounds did not follow iterator invalidation rules. This     vulnerability affects Firefox < 81, Thunderbird < 78.3, and Firefox ESR < 78.3. (CVE-2020-15678)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 7 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2020:2104 advisory.

  - An issue was discovered in drivers/i2c/i2c-core-smbus.c in the Linux kernel before 4.14.15. There is an     out of bounds write in the function i2c_smbus_xfer_emulated. (CVE-2017-18551)

  - An issue was discovered in the Linux kernel before 4.14.11. A double free may be caused by the function     allocate_trace_buffer in the file kernel/trace/trace.c. (CVE-2017-18595)

  - An issue was discovered in dlpar_parse_cc_property in arch/powerpc/platforms/pseries/dlpar.c in the Linux     kernel through 5.1.6. There is an unchecked kstrdup of prop->name, which might allow an attacker to cause     a denial of service (NULL pointer dereference and system crash). (CVE-2019-12614)

  - An issue was discovered in xfs_setattr_nonsize in fs/xfs/xfs_iops.c in the Linux kernel through 5.2.9. XFS     partially wedges when a chgrp fails on account of being out of disk quota. xfs_setattr_nonsize is failing     to unlock the ILOCK after the xfs_qm_vop_chown_reserve call fails. This is primarily a local DoS attack     vector, but it might result as well in remote DoS if the XFS filesystem is exported for instance via NFS.
    (CVE-2019-15538)

  - In the Linux kernel 5.0.21, mounting a crafted ext4 filesystem image, performing some operations, and     unmounting can lead to a use-after-free in ext4_put_super in fs/ext4/super.c, related to dump_orphan_list     in fs/ext4/super.c. (CVE-2019-19447)

  - In the Linux kernel before 5.3.12, there is a use-after-free bug that can be caused by a malicious USB     device in the drivers/input/ff-memless.c driver, aka CID-fa3a5a1880c9. (CVE-2019-19524)

  - In the Linux kernel 5.4.0-rc2, there is a use-after-free (read) in the __blk_add_trace function in     kernel/trace/blktrace.c (which is used to fill out a blk_io_trace structure and place it in a per-cpu sub-     buffer). (CVE-2019-19768)

  - In the Android kernel in i2c driver there is a possible out of bounds write due to memory corruption. This     could lead to local escalation of privilege with System execution privileges needed. User interaction is     not needed for exploitation. (CVE-2019-9454)

  - A NULL pointer dereference flaw was found in the Linux kernel's SELinux subsystem in versions before 5.7.
    This flaw occurs while importing the Commercial IP Security Option (CIPSO) protocol's category bitmap into     the SELinux extensible bitmap via the' ebitmap_netlbl_import' routine. While processing the CIPSO     restricted bitmap tag in the 'cipso_v4_parsetag_rbm' routine, it sets the security attribute to indicate     that the category bitmap is present, even if it has not been allocated. This issue leads to a NULL pointer     dereference issue while importing the same category bitmap into SELinux. This flaw allows a remote network     user to crash the system kernel, resulting in a denial of service. (CVE-2020-10711)

  - An issue was discovered in the Linux kernel 3.16 through 5.5.6. set_fdc in drivers/block/floppy.c leads to     a wait_til_ready out-of-bounds read because the FDC index is not checked for errors before assigning it,     aka CID-2e90ca68b0d2. (CVE-2020-9383)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 7 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2021:3293 advisory.

  - Vulnerability in the Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component:
    Networking). Supported versions that are affected are Java SE: 7u301, 8u291, 11.0.11, 16.0.1; Oracle     GraalVM Enterprise Edition: 20.3.2 and 21.1.0. Difficult to exploit vulnerability allows unauthenticated     attacker with network access via multiple protocols to compromise Java SE, Oracle GraalVM Enterprise     Edition. Successful attacks require human interaction from a person other than the attacker. Successful     attacks of this vulnerability can result in unauthorized read access to a subset of Java SE, Oracle     GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments,     typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load     and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for     security. This vulnerability does not apply to Java deployments, typically in servers, that load and run     only trusted code (e.g., code installed by an administrator). (CVE-2021-2341)

  - Vulnerability in the Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component:
    Library). Supported versions that are affected are Java SE: 7u301, 8u291, 11.0.11, 16.0.1; Oracle GraalVM     Enterprise Edition: 20.3.2 and 21.1.0. Easily exploitable vulnerability allows unauthenticated attacker     with network access via multiple protocols to compromise Java SE, Oracle GraalVM Enterprise Edition.
    Successful attacks require human interaction from a person other than the attacker. Successful attacks of     this vulnerability can result in unauthorized update, insert or delete access to some of Java SE, Oracle     GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments,     typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load     and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for     security. This vulnerability does not apply to Java deployments, typically in servers, that load and run     only trusted code (e.g., code installed by an administrator). (CVE-2021-2369)

  - Vulnerability in the Java SE product of Oracle Java SE (component: JNDI). The supported version that is     affected is Java SE: 7u301. Difficult to exploit vulnerability allows unauthenticated attacker with     network access via multiple protocols to compromise Java SE. Successful attacks of this vulnerability can     result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE. Note: This     vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start     applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the     internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using     APIs in the specified Component, e.g., through a web service which supplies data to the APIs.
    (CVE-2021-2432)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 7 host has packages installed that are affected by a vulnerability as referenced in the RHSA-2020:1209 advisory.

  - In libslirp 4.1.0, as used in QEMU 4.2.0, tcp_subr.c misuses snprintf return values, leading to a buffer     overflow in later code. (CVE-2020-8608)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 7 host has packages installed that are affected by a vulnerability as referenced in the RHSA-2021:3439 advisory.

  - A flaw was found in the Routing decision classifier in the Linux kernel's Traffic Control networking     subsystem in the way it handled changing of classification filters, leading to a use-after-free condition.
    This flaw allows unprivileged local users to escalate their privileges on the system. The highest threat     from this vulnerability is to confidentiality, integrity, as well as system availability. (CVE-2021-3715)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 7 host has a package installed that is affected by multiple vulnerabilities as referenced in the RHSA-2022:9079 advisory.

  - If a Thunderbird user quoted from an HTML email, for example by replying to the email, and the email     contained either a VIDEO tag with the POSTER attribute or an OBJECT tag with a DATA attribute, a network     request to the referenced remote URL was performed, regardless of a configuration to block remote content.
    An image loaded from the POSTER attribute was shown in the composer window. These issues could have given     an attacker additional capabilities when targetting releases that did not yet have a fix for CVE-2022-3033     which was reported around three months ago. This vulnerability affects Thunderbird < 102.5.1.
    (CVE-2022-45414)

  - An attacker who compromised a content process could have partially escaped the sandbox to read arbitrary     files via clipboard-related IPC messages.<br>*This bug only affects Thunderbird for Linux. Other operating     systems are unaffected.*. This vulnerability affects Firefox < 108, Firefox ESR < 102.6, and Thunderbird <     102.6. (CVE-2022-46872)

  - A file with a long filename could have had its filename truncated to remove the valid extension, leaving a     malicious extension in its place. This could potentially led to user confusion and the execution of     malicious code.<br/>*Note*: This issue was originally included in the advisories for Thunderbird 102.6,     but a patch (specific to Thunderbird) was omitted, resulting in it actually being fixed in Thunderbird     102.6.1. This vulnerability affects Firefox < 108, Thunderbird < 102.6.1, Thunderbird < 102.6, and Firefox     ESR < 102.6. (CVE-2022-46874)

  - Mozilla developers Randell Jesup, Valentin Gosu, Olli Pettay, and the Mozilla Fuzzing Team reported memory     safety bugs present in Thunderbird 102.5. Some of these bugs showed evidence of memory corruption and we     presume that with enough effort some of these could have been exploited to run arbitrary code. This     vulnerability affects Firefox < 108, Firefox ESR < 102.6, and Thunderbird < 102.6. (CVE-2022-46878)

  - A missing check related to tex units could have led to a use-after-free and potentially exploitable     crash.<br />*Note*: This advisory was added on December 13th, 2022 after we better understood the impact     of the issue. The fix was included in the original release of Firefox 105. This vulnerability affects     Firefox ESR < 102.6, Firefox < 105, and Thunderbird < 102.6. (CVE-2022-46880)

  - An optimization in WebGL was incorrect in some cases, and could have led to memory corruption and a     potentially exploitable crash. *Note*: This advisory was added on December 13th, 2022 after we better     understood the impact of the issue. The fix was included in the original release of Firefox 106. This     vulnerability affects Firefox < 106, Firefox ESR < 102.6, and Thunderbird < 102.6. (CVE-2022-46881)

  - A use-after-free in WebGL extensions could have led to a potentially exploitable crash. This vulnerability     affects Firefox < 107, Firefox ESR < 102.6, and Thunderbird < 102.6. (CVE-2022-46882)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 7 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2021:0336 advisory.

  - Use-after-free vulnerability in fs/block_dev.c in the Linux kernel before 5.8 allows local users to gain     privileges or cause a denial of service by leveraging improper access to a certain error field.
    (CVE-2020-15436)

  - A flaw incorrect umask during file or directory modification in the Linux kernel NFS (network file system)     functionality was found in the way user create and delete object using NFSv4.2 or newer if both     simultaneously accessing the NFS by the other process that is not using new NFSv4.2. A user with access to     the NFS could use this flaw to starve the resources causing denial of service. (CVE-2020-35513)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 7 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2020:2117 advisory.

  - A path traversal flaw was found in Buildah in versions before 1.14.5. This flaw allows an attacker to     trick a user into building a malicious container image hosted on an HTTP(s) server and then write files to     the user's system anywhere that the user has permissions. (CVE-2020-10696)

  - The proglottis Go wrapper before 0.1.1 for the GPGME library has a use-after-free, as demonstrated by use     for container image pulls by Docker or CRI-O. This leads to a crash or potential code execution during GPG     signature verification. (CVE-2020-8945)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 7 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2021:2260 advisory.

  - A heap-based buffer overflow was found in libwebp in versions before 1.0.1 in PutLE16(). (CVE-2018-25011)

  - A flaw was found in libwebp in versions before 1.0.1. A heap-based buffer overflow in function     WebPDecodeRGBInto is possible due to an invalid check for buffer size. The highest threat from this     vulnerability is to data confidentiality and integrity as well as system availability. (CVE-2020-36328)

  - A flaw was found in libwebp in versions before 1.0.1. A use-after-free was found due to a thread being     killed too early. The highest threat from this vulnerability is to data confidentiality and integrity as     well as system availability. (CVE-2020-36329)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 7 host has packages installed that are affected by a vulnerability as referenced in the RHSA-2024:3304 advisory.

  - Improper Input Validation vulnerability in GStreamer integration of The Document Foundation LibreOffice     allows an attacker to execute arbitrary GStreamer plugins. In affected versions the filename of the     embedded video is not sufficiently escaped when passed to GStreamer enabling an attacker to run arbitrary     gstreamer plugins depending on what plugins are installed on the target system. (CVE-2023-6185)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 7 host has a package installed that is affected by multiple vulnerabilities as referenced in the RHSA-2022:4730 advisory.

  - An attacker could have sent a message to the parent process where the contents were used to double-index     into a JavaScript object, leading to prototype pollution and ultimately attacker-controlled JavaScript     executing in the privileged parent process. This vulnerability affects Firefox ESR < 91.9.1, Firefox <     100.0.2, Firefox for Android < 100.3.0, and Thunderbird < 91.9.1. (CVE-2022-1529)

  - If an attacker was able to corrupt the methods of an Array object in JavaScript via prototype pollution,     they could have achieved execution of attacker-controlled JavaScript code in a privileged context. This     vulnerability affects Firefox ESR < 91.9.1, Firefox < 100.0.2, Firefox for Android < 100.3.0, and     Thunderbird < 91.9.1. (CVE-2022-1802)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 6 host has a package installed that is affected by a vulnerability as referenced in the RHSA-2020:5164 advisory.

  - In certain circumstances, the MCallGetProperty opcode can be emitted with unmet assumptions resulting in     an exploitable use-after-free condition. This vulnerability affects Firefox < 82.0.3, Firefox ESR <     78.4.1, and Thunderbird < 78.4.2. (CVE-2020-26950)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 7 host has packages installed that are affected by a vulnerability as referenced in the RHSA-2020:5079 advisory.

  - A flaw was found in the Linux kernel's implementation of biovecs in versions before 5.9-rc7. A zero-length     biovec request issued by the block subsystem could cause the kernel to enter an infinite loop, causing a     denial of service. This flaw allows a local attacker with basic privileges to issue requests to a block     device, resulting in a denial of service. The highest threat from this vulnerability is to system     availability. (CVE-2020-25641)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 6 host has a package installed that is affected by multiple vulnerabilities as referenced in the RHSA-2020:3377 advisory.

  - Heap buffer overflow in background fetch in Google Chrome prior to 84.0.4147.89 allowed a remote attacker     to potentially exploit heap corruption via a crafted HTML page. (CVE-2020-6510)

  - Information leak in content security policy in Google Chrome prior to 84.0.4147.89 allowed a remote     attacker to leak cross-origin data via a crafted HTML page. (CVE-2020-6511)

  - Type Confusion in V8 in Google Chrome prior to 84.0.4147.89 allowed a remote attacker to potentially     exploit heap corruption via a crafted HTML page. (CVE-2020-6512, CVE-2020-6533)

  - Heap buffer overflow in PDFium in Google Chrome prior to 84.0.4147.89 allowed a remote attacker to     potentially exploit heap corruption via a crafted PDF file. (CVE-2020-6513)

  - Inappropriate implementation in WebRTC in Google Chrome prior to 84.0.4147.89 allowed an attacker in a     privileged network position to potentially exploit heap corruption via a crafted SCTP stream.
    (CVE-2020-6514)

  - Use after free in tab strip in Google Chrome prior to 84.0.4147.89 allowed a remote attacker to     potentially exploit heap corruption via a crafted HTML page. (CVE-2020-6515)

  - Policy bypass in CORS in Google Chrome prior to 84.0.4147.89 allowed a remote attacker to leak cross-     origin data via a crafted HTML page. (CVE-2020-6516)

  - Heap buffer overflow in history in Google Chrome prior to 84.0.4147.89 allowed a remote attacker to     potentially exploit heap corruption via a crafted HTML page. (CVE-2020-6517)

  - Use after free in developer tools in Google Chrome prior to 84.0.4147.89 allowed a remote attacker who had     convinced the user to use developer tools to potentially exploit heap corruption via a crafted HTML page.
    (CVE-2020-6518)

  - Policy bypass in CSP in Google Chrome prior to 84.0.4147.89 allowed a remote attacker to bypass content     security policy via a crafted HTML page. (CVE-2020-6519)

  - Buffer overflow in Skia in Google Chrome prior to 84.0.4147.89 allowed a remote attacker to potentially     exploit heap corruption via a crafted HTML page. (CVE-2020-6520)

  - Side-channel information leakage in autofill in Google Chrome prior to 84.0.4147.89 allowed a remote     attacker to obtain potentially sensitive information from process memory via a crafted HTML page.
    (CVE-2020-6521)

  - Inappropriate implementation in external protocol handlers in Google Chrome prior to 84.0.4147.89 allowed     a remote attacker to potentially perform a sandbox escape via a crafted HTML page. (CVE-2020-6522)

  - Out of bounds write in Skia in Google Chrome prior to 84.0.4147.89 allowed a remote attacker to     potentially exploit heap corruption via a crafted HTML page. (CVE-2020-6523)

  - Heap buffer overflow in WebAudio in Google Chrome prior to 84.0.4147.89 allowed a remote attacker to     potentially exploit heap corruption via a crafted HTML page. (CVE-2020-6524)

  - Heap buffer overflow in Skia in Google Chrome prior to 84.0.4147.89 allowed a remote attacker to     potentially exploit heap corruption via a crafted HTML page. (CVE-2020-6525)

  - Inappropriate implementation in iframe sandbox in Google Chrome prior to 84.0.4147.89 allowed a remote     attacker to bypass navigation restrictions via a crafted HTML page. (CVE-2020-6526)

  - Insufficient policy enforcement in CSP in Google Chrome prior to 84.0.4147.89 allowed a remote attacker to     bypass content security policy via a crafted HTML page. (CVE-2020-6527)

  - Incorrect security UI in basic auth in Google Chrome on iOS prior to 84.0.4147.89 allowed a remote     attacker to spoof the contents of the Omnibox (URL bar) via a crafted HTML page. (CVE-2020-6528)

  - Inappropriate implementation in WebRTC in Google Chrome prior to 84.0.4147.89 allowed an attacker in a     privileged network position to leak cross-origin data via a crafted HTML page. (CVE-2020-6529)

  - Out of bounds memory access in developer tools in Google Chrome prior to 84.0.4147.89 allowed an attacker     who convinced a user to install a malicious extension to potentially exploit heap corruption via a crafted     Chrome Extension. (CVE-2020-6530)

  - Side-channel information leakage in scroll to text in Google Chrome prior to 84.0.4147.89 allowed a remote     attacker to leak cross-origin data via a crafted HTML page. (CVE-2020-6531)

  - Use after free in SCTP in Google Chrome prior to 84.0.4147.105 allowed a remote attacker to potentially     exploit heap corruption via a crafted HTML page. (CVE-2020-6532)

  - Heap buffer overflow in WebRTC in Google Chrome prior to 84.0.4147.89 allowed a remote attacker to     potentially exploit heap corruption via a crafted HTML page. (CVE-2020-6534)

  - Insufficient data validation in WebUI in Google Chrome prior to 84.0.4147.89 allowed a remote attacker who     had compromised the renderer process to inject scripts or HTML into a privileged page via a crafted HTML     page. (CVE-2020-6535)

  - Incorrect security UI in PWAs in Google Chrome prior to 84.0.4147.89 allowed a remote attacker who had     persuaded the user to install a PWA to spoof the contents of the Omnibox (URL bar) via a crafted PWA.
    (CVE-2020-6536)

  - Type confusion in V8 in Google Chrome prior to 84.0.4147.105 allowed a remote attacker to execute     arbitrary code inside a sandbox via a crafted HTML page. (CVE-2020-6537)

  - Inappropriate implementation in WebView in Google Chrome on Android prior to 84.0.4147.105 allowed a     remote attacker to leak cross-origin data via a crafted HTML page. (CVE-2020-6538)

  - Use after free in CSS in Google Chrome prior to 84.0.4147.105 allowed a remote attacker to potentially     exploit heap corruption via a crafted HTML page. (CVE-2020-6539)

  - Buffer overflow in Skia in Google Chrome prior to 84.0.4147.105 allowed a remote attacker to potentially     exploit heap corruption via a crafted HTML page. (CVE-2020-6540)

  - Use after free in WebUSB in Google Chrome prior to 84.0.4147.105 allowed a remote attacker to potentially     exploit heap corruption via a crafted HTML page. (CVE-2020-6541)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote CentOS Linux 6 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2020:3387 advisory.

  - In Eclipse OpenJ9 prior to version 0.21 on Power platforms, calling the System.arraycopy method with a     length longer than the length of the source or destination array can, in certain specially crafted code     patterns, cause the current method to return prematurely with an undefined return value. This allows     whatever value happens to be in the return register at that time to be used as if it matches the method's     declared return type. (CVE-2019-17639)

  - Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: JSSE). Supported     versions that are affected are Java SE: 7u261, 8u251, 11.0.7 and 14.0.1; Java SE Embedded: 8u251.
    Difficult to exploit vulnerability allows unauthenticated attacker with network access via TLS to     compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized     read access to a subset of Java SE, Java SE Embedded accessible data. Note: Applies to client and server     deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and     sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component     without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web     service. (CVE-2020-14577)

  - Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: Libraries). Supported     versions that are affected are Java SE: 7u261 and 8u251; Java SE Embedded: 8u251. Difficult to exploit     vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise     Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized ability to     cause a partial denial of service (partial DOS) of Java SE, Java SE Embedded. Note: Applies to client and     server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start     applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the     specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as     through a web service. (CVE-2020-14578, CVE-2020-14579)

  - Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: Libraries). Supported     versions that are affected are Java SE: 7u261, 8u251, 11.0.7 and 14.0.1; Java SE Embedded: 8u251.
    Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple     protocols to compromise Java SE, Java SE Embedded. Successful attacks require human interaction from a     person other than the attacker and while the vulnerability is in Java SE, Java SE Embedded, attacks may     significantly impact additional products. Successful attacks of this vulnerability can result in takeover     of Java SE, Java SE Embedded. Note: This vulnerability applies to Java deployments, typically in clients     running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code     (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability     does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code     installed by an administrator). (CVE-2020-14583)

  - Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: 2D). Supported     versions that are affected are Java SE: 7u261, 8u251, 11.0.7 and 14.0.1; Java SE Embedded: 8u251. Easily     exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to     compromise Java SE, Java SE Embedded. Successful attacks require human interaction from a person other     than the attacker and while the vulnerability is in Java SE, Java SE Embedded, attacks may significantly     impact additional products. Successful attacks of this vulnerability can result in unauthorized creation,     deletion or modification access to critical data or all Java SE, Java SE Embedded accessible data. Note:
    This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start     applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the     internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java     deployments, typically in servers, that load and run only trusted code (e.g., code installed by an     administrator). (CVE-2020-14593)

  - Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: JAXP). Supported     versions that are affected are Java SE: 7u261, 8u251, 11.0.7 and 14.0.1; Java SE Embedded: 8u251. Easily     exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to     compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized     update, insert or delete access to some of Java SE, Java SE Embedded accessible data. Note: This     vulnerability can only be exploited by supplying data to APIs in the specified Component without using     Untrusted Java Web Start applications or Untrusted Java applets, such as through a web service.
    (CVE-2020-14621)

  - Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: Security). Supported     versions that are affected are Java SE: 7u241, 8u231, 11.0.5 and 13.0.1; Java SE Embedded: 8u231.
    Difficult to exploit vulnerability allows unauthenticated attacker with network access via Kerberos to     compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized     update, insert or delete access to some of Java SE, Java SE Embedded accessible data. Note: This     vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start     applications or sandboxed Java applets (in Java SE 8), that load and run untrusted code (e.g., code that     comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be     exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the     APIs. (CVE-2020-2590)

  - Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: Security). Supported     versions that are affected are Java SE: 7u241, 8u231, 11.0.5 and 13.0.1; Java SE Embedded: 8u231.
    Difficult to exploit vulnerability allows unauthenticated attacker with network access via Kerberos to     compromise Java SE, Java SE Embedded. While the vulnerability is in Java SE, Java SE Embedded, attacks may     significantly impact additional products. Successful attacks of this vulnerability can result in     unauthorized access to critical data or complete access to all Java SE, Java SE Embedded accessible data.
    Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web     Start applications or sandboxed Java applets (in Java SE 8), that load and run untrusted code (e.g., code     that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be     exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the     APIs. (CVE-2020-2601)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

ID	Name	Severity
235716	CentOS 9 : kernel-5.14.0-583.el9	medium
235376	CentOS 9 : kernel-5.14.0-582.el9	medium
234895	CentOS 9 : kernel-5.14.0-580.el9	medium
234322	CentOS 9 : kernel-5.14.0-578.el9	high
233578	CentOS 9 : kernel-5.14.0-575.el9	high
233298	CentOS 9 : kernel-5.14.0-573.el9	high
232849	CentOS 9 : kernel-5.14.0-572.el9	high
217011	CentOS 9 : libxml2-2.9.13-9.el9	high
217010	CentOS 9 : microcode_ctl-20250211-1.el9	high
216704	CentOS 9 : openssh-8.7p1-45.el9	medium
215234	CentOS 9 : gcc-11.5.0-5.el9	medium
215233	CentOS 9 : kernel-5.14.0-565.el9	high
214888	CentOS 9 : kernel-5.14.0-559.el9	high
214579	CentOS 9 : kernel-5.14.0-554.el9	high
213504	CentOS 9 : microcode_ctl-20241112-1.el9	high
213467	CentOS 9 : kernel-5.14.0-547.el9	high
213059	CentOS 9 : kernel-5.14.0-542.el9	high
212193	CentOS 9 : kernel-5.14.0-539.el9	medium
212094	CentOS 9 : kernel-5.14.0-536.el9	high
212093	CentOS 9 : tuned-2.24.0-2.el9	high
211829	CentOS 9 : kernel-5.14.0-533.el9	critical
211828	CentOS 9 : pam-1.5.1-23.el9	high
211516	CentOS 9 : kernel-5.14.0-529.el9	high
210768	CentOS 9 : expat-2.5.0-4.el9	medium
210767	CentOS 9 : kernel-5.14.0-527.el9	medium
208962	CentOS 9 : kernel-5.14.0-516.el9	high
208653	CentOS 7 : kpatch-patch (RHSA-2020:0028)	medium
208652	CentOS 7 : firefox (RHSA-2020:5561)	high
208651	CentOS 7 : kpatch-patch (RHSA-2021:3381)	high
208650	CentOS 7 : thunderbird (RHSA-2022:1302)	high
208649	CentOS 6 : kernel (RHSA-2020:3548)	critical
208648	CentOS 6 : chromium-browser (RHSA-2020:4235)	high
208647	CentOS 7 : qemu-kvm-ma (RHSA-2021:0346)	medium
208646	CentOS 7 : kernel-alt (RHSA-2021:0354)	high
208645	CentOS 6 : libexif (RHSA-2020:2516)	critical
208644	CentOS 7 : thunderbird (RHSA-2020:4163)	high
208643	CentOS 7 : kernel-alt (RHSA-2020:2104)	high
208642	CentOS 7 : java-1.7.1-ibm (RHSA-2021:3293)	medium
208641	CentOS 7 : qemu-kvm-ma (RHSA-2020:1209)	medium
208640	CentOS 7 : kernel-rt (RHSA-2021:3439)	high
208639	CentOS 7 : thunderbird (RHSA-2022:9079)	critical
208638	CentOS 7 : kernel (RHSA-2021:0336)	medium
208637	CentOS 7 : podman (RHSA-2020:2117)	high
208636	CentOS 7 : libwebp (RHSA-2021:2260)	critical
208635	CentOS 7 : libreoffice (RHSA-2024:3304)	high
208634	CentOS 7 : thunderbird (RHSA-2022:4730)	high
208633	CentOS 6 : thunderbird (RHSA-2020:5164)	high
208632	CentOS 7 : kernel-alt (RHSA-2020:5079)	medium
208631	CentOS 6 : chromium-browser (RHSA-2020:3377)	critical
208630	CentOS 6 : java-1.7.1-ibm (RHSA-2020:3387)	medium

Detections

Analytics

CentOS Local Security Checks Family for Nessus

medium

medium

medium

high

high

high

high

high

high

medium

medium

high

high

high

high

high

high

medium

high

high

critical

high

high

medium

medium

high

medium

high

high

high

critical

high

medium

high

critical

high

high

medium

medium

high

critical

medium

high

critical

high

high

high

medium

critical

medium