In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix locking in rxrpc's sendmsg Fix three bugs in the rxrpc's sendmsg implementation: (1) rxrpc_new_client_call() should release the socket lock when returning an error from rxrpc_get_call_slot(). (2) rxrpc_wait_for_tx_window_intr() will return without the call mutex held in the event that we're interrupted by a signal whilst waiting for tx space on the socket or relocking the call mutex afterwards. Fix this by: (a) moving the unlock/lock of the call mutex up to rxrpc_send_data() such that the lock is not held around all of rxrpc_wait_for_tx_window*() and (b) indicating to higher callers whether we're return with the lock dropped. Note that this means recvmsg() will not block on this call whilst we're waiting. (3) After dropping and regaining the call mutex, rxrpc_send_data() needs to go and recheck the state of the tx_pending buffer and the tx_total_len check in case we raced with another sendmsg() on the same call. Thinking on this some more, it might make sense to have different locks for sendmsg() and recvmsg(). There's probably no need to make recvmsg() wait for sendmsg(). It does mean that recvmsg() can return MSG_EOR indicating that a call is dead before a sendmsg() to that call returns - but that can currently happen anyway. Without fix (2), something like the following can be induced: WARNING: bad unlock balance detected! 5.16.0-rc6-syzkaller #0 Not tainted ------------------------------------- syz-executor011/3597 is trying to release lock (&call->user_mutex) at: [<ffffffff885163a3>] rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748 but there are no more locks to release! other info that might help us debug this: no locks held by syz-executor011/3597. ... Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_unlock_imbalance_bug include/trace/events/lock.h:58 [inline] __lock_release kernel/locking/lockdep.c:5306 [inline] lock_release.cold+0x49/0x4e kernel/locking/lockdep.c:5657 __mutex_unlock_slowpath+0x99/0x5e0 kernel/locking/mutex.c:900 rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748 rxrpc_sendmsg+0x420/0x630 net/rxrpc/af_rxrpc.c:561 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:724 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409 ___sys_sendmsg+0xf3/0x170 net/socket.c:2463 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae [Thanks to Hawkins Jiawei and Khalid Masum for their attempts to fix this]

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2025-992846 advisory.

    In the Linux kernel, the following vulnerability has been resolved:

    rxrpc: Fix locking in rxrpc's sendmsg

    Fix three bugs in the rxrpc's sendmsg implementation:

     (1) rxrpc_new_client_call() should release the socket lock when returning          an error from rxrpc_get_call_slot().

     (2) rxrpc_wait_for_tx_window_intr() will return without the call mutex          held in the event that we're interrupted by a signal whilst waiting          for tx space on the socket or relocking the call mutex afterwards.

         Fix this by: (a) moving the unlock/lock of the call mutex up to          rxrpc_send_data() such that the lock is not held around all of          rxrpc_wait_for_tx_window*() and (b) indicating to higher callers          whether we're return with the lock dropped.  Note that this means          recvmsg() will not block on this call whilst we're waiting.

     (3) After dropping and regaining the call mutex, rxrpc_send_data() needs          to go and recheck the state of the tx_pending buffer and the          tx_total_len check in case we raced with another sendmsg() on the same          call.

    Thinking on this some more, it might make sense to have different locks for     sendmsg() and recvmsg().  There's probably no need to make recvmsg() wait     for sendmsg().  It does mean that recvmsg() can return MSG_EOR indicating     that a call is dead before a sendmsg() to that call returns - but that can     currently happen anyway.

    Without fix (2), something like the following can be induced:

            WARNING: bad unlock balance detected!             5.16.0-rc6-syzkaller #0 Not tainted
            -------------------------------------             syz-executor011/3597 is trying to release lock (&call->user_mutex) at:
            [<ffffffff885163a3>] rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748             but there are no more locks to release!

            other info that might help us debug this:
            no locks held by syz-executor011/3597.
            ...
            Call Trace:
             <TASK>
             __dump_stack lib/dump_stack.c:88 [inline]              dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106              print_unlock_imbalance_bug include/trace/events/lock.h:58 [inline]
             __lock_release kernel/locking/lockdep.c:5306 [inline]              lock_release.cold+0x49/0x4e kernel/locking/lockdep.c:5657
             __mutex_unlock_slowpath+0x99/0x5e0 kernel/locking/mutex.c:900              rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748              rxrpc_sendmsg+0x420/0x630 net/rxrpc/af_rxrpc.c:561              sock_sendmsg_nosec net/socket.c:704 [inline]              sock_sendmsg+0xcf/0x120 net/socket.c:724
             ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409
             ___sys_sendmsg+0xf3/0x170 net/socket.c:2463
             __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492              do_syscall_x64 arch/x86/entry/common.c:50 [inline]              do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80              entry_SYSCALL_64_after_hwframe+0x44/0xae

    [Thanks to Hawkins Jiawei and Khalid Masum for their attempts to fix this]

Tenable has extracted the preceding description block directly from the Unity Linux security advisory.

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

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2025-992357 advisory.

    In the Linux kernel, the following vulnerability has been resolved:

    rxrpc: Fix locking in rxrpc's sendmsg

    Fix three bugs in the rxrpc's sendmsg implementation:

     (1) rxrpc_new_client_call() should release the socket lock when returning          an error from rxrpc_get_call_slot().

     (2) rxrpc_wait_for_tx_window_intr() will return without the call mutex          held in the event that we're interrupted by a signal whilst waiting          for tx space on the socket or relocking the call mutex afterwards.

         Fix this by: (a) moving the unlock/lock of the call mutex up to          rxrpc_send_data() such that the lock is not held around all of          rxrpc_wait_for_tx_window*() and (b) indicating to higher callers          whether we're return with the lock dropped.  Note that this means          recvmsg() will not block on this call whilst we're waiting.

     (3) After dropping and regaining the call mutex, rxrpc_send_data() needs          to go and recheck the state of the tx_pending buffer and the          tx_total_len check in case we raced with another sendmsg() on the same          call.

    Thinking on this some more, it might make sense to have different locks for     sendmsg() and recvmsg().  There's probably no need to make recvmsg() wait     for sendmsg().  It does mean that recvmsg() can return MSG_EOR indicating     that a call is dead before a sendmsg() to that call returns - but that can     currently happen anyway.

    Without fix (2), something like the following can be induced:

            WARNING: bad unlock balance detected!             5.16.0-rc6-syzkaller #0 Not tainted
            -------------------------------------             syz-executor011/3597 is trying to release lock (&call->user_mutex) at:
            [<ffffffff885163a3>] rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748             but there are no more locks to release!

            other info that might help us debug this:
            no locks held by syz-executor011/3597.
            ...
            Call Trace:
             <TASK>
             __dump_stack lib/dump_stack.c:88 [inline]              dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106              print_unlock_imbalance_bug include/trace/events/lock.h:58 [inline]
             __lock_release kernel/locking/lockdep.c:5306 [inline]              lock_release.cold+0x49/0x4e kernel/locking/lockdep.c:5657
             __mutex_unlock_slowpath+0x99/0x5e0 kernel/locking/mutex.c:900              rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748              rxrpc_sendmsg+0x420/0x630 net/rxrpc/af_rxrpc.c:561              sock_sendmsg_nosec net/socket.c:704 [inline]              sock_sendmsg+0xcf/0x120 net/socket.c:724
             ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409
             ___sys_sendmsg+0xf3/0x170 net/socket.c:2463
             __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492              do_syscall_x64 arch/x86/entry/common.c:50 [inline]              do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80              entry_SYSCALL_64_after_hwframe+0x44/0xae

    [Thanks to Hawkins Jiawei and Khalid Masum for their attempts to fix this]

Tenable has extracted the preceding description block directly from the Unity Linux security advisory.

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

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - rxrpc: Fix locking in rxrpc's sendmsg Fix three bugs in the rxrpc's sendmsg implementation: (1)     rxrpc_new_client_call() should release the socket lock when returning an error from rxrpc_get_call_slot().
    (2) rxrpc_wait_for_tx_window_intr() will return without the call mutex held in the event that we're     interrupted by a signal whilst waiting for tx space on the socket or relocking the call mutex afterwards.
    Fix this by: (a) moving the unlock/lock of the call mutex up to rxrpc_send_data() such that the lock is     not held around all of rxrpc_wait_for_tx_window*() and (b) indicating to higher callers whether we're     return with the lock dropped. Note that this means recvmsg() will not block on this call whilst we're     waiting. (3) After dropping and regaining the call mutex, rxrpc_send_data() needs to go and recheck the     state of the tx_pending buffer and the tx_total_len check in case we raced with another sendmsg() on the     same call. Thinking on this some more, it might make sense to have different locks for sendmsg() and     recvmsg(). There's probably no need to make recvmsg() wait for sendmsg(). It does mean that recvmsg() can     return MSG_EOR indicating that a call is dead before a sendmsg() to that call returns - but that can     currently happen anyway. Without fix (2), something like the following can be induced: WARNING: bad unlock     balance detected! 5.16.0-rc6-syzkaller #0 Not tainted ------------------------------------- syz-     executor011/3597 is trying to release lock (&call->user_mutex) at: [<ffffffff885163a3>]     rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748 but there are no more locks to release! other info     that might help us debug this: no locks held by syz-executor011/3597. ... Call Trace: <TASK> __dump_stack     lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_unlock_imbalance_bug     include/trace/events/lock.h:58 [inline] __lock_release kernel/locking/lockdep.c:5306 [inline]     lock_release.cold+0x49/0x4e kernel/locking/lockdep.c:5657 __mutex_unlock_slowpath+0x99/0x5e0     kernel/locking/mutex.c:900 rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748 rxrpc_sendmsg+0x420/0x630     net/rxrpc/af_rxrpc.c:561 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg+0xcf/0x120     net/socket.c:724 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409 ___sys_sendmsg+0xf3/0x170 net/socket.c:2463
    __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492 do_syscall_x64 arch/x86/entry/common.c:50 [inline]     do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae [Thanks to     Hawkins Jiawei and Khalid Masum for their attempts to fix this] (CVE-2022-49998)

Note that Nessus relies on the presence of the package as reported by the vendor.

The remote Redhat Enterprise Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2023:2458 advisory.

    The kernel packages contain the Linux kernel, the core of any Linux operating system.

    Security Fix(es):

    * use-after-free in l2cap_connect and l2cap_le_connect_req in net/bluetooth/l2cap_core.c (CVE-2022-42896)

    * net/ulp: use-after-free in listening ULP sockets (CVE-2023-0461)

    * cpu: AMD CPUs may transiently execute beyond unconditional direct branch (CVE-2021-26341)

    * malicious data for FBIOPUT_VSCREENINFO ioctl may cause OOB write memory (CVE-2021-33655)

    * possible race condition in drivers/tty/tty_buffers.c (CVE-2022-1462)

    * KVM: NULL pointer dereference in kvm_mmu_invpcid_gva (CVE-2022-1789)

    * use-after-free in free_pipe_info() could lead to privilege escalation (CVE-2022-1882)

    * KVM: nVMX: missing IBPB when exiting from nested guest can lead to Spectre v2 attacks (CVE-2022-2196)

    * netfilter: nf_conntrack_irc message handling issue (CVE-2022-2663)

    * race condition in xfrm_probe_algs can lead to OOB read/write (CVE-2022-3028)

    * out-of-bounds read in fib_nh_match of the file net/ipv4/fib_semantics.c (CVE-2022-3435)

    * race condition in hugetlb_no_page() in mm/hugetlb.c (CVE-2022-3522)

    * memory leak in ipv6_renew_options() (CVE-2022-3524)

    * data races around icsk->icsk_af_ops in do_ipv6_setsockopt (CVE-2022-3566)

    * data races around sk->sk_prot (CVE-2022-3567)

    * memory leak in l2cap_recv_acldata of the file net/bluetooth/l2cap_core.c (CVE-2022-3619)

    * denial of service in follow_page_pte in mm/gup.c due to poisoned pte entry (CVE-2022-3623)

    * use-after-free after failed devlink reload in devlink_param_get (CVE-2022-3625)

    * USB-accessible buffer overflow in brcmfmac (CVE-2022-3628)

    * use after free flaw in l2cap_conn_del in net/bluetooth/l2cap_core.c (CVE-2022-3640)

    * Double-free in split_2MB_gtt_entry when function intel_gvt_dma_map_guest_page failed (CVE-2022-3707)

    * mptcp: NULL pointer dereference in subflow traversal at disconnect time (CVE-2022-4128)

    * l2tp: missing lock when clearing sk_user_data can lead to NULL pointer dereference (CVE-2022-4129)

    * igmp: use-after-free in ip_check_mc_rcu when opening and closing inet sockets (CVE-2022-20141)

    * lockdown bypass using IMA (CVE-2022-21505)

    * double free in usb_8dev_start_xmit in drivers/net/can/usb/usb_8dev.c (CVE-2022-28388)

    * network backend may cause Linux netfront to use freed SKBs (XSA-405) (CVE-2022-33743)

    * unmap_mapping_range() race with munmap() on VM_PFNMAP mappings leads to stale TLB entry (CVE-2022-39188)

    * TLB flush operations are mishandled in certain KVM_VCPU_PREEMPTED leading to guest malfunctioning     (CVE-2022-39189)

    * u8 overflow problem in cfg80211_update_notlisted_nontrans() (CVE-2022-41674)

    * use-after-free related to leaf anon_vma double reuse (CVE-2022-42703)

    * use-after-free in bss_ref_get in net/wireless/scan.c (CVE-2022-42720)

    * BSS list corruption in cfg80211_add_nontrans_list in net/wireless/scan.c (CVE-2022-42721)

    * Denial of service in beacon protection for P2P-device (CVE-2022-42722)

    * memory corruption in usbmon driver (CVE-2022-43750)

    * NULL pointer dereference in traffic control subsystem (CVE-2022-47929)

    * NULL pointer dereference in rawv6_push_pending_frames (CVE-2023-0394)

    * use-after-free due to race condition in qdisc_graft() (CVE-2023-0590)

    * use-after-free caused by invalid pointer hostname in fs/cifs/connect.c (CVE-2023-1195)

    * denial of service in tipc_conn_close (CVE-2023-1382)

    For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and     other related information, refer to the CVE page(s) listed in the References section.

    Additional Changes:

    For detailed information on changes in this release, see the Red Hat Enterprise Linux 9.2 Release Notes     linked from the References section.

Tenable has extracted the preceding description block directly from the Red Hat Enterprise Linux security advisory.

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

The version of kernel installed on the remote host is prior to 5.10.144-127.601. It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2KERNEL-5.10-2022-020 advisory.

    In the Linux kernel, the following vulnerability has been resolved:

    i2c: Fix a potential use after free

    Free the adap structure only after we are done using it.This patch just moves the put_device() down a bit     to avoid theuse after free.

    [wsa: added comment to the code, added Fixes tag] (CVE-2019-25162)

    In the Linux kernel, the following vulnerability has been resolved:

    tun: avoid double free in tun_free_netdev (CVE-2021-47082)

    A use-after-free flaw was found in the Linux kernel's Atheros wireless adapter driver in the way a user     forces the ath9k_htc_wait_for_target function to fail with some input messages. This flaw allows a local     user to crash or potentially escalate their privileges on the system. (CVE-2022-1679)

    A flaw was found in the Linux kernel's KVM when attempting to set a SynIC IRQ. This issue makes it     possible for a misbehaving VMM to write to SYNIC/STIMER MSRs, causing a NULL pointer dereference. This     flaw allows an unprivileged local attacker on the host to issue specific ioctl calls, causing a kernel     oops condition that results in a denial of service. (CVE-2022-2153)

    A use-after-free flaw was found in the Linux kernel's POSIX CPU timers functionality in the way a user     creates and then deletes the timer in the non-leader thread of the program. This flaw allows a local user     to crash or potentially escalate their privileges on the system. (CVE-2022-2585)

    It was discovered that a nft object or expression could reference a nft set on a different nft table,     leading to a use-after-free once that table was deleted. (CVE-2022-2586)

    A use-after-free flaw was found in route4_change in the net/sched/cls_route.c filter implementation in the     Linux kernel. This flaw allows a local user to crash the system and possibly lead to a local privilege     escalation problem. (CVE-2022-2588)

    Non-transparent sharing of return predictor targets between contexts in some Intel(R) Processors may allow     an authorized user to potentially enable information disclosure via local access. (CVE-2022-26373)

    An issue was found in the Linux kernel in nf_conntrack_irc where the message handling can be confused and     incorrectly matches the message. A firewall may be able to be bypassed when users are using unencrypted     IRC with nf_conntrack_irc configured. (CVE-2022-2663)

    An out-of-bounds memory read flaw was found in the Linux kernel's BPF subsystem in how a user calls the     bpf_tail_call function with a key larger than the max_entries of the map. This flaw allows a local user to     gain unauthorized access to data. (CVE-2022-2905)

    A race condition was found in the Linux kernel's IP framework for transforming packets (XFRM subsystem)     when multiple calls to xfrm_probe_algs occurred simultaneously. This flaw could allow a local attacker to     potentially trigger an out-of-bounds write or leak kernel heap memory by performing an out-of-bounds read     and copying it into a socket. (CVE-2022-3028)

    A use-after-free flaw was found in io_uring in the Linux kernel. This flaw allows a local user to trigger     the issue if a signalfd or binder fd is polled with the io_uring poll due to a lack of io_uring POLLFREE     handling. (CVE-2022-3176)

    A vulnerability was found in Linux Kernel. It has been classified as critical. This affects the function     devlink_param_set/devlink_param_get of the file net/core/devlink.c of the component IPsec. The     manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The identifier     VDB-211929 was assigned to this vulnerability. (CVE-2022-3625)

    An issue was discovered in include/asm-generic/tlb.h in the Linux kernel before 5.19. Because of a race     condition (unmap_mapping_range versus munmap), a device driver can free a page while it still has stale     TLB entries. This only occurs in situations with VM_PFNMAP VMAs. (CVE-2022-39188)

    An issue was discovered in net/netfilter/nf_tables_api.c in the Linux kernel before 5.19.6. A denial of     service can occur upon binding to an already bound chain. (CVE-2022-39190)

    A race condition in the Linux kernel's EFI capsule loader driver was found in the way it handled write and     flush operations on the device node of the EFI capsule. A local user could potentially use this flaw to     crash the system. (CVE-2022-40307)

    mm/mremap.c in the Linux kernel before 5.13.3 has a use-after-free via a stale TLB because an rmap lock is     not held during a PUD move. (CVE-2022-41222)

    A double-free flaw was found in the Linux kernel's TUN/TAP device driver functionality in how a user     registers the device when the register_netdevice function fails (NETDEV_REGISTER notifier). This flaw     allows a local user to crash or potentially escalate their privileges on the system. (CVE-2022-4744)

    In the Linux kernel, the following vulnerability has been resolved:

    IB/core: Fix a nested dead lock as part of ODP flow (CVE-2022-48675)

    In the Linux kernel, the following vulnerability has been resolved:

    nvme-tcp: fix UAF when detecting digest errors (CVE-2022-48686)

    In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: fix out-of-bounds read when     setting HMAC data. The SRv6 layer allows defining HMAC data that can later be used to sign IPv6 Segment     Routing Headers. This configuration is realised via netlink through four attributes: SEG6_ATTR_HMACKEYID,     SEG6_ATTR_SECRET, SEG6_ATTR_SECRETLEN and SEG6_ATTR_ALGID. (CVE-2022-48687)

    In the Linux kernel, the following vulnerability has been resolved:

    i40e: Fix kernel crash during module removal (CVE-2022-48688)

    In the Linux kernel, the following vulnerability has been resolved:

    netfilter: nf_tables: clean up hook list when offload flags check fails (CVE-2022-48691)

    In the Linux kernel, the following vulnerability has been resolved:

    scsi: mpt3sas: Fix use-after-free warning (CVE-2022-48695)

    In the Linux kernel, the following vulnerability has been resolved:

    nvmet: fix a use-after-free (CVE-2022-48697)

    In the Linux kernel, the following vulnerability has been resolved:

    drm/radeon: add a force flush to delay work when radeon (CVE-2022-48704)

    In the Linux kernel, the following vulnerability has been resolved:

    sched/fair: Fix fault in reweight_entity (CVE-2022-48921)

    In the Linux kernel, the following vulnerability has been resolved:

    tcp: Fix data-races around sysctl_tcp_l3mdev_accept. (CVE-2022-49599)

    In the Linux kernel, the following vulnerability has been resolved:

    USB: core: Prevent nested device-reset calls (CVE-2022-49936)

    In the Linux kernel, the following vulnerability has been resolved:

    vt: Clear selection before changing the font (CVE-2022-49948)

    In the Linux kernel, the following vulnerability has been resolved:

    net/sched: fix netdevice reference leaks in attach_default_qdiscs() (CVE-2022-49958)

    In the Linux kernel, the following vulnerability has been resolved:

    arm64: cacheinfo: Fix incorrect assignment of signed error value to unsigned fw_level (CVE-2022-49964)

    In the Linux kernel, the following vulnerability has been resolved:

    bpf: Don't redirect packets with invalid pkt_len (CVE-2022-49975)

    In the Linux kernel, the following vulnerability has been resolved:

    ftrace: Fix NULL pointer dereference in is_ftrace_trampoline when ftrace is dead (CVE-2022-49977)

    In the Linux kernel, the following vulnerability has been resolved:

    net: fix refcount bug in sk_psock_get (2) (CVE-2022-49979)

    In the Linux kernel, the following vulnerability has been resolved:

    HID: hidraw: fix memory leak in hidraw_release() (CVE-2022-49981)

    In the Linux kernel, the following vulnerability has been resolved:

    HID: steam: Prevent NULL pointer dereference in steam_{recv,send}_report (CVE-2022-49984)

    In the Linux kernel, the following vulnerability has been resolved:

    bpf: Don't use tnum_range on array range checking for poke descriptors (CVE-2022-49985)

    In the Linux kernel, the following vulnerability has been resolved:

    scsi: storvsc: Remove WQ_MEM_RECLAIM from storvsc_error_wq (CVE-2022-49986)

    In the Linux kernel, the following vulnerability has been resolved:

    md: call __md_stop_writes in md_stop (CVE-2022-49987)

    In the Linux kernel, the following vulnerability has been resolved:

    xen/privcmd: fix error exit of privcmd_ioctl_dm_op() (CVE-2022-49989)

    In the Linux kernel, the following vulnerability has been resolved:

    loop: Check for overflow while configuring loop (CVE-2022-49993)

    In the Linux kernel, the following vulnerability has been resolved:

    rxrpc: Fix locking in rxrpc's sendmsg (CVE-2022-49998)

    In the Linux kernel, the following vulnerability has been resolved:

    xfrm: policy: fix metadata dst->dev xmit null pointer dereference (CVE-2022-50004)

    In the Linux kernel, the following vulnerability has been resolved:

    NFSv4.2 fix problems with __nfs42_ssc_open (CVE-2022-50006)

    In the Linux kernel, the following vulnerability has been resolved:

    xfrm: fix refcount leak in __xfrm_policy_check() (CVE-2022-50007)

    In the Linux kernel, the following vulnerability has been resolved:

    kprobes: don't call disarm_kprobe() for disabled kprobes (CVE-2022-50008)

    In the Linux kernel, the following vulnerability has been resolved:

    drivers:md:fix a potential use-after-free bug (CVE-2022-50022)

    In the Linux kernel, the following vulnerability has been resolved:

    scsi: lpfc: Prevent buffer overflow crashes in debugfs with malformed user input (CVE-2022-50030)

    In the Linux kernel, the following vulnerability has been resolved:

    net: genl: fix error path memory leak in policy dumping (CVE-2022-50042)

    In the Linux kernel, the following vulnerability has been resolved:

    iavf: Fix adminq error handling (CVE-2022-50055)

    In the Linux kernel, the following vulnerability has been resolved:

    ceph: don't leak snap_rwsem in handle_cap_grant (CVE-2022-50059)

    In the Linux kernel, the following vulnerability has been resolved:

    virtio_net: fix memory leak inside XPD_TX with mergeable (CVE-2022-50065)

    In the Linux kernel, the following vulnerability has been resolved:

    NFSv4/pnfs: Fix a use-after-free bug in open (CVE-2022-50072)

    In the Linux kernel, the following vulnerability has been resolved:

    ext4: fix warning in ext4_iomap_begin as race between bmap and write (CVE-2022-50082)

    In the Linux kernel, the following vulnerability has been resolved:

    ext4: add EXT4_INODE_HAS_XATTR_SPACE macro in xattr.h (CVE-2022-50083)

    In the Linux kernel, the following vulnerability has been resolved:

    dm raid: fix address sanitizer warning in raid_status (CVE-2022-50084)

    In the Linux kernel, the following vulnerability has been resolved:

    dm raid: fix address sanitizer warning in raid_resume (CVE-2022-50085)

    In the Linux kernel, the following vulnerability has been resolved:

    firmware: arm_scpi: Ensure scpi_info is not assigned if the probe fails (CVE-2022-50087)

    In the Linux kernel, the following vulnerability has been resolved:

    dm thin: fix use-after-free crash in dm_sm_register_threshold_callback (CVE-2022-50092)

    In the Linux kernel, the following vulnerability has been resolved:

    iommu/vt-d: avoid invalid memory access via node_online(NUMA_NO_NODE) (CVE-2022-50093)

    In the Linux kernel, the following vulnerability has been resolved:

    posix-cpu-timers: Cleanup CPU timers before freeing them during exec (CVE-2022-50095)

    In the Linux kernel, the following vulnerability has been resolved:

    video: fbdev: s3fb: Check the size of screen before memset_io() (CVE-2022-50097)

    In the Linux kernel, the following vulnerability has been resolved:

    sched, cpuset: Fix dl_cpu_busy() panic due to empty cs->cpus_allowed (CVE-2022-50103)

    In the Linux kernel, the following vulnerability has been resolved:

    jbd2: fix assertion 'jh->b_frozen_data == NULL' failure when journal aborted (CVE-2022-50126)

    In the Linux kernel, the following vulnerability has been resolved:

    RDMA/rxe: Fix error unwind in rxe_create_qp() (CVE-2022-50127)

    In the Linux kernel, the following vulnerability has been resolved:

    RDMA/srpt: Fix a use-after-free (CVE-2022-50129)

    In the Linux kernel, the following vulnerability has been resolved:

    RDMA/qedr: Fix potential memory leak in __qedr_alloc_mr() (CVE-2022-50138)

    In the Linux kernel, the following vulnerability has been resolved:

    driver core: fix potential deadlock in __driver_attach (CVE-2022-50149)

    In the Linux kernel, the following vulnerability has been resolved:

    usb: host: Fix refcount leak in ehci_hcd_ppc_of_probe (CVE-2022-50153)

    In the Linux kernel, the following vulnerability has been resolved:

    virtio-gpu: fix a missing check to avoid NULL dereference (CVE-2022-50181)

    In the Linux kernel, the following vulnerability has been resolved:

    drm/radeon: fix potential buffer overflow in ni_set_mc_special_registers() (CVE-2022-50185)

    In the Linux kernel, the following vulnerability has been resolved:

    regulator: of: Fix refcount leak bug in of_get_regulation_constraints() (CVE-2022-50191)

    In the Linux kernel, the following vulnerability has been resolved:

    selinux: Add boundary check in put_entry() (CVE-2022-50200)

    In the Linux kernel, the following vulnerability has been resolved:

    PM: hibernate: defer device probing when resuming from hibernation (CVE-2022-50202)

    In the Linux kernel, the following vulnerability has been resolved:

    ext2: Add more validity checks for inode counts (CVE-2022-50205)

    In the Linux kernel, the following vulnerability has been resolved:

    arm64: fix oops in concurrently setting insn_emulation sysctls (CVE-2022-50206)

    In the Linux kernel, the following vulnerability has been resolved:

    md-raid10: fix KASAN warning (CVE-2022-50211)

    In the Linux kernel, the following vulnerability has been resolved:

    netfilter: nf_tables: do not allow CHAIN_ID to refer to another table (CVE-2022-50212)

    In the Linux kernel, the following vulnerability has been resolved:

    netfilter: nf_tables: do not allow SET_ID to refer to another table (CVE-2022-50213)

    In the Linux kernel, the following vulnerability has been resolved:

    scsi: sg: Allow waiting for commands to complete on removed device (CVE-2022-50215)

    In the Linux kernel, the following vulnerability has been resolved:

    bpf: Fix KASAN use-after-free Read in compute_effective_progs (CVE-2022-50219)

    In the Linux kernel, the following vulnerability has been resolved:

    usbnet: Fix linkwatch use-after-free on disconnect (CVE-2022-50220)

    In the Linux kernel, the following vulnerability has been resolved:

    tty: vt: initialize unicode screen buffer (CVE-2022-50222)

    In the Linux kernel, the following vulnerability has been resolved:

    KVM: SVM: Don't BUG if userspace injects an interrupt with GIF=0 (CVE-2022-50228)

    In the Linux kernel, the following vulnerability has been resolved:

    crypto: arm64/poly1305 - fix a read out-of-bound (CVE-2022-50231)

    In nf_tables_updtable, if nf_tables_table_enable returns an error, nft_trans_destroy is called to free the     transaction object. nft_trans_destroy() calls list_del(), but the transaction was never placed on a list
    -- the list head is all zeroes, this results in a NULL pointer dereference. (CVE-2023-1095)

    The upstream advisory describes this issue as follows:

    This vulnerability allows local attackers to disclose sensitive information on affected installations of     the Linux Kernel. An attacker must first obtain the ability to execute high-privileged code on the target     system in order to exploit this vulnerability.

    The specific flaw exists within the processing of seg6 attributes. The issue results from the lack of     proper validation of user-supplied data, which can result in a read past the end of an allocated buffer.
    An attacker can leverage this in conjunction with other vulnerabilties to escalate privileges and execute     arbitrary code in the context of the kernel. (CVE-2023-2860)

Tenable has extracted the preceding description block directly from the tested product security advisory.

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

ID	Name	Product	Family	Severity
281175	Unity Linux 20.1060a / 20.1070a Security Update: kernel (UTSA-2025-992846)	Nessus	Unity Linux Local Security Checks	medium
280568	Unity Linux 20.1060e / 20.1070e Security Update: kernel (UTSA-2025-992357)	Nessus	Unity Linux Local Security Checks	medium
244267	Linux Distros Unpatched Vulnerability : CVE-2022-49998	Nessus	Misc.	medium
175477	RHEL 9 : kernel (RHSA-2023:2458)	Nessus	Red Hat Local Security Checks	high
166124	Amazon Linux 2 : kernel, --advisory ALAS2KERNEL-5.10-2022-020 (ALASKERNEL-5.10-2022-020)	Nessus	Amazon Linux Local Security Checks	high
166118	Amazon Linux 2 : kernel, --advisory ALAS2KERNEL-5.15-2022-008 (ALASKERNEL-5.15-2022-008)	Nessus	Amazon Linux Local Security Checks	high

Detections

Analytics

CVE-2022-49998

medium

Tenable Plugins

medium

medium

medium

high

high

high