RHSA-2023:3491HighCVSS 8.2

Red Hat Security Advisory: Red Hat Virtualization Host 4.4.z SP 1 security update

Published
June 6, 2023
Last Modified
August 6, 2026

🔗 CVE IDs covered (6)

CVE-2022-3564 →CVE-2022-4378 →CVE-2022-38023 →CVE-2022-41222 →CVE-2023-0461 →CVE-2023-1668 →

📋 Description

CVE-2022-3564 — kernel: use-after-free caused by l2cap_reassemble_sdu() in net/bluetooth/l2cap_core.c CVE-2022-4378 — kernel: stack overflow in do_proc_dointvec and proc_skip_spaces CVE-2022-38023 — samba: RC4/HMAC-MD5 NetLogon Secure Channel is weak and should be avoided CVE-2022-41222 — kernel: mm/mremap.c use-after-free vulnerability CVE-2023-0461 — kernel: net/ulp: use-after-free in listening ULP sockets CVE-2023-1668 — openvswitch: ip proto 0 triggers incorrect handling

🎯 Affected products8

  • RHEL 8-based RHEV-H for RHEV 4 (build requirements)
  • Red Hat Virtualization 4 Hypervisor for RHEL 8
  • redhat-release-virtualization-host-0:4.5.3-7.el8ev.src as a component of RHEL 8-based RHEV-H for RHEV 4 (build requirements)
  • redhat-release-virtualization-host-0:4.5.3-7.el8ev.x86_64 as a component of RHEL 8-based RHEV-H for RHEV 4 (build requirements)
  • redhat-release-virtualization-host-content-0:4.5.3-7.el8ev.x86_64 as a component of RHEL 8-based RHEV-H for RHEV 4 (build requirements)
  • redhat-virtualization-host-0:4.5.3-202306050942_8.6.src as a component of Red Hat Virtualization 4 Hypervisor for RHEL 8
  • redhat-virtualization-host-image-update-0:4.5.3-202306050942_8.6.x86_64 as a component of Red Hat Virtualization 4 Hypervisor for RHEL 8
  • redhat-virtualization-host-image-update-placeholder-0:4.5.3-7.el8ev.noarch as a component of RHEL 8-based RHEV-H for RHEV 4 (build requirements)

✅ Remediation

For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/2974891 Workaround: To mitigate these vulnerabilities on the operating system level, disable the Bluetooth functionality via blocklisting kernel modules in the Linux kernel. The kernel modules can be prevented from being loaded by using system-wide modprobe rules. Instructions on how to disable Bluetooth modules are available on the Customer Portal at https://access.redhat.com/solutions/2682931. Alternatively, Bluetooth can be disabled within the hardware or at BIOS level which will also provide an effective mitigation as the kernel will not be able to detect that Bluetooth hardware is present on the system. Workaround: A possible workaround is preventing regular users from accessing sysctl files (such as /proc/sys/net/ipv4/tcp_rmem and similar). Also, preventing a user from increasing privileges with commands such as "unshare -rn" (that allows obtaining net namespace privileges required to access /proc/sys/net/ipv4/tcp_rmem). Workaround: Users can disable MD5-based NetLogon by adding the following snippet to their smb.conf ~~~ reject md5 clients = yes ~~~ in case there's still need to allow SMB to authenticate to MD5-based NetLogon servers, it's possible to explicitly enable it per-server based: ~~~ server reject md5 schannel:<SERVERNAME>$ = no ~~~ Workaround: To mitigate this issue, prevent module tls from being loaded. Please see https://access.redhat.com/solutions/41278 for how to blacklist a kernel module to prevent it from loading automatically. Workaround: For any version of Open vSwitch, preventing packets with network protocol number '0' from reaching Open vSwitch will prevent the issue. This is difficult to achieve because Open vSwitch obtains packets before the iptables or nftables host firewall, so iptables or nftables on the Open vSwitch host cannot ordinarily block the vulnerability. Another method would be to add a high priority flow to the flow table explicitly matching on nw protocol '0' and handling that traffic separately: table=0 priority=32768,ip,ip_proto=0 actions=drop This would need to be similarly done for IPv6 traffic as well.

🔗 References (9)