There are also two out-of-bounds write vulnerabilities in the AMD Radeon user mode driver for DirectX 11.

Wednesday, April 10, 2024 12:56

Cisco Talos’ Vulnerability Research team has disclosed 10 vulnerabilities over the past three weeks, including four in a line of TP-Link routers, one of which could allow an attacker to reset the devices’ settings back to the factory default. 

A popular open-source software for internet-of-things (IoT) and industrial control systems (ICS) networks also contains multiple vulnerabilities that could be used to arbitrarily create new files on the affected systems or overwrite existing ones. 

For Snort coverage that can detect the exploitation of these vulnerabilities, download the latest rule sets from Snort.org, and our latest Vulnerability Advisories are always posted on Talos Intelligence’s website.  

**Denial-of-service, remote code execution vulnerabilities in TP-Link AC1350 router **

Talos researchers recently discovered four vulnerabilities in the TP-Link AC1350 wireless router. The AC1350 is one of many routers TP-Link produces and is designed to be used on home networks. 

TALOS-2023-1861 (CVE-2023-49074) is a denial-of-service vulnerability in the TP-Link Device Debug Protocol (TDDP). An attacker could exploit this vulnerability by sending a series of unauthenticated packets to the router, potentially causing a denial of service and forcing the device to reset to its factory settings.  

However, the TDDP protocol is only denial of serviceavailable for roughly 15 minutes after a device reboot.  

The TDDP protocol is also vulnerable to TALOS-2023-1862 (CVE-2023-49134 and CVE-2023-49133), a command execution vulnerability that could allow an attacker to execute arbitrary code on the targeted device. 

There is another remote code execution vulnerability, TALOS-2023-1888 (CVE-2023-49912, CVE-2023-49909, CVE-2023-49907, CVE-2023-49908, CVE-2023-49910, CVE-2023-49906, CVE-2023-49913, CVE-2023-49911) that is triggered if an attacker sends an authenticated HTTP request to the targeted device. This exploit includes multiple CVEs because an attacker could overflow multiple buffers to cause this condition. 

TALOS-2023-1864 (CVE-2023-48724) also exists in the device’s web interface functionality. An adversary could exploit this vulnerability by sending an unauthenticated HTTP request to the targeted device, thus causing a denial of service. 

**Multiple vulnerabilities in OAS Platform **

_Discovered by Jared Rittle._ 

Open Automation Software’s OAS Platform is an IoT gateway and protocol bus. It allows administrators to connect PLCs, devices, databases and custom apps. 

There are two vulnerabilities — TALOS-2024-1950 (CVE-2024-21870) and TALOS-2024-1951 (CVE-2024-22178) — that exist in the platform that can lead to arbitrary file creation or overwrite. An attacker can send a sequence of requests to trigger these vulnerabilities.  

An adversary could also send a series of requests to exploit TALOS-2024-1948 (CVE-2024-24976), but in this case, the vulnerability leads to a denial of service. 

An improper input validation vulnerability (TALOS-2024-1949/CVE-2024-27201) also exists in the OAS Engine User Configuration functionality that could lead to unexpected data in the configuration, including possible decoy usernames that contain characters not usually allowed by the software’s configuration. 

**Arbitrary write vulnerabilities in AMD graphics driver **

_Discovered by Piotr Bania._ 

There are two out-of-bounds write vulnerabilities in the AMD Radeon user mode driver for DirectX 11. TALOS-2023-1847 and TALOS-2023-1848 could allow an attacker with access to a malformed shader to potentially achieve arbitrary code execution after causing an out-of-bounds write. 

AMD graphics drivers are software that allows graphics processing units (GPUs) to communicate with the operating system.  

These vulnerabilities could be triggered from guest machines running virtualization environments to perform guest-to-host escape. Theoretically, an adversary could also exploit these issues from a web browser. Talos has demonstrated with past, similar, vulnerabilities that they could be triggered from HYPER-V guest using the RemoteFX feature, leading to executing the vulnerable code on the HYPER-V host.

Vulnerability in some TP-Link routers could lead to factory reset

In confidential computing environments, attestation is crucial in verifying the trustworthiness of the location where you plan to run your workload or where you plan to send confidential information. Before actually running the workload or transmitting the confidential information, you need to perform attestation.This blog provides an overview of the components implemented in the confidential containers (CoCo) to support the IETF RATS model (Remote ATtestation procedureS Architecture). The components include the Attestation Service (AS), Key Broker Service (KBS), Reference Value Provider Servi

In confidential computing environments, _attestation_ is crucial in verifying the trustworthiness of the location where you plan to run your workload or where you plan to send confidential information. Before actually running the workload or transmitting the confidential information, you need to perform **attestation**.

This blog provides an overview of the components implemented in the confidential containers (CoCo) to support the IETF RATS model **(Remote ATtestation procedureS Architecture)**. The components include the Attestation Service (AS), Key Broker Service (KBS), Reference Value Provider Service (RVPS), Attestation Agent (AA), and Confidential Data Hub (CDH). The AS, KBS, and RVPS components are part of the Trustee project, whereas the AA and CDH are part of the guest-components project in CoCo.

We begin by introducing the RATS model and its components. After that, we discuss the Trustee project, its various components, and how they relate to the RATS model. Finally, we present a few use cases that demonstrate the usage of the CoCo Trustee and guest-components project.

**RATS architecture and key components**

The key components in the RATS architecture are described in the following diagram:

*   **Attester** - provides **Evidence**, which is evaluated and appraised to decide its trustworthiness (for instance, a test to see whether it’s authorized to perform some action). Evidence may include configuration data, measurements, telemetry, or inferences.
*   **Verifier** - evaluates the validity of the evidence received from the attester and produces **attestation results**, which are sent to the Relying party. Attestation results typically include information regarding the Attester, while the Verifier vouches for the validity of the results.
*   **Relying party** - depends on the validity of information originating from the attester for reliably applying an action. This information can come from the verifier or directly through the attester.
*   **Relying party owner** - authorized to configure the appraisal policy that the **relying party** will use when receiving the attestation results (such as admin).
*   **Verifier owner** - authorized to configure the appraisal policy the **verifier** will use when receiving the evidence.
*   **Endorser** - for us, the hardware manufacturer who provides an **endorsement**, which the **verifier** uses to validate the evidence received from the attester. The endorsement is a secure statement the Endorser vouches for on the integrity of an Attester's various capabilities
*   **Reference Value Provider** - for us the hardware manufacturer who provides **reference values**, which the verifier uses to verify that claims were recorded by the attester. Reference values are, for example, golden measurements or nominal values.

In practice, the data flow between the verifier, attester, and relying party can be done through the **passport check model** and **background check model**.

**Passport check model**

In the passport model, the **attester** validates an identification token with the **verifier**. It then presents the **identification token** to the **relying party**. It's a similar process to when you present your passport at an airport to confirm your own identity when entering a country.

In this model, the attester requests the passport from the verifier by providing **evidence** and receives a passport in the form of **attestation results**. It can now interact directly with the relying party by presenting its passport (attestation result).

The following diagram shows this flow: 

**Background check model**

In the background check model, the **relying party** asks for verification each time the **attester** presents its evidence. This is similar to performing a full background check on an individual every time the individual enters a country.

The attester provides **evidence** to the relying party, which forwards it directly to the verifier. The verifier compares the evidence with the **appraised policy** it contains, and returns an **attestation result** to the relying party. The relying party compares the attestation results with its own **appraisal policy**.

Unlike a passport model, where the attester sends **attestation results** to the relying party, the background model requires the attester to send the relying party **evidence** (which is sent as-is to the verifier).

The following diagram illustrates the background check model:

**The Trustee project**

The trustee project (previously known as CoCo KBS) includes components deployed on a trusted side and used to verify whether the remote workload is running in a trusted execution environment (TEE). It also verifies that the remote environment uses the expected software and hardware versions.

This diagram shows the architecture for the Trustee model:

The **left side** includes the **guest components** running inside the TEE, including the Attestation Agent (AA) and Confidential Data Hub (CDH). The **right side** includes the external components, which the guest components interact with, such as the Key Broker Service (KBS), Attestation Service (AS), and the Reference Value Provider Service (RVPS).

**Trustee and guest components****Key Broker Service (KBS)**

The Key Broker Service (KBS) facilitates remote attestation and managing and delivering secrets. Equating this to the RATS model, the KBS is the **relying party** entity. The KBS, however, doesn’t validate the attestation evidence. Instead, it uses the attestation service (AS) to verify the TEE evidence.

**Attestation Service (AS)**

The Attestation Service (AS) is responsible for validating the TEE evidence. This includes evidence from the following TEEs: Intel TDX, Intel SGX, AMD SEV-SNP, ARM CCA, Hygon CSV, and more.

When mapped to the RATS model, the AS is the equivalent of the **verifier**.

The AS receives attestation evidence and returns an attestation token containing the results of a two-step verification process. Note that the KBS is the client of the AS, however the evidence originates from the attestation agent (AA).

The following diagram shows the AS components:

The AS runs the following verification process:

1.  **Verify the formatting and the origin of the evidence** - for example, checking the signature of the evidence. This is accomplished by one of the platform-specific Verifier Drivers.
2.  **Evaluate the claims provided in the evidence** - for example, validating that the measurements are what the client expects. This is done by a Policy Engine with help from the RVPS.

**Verifier driver**

A verifier driver parses the attestation evidence provided by the hardware TEE. It performs the following tasks:

1.  Verifies the hardware TEE signature of the TEE quote and report provided in the evidence
2.  Receives the evidence and organizes the status into a JSON format to be returned

**Policy Engine**

The AS allows users to upload their own policies when performing evidence verification. When an attestation request is received by the AS, it uses a policy ID in the request to decide which policies should be evaluated. The results of all policies evaluated are included in the attestation response.

**Reference Value Provider Service (RVPS)**

The reference value provider service (RVPS) is a component in the AS responsible for verifying, storing, and providing reference values. RVPS receives and verifies inputs from the software supply chain, stores the measurement values, and generates reference value claims for the AS. This operation is performed based on the evidence verified by the AS.

The following diagram shows the RVPS components:

RVPS contains the preprocessors, extractors, and store components:

**Preprocessors**

These are plugins that preprocess the reference value registration messages before sending it to extractors.

**Extractors**

These are plugins that process different types of provenance in the input message. Each plugin consumes the input message, and then generates an output **Reference** value.

**Store**

The store component provides persistent storage for the reference values.

**Attestation Agent (AA)**

The Attestation Agent (AA) is the entity running inside the TEE that connects to the KBS in order to perform attestation.  AA is responsible for sending the evidence (claims) from the TEE to prove the trustworthiness of the environment.

**Confidential Data Hub (CDH)**

The Confidential Data Hub (CDH) facilitates secure key retrieval for kata-agent and applications. It also provides additional services, such as secure mount for external storage or key management client services to retrieve keys directly from external Key Management Services. The secure mount service enables mounting of encrypted storage inside the TEE. We'll cover the secure mount service in a subsequent blog.

The following diagram shows the CDH components:

**Resources for learning about the attestation flow**

For an **overview of attestation**, read our Learn about Confidential Computing Attestation blog series.

For details on **attestation flow in confidential containers**, read our Understanding the Confidential Containers Attestation Flow article.

For a **step-by-step flow of confidential containers attestation on Azure** cloud, read our Confidential Containers on Azure with OpenShift: A technical deep dive article.

**Mapping Trustee components to the RATS model**

This is how the RATS model maps to the Trustee components model:

Note the following:

*   The **Attester** functionally is performed by the **AA** and **CDH** guest side components.
*   The **Verifier** is mapped to the **AS**.
*   The **Relying party** is mapped to the **KBS** receiving attestation results from the AS, and performing actions based on the results.
*   The **Endorser** usually originates from the platform manufacturer (Intel, AMD, IBM, and so on), so it can be the manufacturer itself or a CSP that got endorsed by the hardware manufacturer.
*   The **Reference Value Provider** is mapped to the **RVPS** and provides the endorsed reference. Note that reference values do not originate from the hardware manufacturer, but rather they reference measurements of the kernel, firmware image, and so on. They are trusted artifacts meaning signed by an identity you can trust and are used for performing the verification.
*   The **Verify owner** and **Relying Party** owner are the entities who operate the KBS and AS on the user's behalf.

**Background check model**

The background check model is a common way to configure the KBS and AS components, so we present it before the passport model. The following diagram shows the model: 

In this model, the AA communicates with the KBS providing the hardware evidence and the KBS communicates with the AS to verify it. After the evidence is verified, the KBS releases the secrets back to the CDH when requested.

In background check mode, the KBS is the relying party, the AS is the verifier, and the AA is the attester.

**Passport model**

In the passport model, the validation of evidence and provisioning of resources are typically handled by  different KBSes. The following diagram shows the model: 

We now have 2 KBS entities:

*   The first KBS, with the AS, verifies the evidence from the guest.
*   The second KBS provides secrets to the guest.

The AA interacts with **upper KBS + AS (Trustee 1)** in order to attest, verify the evidence, and receive a token (a passport). It then requests the secret resources from the **lower KBS (Trustee 2)**.

In practice, we recommend using the passport model when the attestation and resource provisioning are handled by separate entities.

**Attestation use cases leveraging Trustee components**

There are many use cases that can leverage the Trustee and guest components. For simplicity, we focus on the **background check model** (a single KBS) and not the **passport model** (with two KBS entities).

**Attestation for virtual machines (VMs) and their workloads**

Confidential VMs (CVMs) leverage hardware-based security features, such as AMD SEV-SNP (Secure Encrypted Virtualization-Secure Nested Paging) or Intel TDX (Trust Domain Extensions) to provide a secure execution environment for sensitive workloads. These VMs confirm that code and data remain encrypted and isolated, even from other privileged softwares on the host system. However, validating the integrity of these VMs and their underlying hardware is critical to guaranteeing the confidentiality and security of the data that is processed.

For a detailed description of confidential VMs, read our Learn about Red Hat Confidential Virtual Machines blog series.

VM attestation verifies the integrity of a confidential VM and its underlying platform components, including the CPU, firmware, and hypervisor. The attestation process might be initiated by the firmware or initrd.

From a trust perspective, you need assurance that the VM you just created on a public cloud is really a CVM with an operating system of your choice. In particular, you need to make sure that the host hasn’t started a non-confidential VM with a specially crafted guest operating system to steal your secrets instead.

The following diagram shows the overall architecture for VM attestation: 

Note the following:

*   The CVM can run over a KVM hypervisor, some other hypervisor on bare metal or on a public cloud provider infrastructure.
*   The AA works with the Trustee AS.

Here is a list of Trustee and guest components being used:

**Trustee components**

**Guest components**

KBS

AA

AS

 

RVPS

 

**Attestation for a confidential containers workload**

Moving from the VM level attestation to a container level attestation, let’s focus on container workload the user wants to run in a secure manner protected from the host.

Attestation for confidential containers verifies the container runtime stack running in the confidential environment. This includes kata-agent, supporting services like agent-protocol-forwarder, process-user-data, open policy agent, and default policies that are needed to run the container.

If the confidential containers are using the VM trusted execution environment, then the attestation includes attestation of the VM followed by attestation of the container runtime components. This diagram shows the overall architecture for confidential container attestation: 

Note the following:

*   Peer-pods are used for running confidential containers over VMs (on-prem and public cloud). For additional details, read Deploying confidential containers on the public cloud
*   The trustee model is used twice in this case to attest the CVM and then attest the confidential container runtime components

Here's a list of Trustee and guest components being used:

**Trustee components**

**Guest components**

KBS

AA

AS

 

RVPS

 

**Attestation to retrieve container image signing or decryption keys**

This use case is specific to obtaining the key for signature verification of a signed container image or obtaining the decryption key for encrypted images. For example, you might use encrypted container images to ship proprietary or sensitive code, such as AI models.

If the confidential containers are using the VM trusted execution environment, then the attestation process begins with VM attestation to confirm the integrity of the underlying execution environment. Once the VM's trustworthiness is established, container attestation proceeds, confirming the authenticity and integrity of the container runtime components. After a successful attestation, the container runtime requests the key from the Key Broker Service (KBS) for signature verification or decryption of the container images before starting the application.

The following diagram shows the overall architecture for retrieving the container image signing or decryption keys:

The attestation process is similar to attesting a confidential container workload, with the extra step of CDH retrieving the signing or decryption key that gets used by the kata-agent for signature verification or decrypting the container image.

This is a list of Trustee and guest components being used:

**Trustee components**

**Guest components**

KBS

AA

AS

CDH

RVPS

 

**Attestation for releasing application secrets**

This use case is specific to obtaining the key used by the workload. An example use case for obtaining the key is **Data Clean Rooms**. 

A number of organizations want to analyze data without compromising the privacy of individuals whose data is being analyzed (a joint bank fraud detection effort, for example). They're required to create a shared secured environment for data leaving the boundaries of those individuals. They would also want that environment to run in the cloud at scale. This can be accomplished by a secure key release where the data decryption key is only released to a specific TEE based on attestation.

The following diagram shows the idea: 

If the confidential containers are using the VM trusted execution environment, then the attestation process begins with VM attestation to ensure the integrity of the underlying execution environment. Once the VM's **trustworthiness** is established, container attestation proceeds, confirming the authenticity and integrity of the container runtime components. After a successful attestation, the container runtime starts the application.

The application then starts another attestation sequence to request the application secret from the Key Broker Service (KBS).  Confidential Data Hub (CDH) is used to request the application secret from the KBS by initiating an attestation sequence to prove the trustworthiness of the environment.

The following diagram shows the additional step of obtaining the application secret:

Note the following:

*   The attestation process is similar to attesting a confidential container workload, with the extra step of CDH retrieving the application secrets and providing it to the application
*   If the container images are signed or encrypted, then first the signing or decryption key is fetched (as described in the previous use case), followed by the application secret retrieval by CDH

Here's a list of Trustee and guest components being used:

**Trustee components**

**Guest components**

KBS

AA

AS

CDH

RVPS

 

**Trustee project and confidential computing**

In this blog we have introduced the Trustee project which is part of the confidential containers CNCF initiative and includes a number of services providing attestation capabilities for containers, VMs, shared keys and more.

We’ve covered the IETF RATS model, reviewed the Trustee components and showed the mapping between Trustee and the RATS model. We’ve also reviewed a number of use cases requiring attestation and presented how the Trustee components are used for those purposes.

In future blogs, we'll dive deeper into the Trustee projects looking at the technical details and hands on instructions on how to try out things.

Introducing Confidential Containers Trustee: Attestation Services Solution Overview and Use Cases

Red Hat Security Advisory 2024-1614-03 - An update for kernel-rt is now available for Red Hat Enterprise Linux 8. Issues addressed include code execution, null pointer, privilege escalation, and use-after-free vulnerabilities.

The following advisory data is extracted from:

https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_1614.json

Red Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.

- Packet Storm Staff

====================================================================  
Red Hat Security Advisory

Synopsis:           Important: kernel-rt security and bug fix update  
Advisory ID:        RHSA-2024:1614-03  
Product:            Red Hat Enterprise Linux  
Advisory URL:       https://access.redhat.com/errata/RHSA-2024:1614  
Issue date:         2024-04-03  
Revision:           03  
CVE Names:          CVE-2021-33631  
====================================================================

Summary: 

An update for kernel-rt is now available for Red Hat Enterprise Linux 8.

Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.

Description:

The kernel-rt packages provide the Real Time Linux Kernel, which enables fine-tuning for systems with extremely high determinism requirements.

Security Fix(es):

* kernel: vmwgfx: NULL pointer dereference in vmw_cmd_dx_define_query (CVE-2022-38096)

* kernel: Out of boundary write in perf_read_group() as result of overflow a perf_event's read_size (CVE-2023-6931)

* kernel: GSM multiplexing race condition leads to privilege escalation (CVE-2023-6546,ZDI-CAN-20527)

* kernel: CIFS Filesystem Decryption Improper Input Validation Remote Code Execution Vulnerability in function receive_encrypted_standard of client (CVE-2024-0565)

* kernel: use-after-free in amdgpu_cs_wait_all_fences in drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c (CVE-2023-51042)

* kernel: ext4: kernel bug in ext4_write_inline_data_end() (CVE-2021-33631)

* kernel: nf_tables: use-after-free vulnerability in the nft_verdict_init() function (CVE-2024-1086)

Bug Fix(es):

* kernel-rt: update RT source tree to the latest RHEL-8.9.z3 Batch (JIRA:RHEL-23853)

* kernel-rt: kernel: nf_tables: use-after-free vulnerability in the nft_verdict_init() function (JIRA:RHEL-24015)

* kernel-rt: kernel: vmxgfx: NULL pointer dereference in vmw_cmd_dx_define_query (JIRA:RHEL-22758)

* kernel-rt: kernel: CIFS Filesystem Decryption Improper Input Validation Remote Code Execution Vulnerability in function receive_encrypted_standard of client (JIRA:RHEL-22080)

* kernel-rt: kernel: Out of boundary write in perf_read_group() as result of overflow a perf_event's read_size (JIRA:RHEL-22933)

* kernel-rt: kernel: use-after-free in amdgpu_cs_wait_all_fences in drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c (JIRA:RHEL-24498)

* kernel-rt: kernel: GSM multiplexing race condition leads to privilege escalation (JIRA:RHEL-19966)

* kernel-rt: kernel: ext4: kernel bug in ext4_write_inline_data_end() (JIRA:RHEL-26334)

Solution:

https://access.redhat.com/articles/11258

CVEs:

CVE-2021-33631

References:

https://access.redhat.com/security/updates/classification/#important  
https://bugzilla.redhat.com/show_bug.cgi?id=2133452  
https://bugzilla.redhat.com/show_bug.cgi?id=2252731  
https://bugzilla.redhat.com/show_bug.cgi?id=2255498  
https://bugzilla.redhat.com/show_bug.cgi?id=2258518  
https://bugzilla.redhat.com/show_bug.cgi?id=2259866  
https://bugzilla.redhat.com/show_bug.cgi?id=2261976  
https://bugzilla.redhat.com/show_bug.cgi?id=2262126

Red Hat Security Advisory 2024-1614-03

Fortanix is working on technologies to build a security wall around AI search.

The inner functioning of AI-powered search is more complex than plain-text search via Google when it comes to extracting answers from websites and databases. Fortanix is trying to build a security wall to protect the search query and the extraction of data from artificial intelligence (AI) systems.

Generative AI technologies will ultimately provide fine-grained responses based on associativity of information and retrieve information from sources users may not be aware of, says Richard Searle, vice president of confidential computing at Fortanix.

"What we're finding ... is that there is a deeper focus happening in the AI domain around privacy, consent, and permissioning of information," Searle says. "These are obviously the core cases."

Essentially, Fortanix is building a security wall around the way AI search queries are handled. More specifically, it is building security around prompts, where users provide AI search queries. The security wall extends to data retrieval from large language models, which are delivered to customers.

"We think there's a significant market there," Searle says. "The partners that we're working with within the AI space are talking about search to their customers already today."

Fortanix's private AI search is pinned on confidential computing, which creates secure vaults that are accessible to authorized parties only via keys. The data is processed inside, without leaving the vault.

"Data is going to be subject to not only the data protection regulations that we have today, but also these emerging AI regulations," Searle says.

Fortanix's technology is a component in the emerging field of confidential AI. Confidential AI is extended to AI scenarios typically associated with GPUs and accelerators, said Mark Russinovich, chief technology officer for Microsoft Azure, during a panel discussion at the Open Confidential Computing Conference in March.

**Protecting Vector Databases**

Private search with AI relies on data extraction from knowledge graphs or vector databases, which could draw information from a wide range of sources, including static conventional databases.

At Nvidia's GPU Technology Conference, also in March, the company's CEO, Jensen Huang, defined vector databases as a new style of database that takes structured data or unstructured data that can be reindexed by encoding the meaning of data.

"Now this becomes an AI database, and that AI database in the future, once you create it, you can talk to it," Huang said.

Fortanix's goal is to initiate privacy for the search initiator — a human or machine user — and protect the privacy and integrity of the information that might be within the vector embeddings.

"Confidential computing, I think, has a very important role to play," Fortanix’s Searle says.

**Private Search Differs From Conventional Search**

Confidential AI prevents the leak of AI information, which helps meet regulatory requirements. The layer also anonymizes the information so a user's intent or identity is protected. That is the opposite of conventional search, where user information and motives drive Google Ads and analytics.

A higher level of AI privacy is a cornerstone for industries such as healthcare and banking, which are tied to regulatory issues.

"Imagine that you want to do search in a scientific domain — you might want to be able to use data from a different institution to the one you're working in that has some specific expertise in a particular field. Showing the privacy of that data and the accuracy of this research is important," Searle says.

**State of Confidential AI**

Confidential AI is an emerging concept, and search fits into that profile. Intel and AMD have chips with hooks for secure enclaves. Microsoft, Google, and Amazon are providing confidential computing virtual machines in their cloud services.

Companies can bring data sets together to train a foundational model effectively, and these data sets are becoming high-value assets for top corporations, said Ian Buck, vice president and general manager of Nvidia's hyperscale and high-performance computing division, during the panel discussion.

The IT industry is rapidly approaching the deployment of confidential computing in data centers, edge computing, and PCs, but there's a lot more to do with confidential AI, said Greg Lavender, Intel's chief technology officer, during the panel.

"Privacy and safety and responsible AI are going to be big forcing functions for this as the government adopts AI technologies from the industry," he said.

**About the Author(s)**

Agam Shah has covered enterprise IT for more than a decade. Outside of machine learning, hardware, and chips, he's also interested in martial arts and Russia.

Fortanix Builds Private Search for AI

Red Hat Security Advisory 2024-1607-03 - An update for kernel is now available for Red Hat Enterprise Linux 8. Issues addressed include code execution, null pointer, privilege escalation, and use-after-free vulnerabilities.

The following advisory data is extracted from:

https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_1607.json

Red Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.

- Packet Storm Staff

====================================================================  
Red Hat Security Advisory

Synopsis:           Important: kernel security, bug fix, and enhancement update  
Advisory ID:        RHSA-2024:1607-03  
Product:            Red Hat Enterprise Linux  
Advisory URL:       https://access.redhat.com/errata/RHSA-2024:1607  
Issue date:         2024-04-02  
Revision:           03  
CVE Names:          CVE-2021-33631  
====================================================================

Summary: 

An update for kernel is now available for Red Hat Enterprise Linux 8.

Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.

Description:

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

Security Fix(es):

* kernel: vmwgfx: NULL pointer dereference in vmw_cmd_dx_define_query (CVE-2022-38096)

* kernel: Out of boundary write in perf_read_group() as result of overflow a perf_event's read_size (CVE-2023-6931)

* kernel: GSM multiplexing race condition leads to privilege escalation (CVE-2023-6546,ZDI-CAN-20527)

* kernel: CIFS Filesystem Decryption Improper Input Validation Remote Code Execution Vulnerability in function receive_encrypted_standard of client (CVE-2024-0565)

* kernel: use-after-free in amdgpu_cs_wait_all_fences in drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c (CVE-2023-51042)

* kernel: ext4: kernel bug in ext4_write_inline_data_end() (CVE-2021-33631)

* kernel: nf_tables: use-after-free vulnerability in the nft_verdict_init() function (CVE-2024-1086)

Bug Fix(es):

* OCP 4.12 crashed due to use-after-free in libceph in rhel8 (JIRA:RHEL-21394)

* kernel: nf_tables: use-after-free vulnerability in the nft_verdict_init() function (JIRA:RHEL-24010)

* Screen floods with random colour suggesting something not initialised (JIRA:RHEL-21055)

* kernel: vmxgfx: NULL pointer dereference in vmw_cmd_dx_define_query (JIRA:RHEL-22766)

* tx-checksumming required for accessing port in OpenShift for RHEL 8.6 (JIRA:RHEL-20822)

* kernel: CIFS Filesystem Decryption Improper Input Validation Remote Code Execution Vulnerability in function receive_encrypted_standard of client (JIRA:RHEL-22077)

* kernel: Out of boundary write in perf_read_group() as result of overflow a perf_event's read_size (JIRA:RHEL-22930)

* rbd: don't move requests to the running list on errors [8.x] (JIRA:RHEL-24204)

* kernel: use-after-free in amdgpu_cs_wait_all_fences in drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c (JIRA:RHEL-24479)

* ceph: several cap and snap fixes (JIRA:RHEL-20909)

* [RHVH] Migration hangs between RHVH release bellow 4.5.1 and RHVH over or equal 4.5.2 release (JIRA:RHEL-23063)

* unable to access smsc95xx based interface unless you start outgoing traffic.  (JIRA:RHEL-25719)

* [RHEL8] ] BUG bio-696 (Not tainted): Poison overwritten  (JIRA:RHEL-26101)

* kernel: GSM multiplexing race condition leads to privilege escalation (JIRA:RHEL-19954)

* backport smartpqi: fix disable_managed_interrupts (JIRA:RHEL-26139)

* kernel: ext4: kernel bug in ext4_write_inline_data_end() (JIRA:RHEL-26331)

* ceph: always check dir caps asynchronously (JIRA:RHEL-27496)

Enhancement(s):

* [IBM 8.10 FEAT] Upgrade the qeth driver to latest from upstream, e.g. kernel 6.4 (JIRA:RHEL-25811)

Solution:

https://access.redhat.com/articles/11258

CVEs:

CVE-2021-33631

References:

https://access.redhat.com/security/updates/classification/#important  
https://bugzilla.redhat.com/show_bug.cgi?id=2133452  
https://bugzilla.redhat.com/show_bug.cgi?id=2252731  
https://bugzilla.redhat.com/show_bug.cgi?id=2255498  
https://bugzilla.redhat.com/show_bug.cgi?id=2258518  
https://bugzilla.redhat.com/show_bug.cgi?id=2259866  
https://bugzilla.redhat.com/show_bug.cgi?id=2261976  
https://bugzilla.redhat.com/show_bug.cgi?id=2262126

Red Hat Security Advisory 2024-1607-03

Cybersecurity researchers from ETH Zurich have developed a new variant of the RowHammer DRAM (dynamic random-access memory) attack that, for the first time, successfully works against AMD Zen 2 and Zen 3 systems despite mitigations such as Target Row Refresh (TRR).
"This result proves that AMD systems are equally vulnerable to Rowhammer as Intel systems, which greatly increases the attack

New ZenHammer Attack Bypasses Rowhammer Defenses on AMD CPUs

There are a few reasons why we’re so ready to jump to the “it’s a cyber attack!”

Thursday, March 14, 2024 14:00

Some of my Webex rooms recently have been blowing up with memes about blaming Canada or wild speculation that a state-sponsored actor is carrying out some sort of major campaign.  

After a widespread outage of cellular service with AT&T and other carriers a few weeks ago, people were sure it was some sort of coordinated attack to disrupt Americans’ services that largely power our day-to-day lives. The outage lasted about 11 hours, and after the fact, the company announced they’d give customers a whopping $5 credit to make up for the issue. The Federal Communications Commission also announced last week that it was launching a formal investigation into the outage, requesting more information about the exact cause and how many users were affected.  

About two weeks later, the same kinds of messages and questions to our team came flooding in when Meta experienced an outage across many of its platforms, most notably Facebook, Instagram and Threads. Though this only lasted a few hours, any time Americans can’t access their Instagram feeds, it’s going to make headlines. 

In both cases, consumers immediately wanted to start pointing fingers — Which actor was behind these? Why is there so little information about this outage? Is this China getting revenge for talk of forcing a TikTok sale? What’s the broader conspiracy behind this? The outages also quickly opened the door for some of the world’s chief spreaders of misinformation and fake news to start spreading conspiracy theories. 

The problem is, not every technical issue can or needs to be explained away by a cyber attack. That’s not to undersell the danger that state-sponsored APTs pose currently, or the fact that they \*could\* one day cause a disruption like this. But jumping to that conclusion every time Down Detector pops off is only going to spread fear/FUD and help these outlets for disinformation reach a larger audience.  

It creates a “boy who cried wolf” situation for when a major cyber attack actually does happen, and the average consumer is forced to make an immediate update to some piece of software or hardware. 

There are a few reasons why we’re so ready to jump to the “it’s a cyber attack!” conclusion. One is that Hollywood has been “glamorizing” the idea of a major cyber attack or major disruption for years now. Movies and TV shows like Netflix’s “Leave the World Behind” have dramatized what a major cyber attack or internet outage may look like, and how quickly it could lead to the unraveling of civilization. Because of our current doomscrolling culture, the second something even looks like it could be a cyber event, we’re ready to declare the end of our economy and society. 

It’s also sexier when it’s a cyber attack. AT&T says its outage was caused by a technical error that occurred when it was trying to upgrade its network’s capacity, explicitly stating it was not caused by any sort of disruption campaign or cyber attack. Meta simply chalked their outage up to a “technical issue.”  

None of these things make for good headlines. But sometimes, the simplest explanation is the most obvious one — we’ve all pressed a wrong button here or there, and stuff breaks on the internet all the time for all sorts of reasons. But “Users logged out of Instagram after Meta employee hits ‘enter’ too soon” isn’t as eye-catching as “Are Instagram and Facebook down because of a cyber attack?” 

Could these multi-billion-dollar corporations be lying? Sure, but I also find it hard enough to believe that the truth would not have made it out to consumers by now if these outages weren’t simple technical issues, nor would AT&T feel compelled to reimburse customers for something that could be totally out of their control. 

And if you ever get logged out of Facebook or Instagram, maybe you’re just better off being offline for a few hours anyway than immediately assuming Mahershala Ali is going to be knocking on your vacation home’s door in any minute.   

**The one big thing **

We want to keep reminding users to update and upgrade their network infrastructure. Aging devices like switches and routers that are used across the globe are a consistently vulnerable surface for adversaries to gain an initial foothold onto targeted networks. Talos recently highlighted the three most common post-compromise attacks that adversaries carry out after compromising these types of vulnerable devices, including modifying the device’s firmware and downgrading the firmware to remove older patches and open the door to new exploitable vulnerabilities. Nick Biasini from Talos Outreach also spoke about this issue for an article in NetworkWorld.  

**Why do I care? **

As Hazel Burton puts it in the blog post linked above: “Adversaries, particularly APTs, are capitalizing on this scenario to conduct hidden post-compromise activities once they have gained initial access to the network. The goal here is to give themselves a greater foothold, conceal their activities, and hunt for data and intelligence that can assist them with their espionage and/or disruptive goals. Think of it like a burglar breaking into a house via the water pipes. They’re not using “traditional” methods such as breaking down doors or windows (the noisy smash-and-grab approach) — they’re using an unusual route, because no one ever thinks their house will be broken into via the water pipes. Their goal is to remain stealthy on the inside while they take their time to find the most valuable artefacts.” 

**So now what? **

If you are using network infrastructure that is end of life, out of support, and now has vulnerabilities that cannot be patched, now really is the time to replace those devices. Using networking equipment that has been built with secure-by-design principles such as running secure boot, alongside having a robust configuration and patch management approach, is key to combatting these types of threats. Ensure that these devices are being watched very carefully for any configuration changes and patch them promptly whenever new vulnerabilities are discovered.   

**Top security headlines of the week **

**Security researchers have found a new vulnerability affecting chips made by nearly all major CPU makers dubbed “GhostRace.”** The vulnerability, identified as CVE-2024-2193, requires an adversary to win a race condition and to have physical or privileged access to the targeted machine. However, it could allow a malicious user to steal potentially sensitive information from memory like passwords and encryption keys. "The vulnerability affects many CPU architectures, including those made by Intel, AMD, Arm and IBM. It also affected some hypervisor vendors and the Linux operating system. AMD released an advisory this week that informed customers that they should follow previous defense guidance for other security flaws like Spectre that have affected CPUs in the past. “Our analysis shows all the other common write-side synchronization primitives in the Linux kernel are ultimately implemented through a conditional branch and are therefore vulnerable to speculative race conditions,” VU Amsterdam said in its blog post disclosing GhostRace. (SecurityWeek, Vrije Universiteit Amsterdam) 

**Health care providers are still reeling from a cyber attack on Change Healthcare**, a subsidiary of the United HealthGroup Inc. insurance provider. First Health Advisory, a digital health risk assurance firm, recently estimated that health care providers are losing an estimated $100 million daily as they still cannot process payments from insurance providers. Change first disclosed the suspected ransomware attack in late February, and on March 5, the U.S. government announced a plan to provide relief payments for providers who are facing financial shortfalls due to the outage. Many doctors' offices and care clinics are facing late rent payments and unpaid invoices. The attack has also limited some patients’ ability to obtain pre-authorization for certain services and surgeries, and others have not been able to refill their prescriptions at hospitals. U.S. Congress is also asking the CEO of United HealthGroup to appear before a committee to answer questions about the hack. (CBS News, Bloomberg) 

**The U.S. has placed formal sanctions against two individuals and five entities associated with the Intellexa Consortium,** responsible for developing and distributing the Predator spyware. Talos has previously reported on Intellexa’s tools, and how their spyware is silently loaded onto targeted devices. This is the first time the Treasury Department has sanctioned a spyware organization and announced it publicly. The sanctions include five vendors who work with Intellexa to sell the spyware, all of whom are spread across Europe. Intellexa itself is based in Greece. Predator and other spyware developed by private parties are often used to target high-risk individuals to track their communication and movement, including politicians, journalists, activists and political dissidents. Under the sanctions, anyone in the U.S. is forbidden from doing business with Intellexa or the associated companies and individuals. The Biden administration has long pushed for additional action against spyware makers, including Israel-based NSO Group, which distributes the Pegasus spyware. (Voice of America, Axios) 

**Can’t get enough Talos? **

*   Threat actors leverage document publishing sites for ongoing credential and session token theft 
*   Heather Couk is here to keep your spirits up during a cyber emergency, even if it takes the “Rocky” music 
*   Another Patch Tuesday with no zero-days, only two critical vulnerabilities disclosed by Microsoft 
*   Talos Takes Ep. #175: What's new about GhostSec's ransomware-as-a-service model 

**Upcoming events where you can find Talos **

**Botconf** **(April 23 - 26)** 

_Nice, Côte d'Azur, France_

> _This presentation from Chetan Raghuprasad details the Supershell C2 framework. Threat actors are using this framework massively and creating botnets with the Supershell implants._

**CARO Workshop 2024** **(May 1 - 3)** 

_Arlington, Virginia_

> Over the past year, we’ve observed a substantial uptick in attacks by YoroTrooper, a relatively nascent espionage-oriented threat actor operating against the Commonwealth of Independent Countries (CIS) since at least 2022. Asheer Malhotra's presentation at CARO 2024 will provide an overview of their various campaigns detailing the commodity and custom-built malware employed by the actor, their discovery and evolution in tactics. He will present a timeline of successful intrusions carried out by YoroTrooper targeting high-value individuals associated with CIS government agencies over the last two years.

**RSA** **(May 6 - 9)** 

_San Francisco, California_   

**Most prevalent malware files from Talos telemetry over the past week **

**SHA 256:** a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91    
**MD5:** 7bdbd180c081fa63ca94f9c22c457376   
**Typical Filename:** c0dwjdi6a.dll   
**Claimed Product:** N/A    
**Detection Name:** Trojan.GenericKD.33515991 

**SHA 256:** 24283c2eda68c559f85db7bf7ccfe3f81e2c7dfc98a304b2056f1a7c053594fe   
**MD5:** 49ae44d48c8ff0ee1b23a310cb2ecf5a   
**Typical Filename:** nYzVlQyRnQmDcXk   
**Claimed Product:** N/A   
**Detection Name:** Win.Dropper.Scar::tpd 

**SHA 256:** e38c53aedf49017c47725e4912fc7560e1c8ece2633c05057b22fd4a8ed28eb3   
**MD5:** c16df0bfc6fda86dbfa8948a566d32c1   
**Typical Filename:** CEPlus.docm   
**Claimed Product:** N/A    
**Detection Name:** Doc.Downloader.Pwshell::mash.sr.sbx.vioc 

**SHA 256:** 9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507    
**MD5:** 2915b3f8b703eb744fc54c81f4a9c67f    
**Typical Filename:** VID001.exe    
**Claimed Product:** N/A    
**Detection Name:** Win.Worm.Coinminer::1201 

**SHA 256:** e4973db44081591e9bff5117946defbef6041397e56164f485cf8ec57b1d8934   
**MD5:** 93fefc3e88ffb78abb36365fa5cf857c   
**Typical Filename:** Wextract   
**Claimed Product:** Internet Explorer   
**Detection Name:** W32.File.MalParent

Not everything has to be a massive, global cyber attack

Red Hat Security Advisory 2024-1248-03 - An update for kernel is now available for Red Hat Enterprise Linux 9. Issues addressed include null pointer, out of bounds access, out of bounds read, out of bounds write, privilege escalation, and use-after-free vulnerabilities.

The following advisory data is extracted from:

https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_1248.json

Red Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.

- Packet Storm Staff

====================================================================  
Red Hat Security Advisory

Synopsis:           Important: kernel security update  
Advisory ID:        RHSA-2024:1248-03  
Product:            Red Hat Enterprise Linux  
Advisory URL:       https://access.redhat.com/errata/RHSA-2024:1248  
Issue date:         2024-03-12  
Revision:           03  
CVE Names:          CVE-2023-4244  
====================================================================

Summary: 

An update for kernel is now available for Red Hat Enterprise Linux 9.

Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.

Description:

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

Security Fix(es):

* kernel: inactive elements in nft_pipapo_walk (CVE-2023-6817)

* kernel: netfilter: use-after-free in nft_trans_gc_catchall_sync leads to privilege escalation (CVE-2024-0193)

* kernel: ktls overwrites readonly memory pages when using function splice with a ktls socket as destination (CVE-2024-0646)

* kernel: Use-after-free in nft_verdict_dump due to a race between set GC and transaction (CVE-2023-4244)

* kernel: A heap out-of-bounds write when function perf_read_group is called and sibling_list is smaller than its child's sibling_list (CVE-2023-5717)

* kernel: NULL pointer dereference in nvmet_tcp_build_iovec (CVE-2023-6356)

* kernel: NULL pointer dereference in nvmet_tcp_execute_request (CVE-2023-6535)

* kernel: NULL pointer dereference in __nvmet_req_complete (CVE-2023-6536)

* kernel: Out-Of-Bounds Read vulnerability in smbCalcSize (CVE-2023-6606)

* kernel: OOB Access in smb2_dump_detail (CVE-2023-6610)

* kernel: use-after-free in amdgpu_cs_wait_all_fences in drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c (CVE-2023-51042)

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.

Solution:

https://access.redhat.com/articles/11258

CVEs:

CVE-2023-4244

References:

https://access.redhat.com/security/updates/classification/#important  
https://bugzilla.redhat.com/show_bug.cgi?id=2235306  
https://bugzilla.redhat.com/show_bug.cgi?id=2246945  
https://bugzilla.redhat.com/show_bug.cgi?id=2253611  
https://bugzilla.redhat.com/show_bug.cgi?id=2253614  
https://bugzilla.redhat.com/show_bug.cgi?id=2253908  
https://bugzilla.redhat.com/show_bug.cgi?id=2254052  
https://bugzilla.redhat.com/show_bug.cgi?id=2254053  
https://bugzilla.redhat.com/show_bug.cgi?id=2254054  
https://bugzilla.redhat.com/show_bug.cgi?id=2255139  
https://bugzilla.redhat.com/show_bug.cgi?id=2255653  
https://bugzilla.redhat.com/show_bug.cgi?id=2259866

Red Hat Security Advisory 2024-1248-03

Red Hat Security Advisory 2024-1019-03 - An update for kernel-rt is now available for Red Hat Enterprise Linux 9.2 Extended Update Support. Issues addressed include null pointer, privilege escalation, and use-after-free vulnerabilities.

The following advisory data is extracted from:

https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_1019.json

Red Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.

- Packet Storm Staff

====================================================================  
Red Hat Security Advisory

Synopsis:           Important: kernel-rt security update  
Advisory ID:        RHSA-2024:1019-03  
Product:            Red Hat Enterprise Linux  
Advisory URL:       https://access.redhat.com/errata/RHSA-2024:1019  
Issue date:         2024-02-28  
Revision:           03  
CVE Names:          CVE-2022-38096  
====================================================================

Summary: 

An update for kernel-rt is now available for Red Hat Enterprise Linux 9.2 Extended Update Support.

Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.

Description:

The kernel-rt packages provide the Real Time Linux Kernel, which enables fine-tuning for systems with extremely high determinism requirements.

Security Fix(es):

* kernel: GSM multiplexing race condition leads to privilege escalation (CVE-2023-6546)

* kernel: inactive elements in nft_pipapo_walk (CVE-2023-6817)

* kernel: netfilter: use-after-free in nft_trans_gc_catchall_sync leads to privilege escalation (CVE-2024-0193)

* kernel: vmwgfx: NULL pointer dereference in vmw_cmd_dx_define_query (CVE-2022-38096)

* kernel: Use-after-free in nft_verdict_dump due to a race between set GC and transaction (CVE-2023-4244)

* kernel: Out of boundary write in perf_read_group() as result of overflow a perf_event's read_size (CVE-2023-6931)

* kernel: use-after-free in amdgpu_cs_wait_all_fences in drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c (CVE-2023-51042)

* kernel: use-after-free during a race condition between a nonblocking atomic commit and a driver unload in drivers/gpu/drm/drm_atomic.c (CVE-2023-51043)

* kernel: nf_tables: use-after-free vulnerability in the nft_setelem_catchall_deactivate() function (CVE-2024-1085)

* kernel: nf_tables: use-after-free vulnerability in the nft_verdict_init() function (CVE-2024-1086)

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.

Solution:

https://access.redhat.com/articles/11258

CVEs:

CVE-2022-38096

References:

https://access.redhat.com/security/updates/classification/#important  
https://bugzilla.redhat.com/show_bug.cgi?id=2133452  
https://bugzilla.redhat.com/show_bug.cgi?id=2235306  
https://bugzilla.redhat.com/show_bug.cgi?id=2252731  
https://bugzilla.redhat.com/show_bug.cgi?id=2255139  
https://bugzilla.redhat.com/show_bug.cgi?id=2255498  
https://bugzilla.redhat.com/show_bug.cgi?id=2255653  
https://bugzilla.redhat.com/show_bug.cgi?id=2259866  
https://bugzilla.redhat.com/show_bug.cgi?id=2260005  
https://bugzilla.redhat.com/show_bug.cgi?id=2262126  
https://bugzilla.redhat.com/show_bug.cgi?id=2262127

Red Hat Security Advisory 2024-1019-03

Red Hat Security Advisory 2024-1018-03 - An update for kernel is now available for Red Hat Enterprise Linux 9.2 Extended Update Support. Issues addressed include null pointer, privilege escalation, and use-after-free vulnerabilities.

The following advisory data is extracted from:

https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_1018.json

Red Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.

- Packet Storm Staff

====================================================================  
Red Hat Security Advisory

Synopsis:           Important: kernel security update  
Advisory ID:        RHSA-2024:1018-03  
Product:            Red Hat Enterprise Linux  
Advisory URL:       https://access.redhat.com/errata/RHSA-2024:1018  
Issue date:         2024-02-28  
Revision:           03  
CVE Names:          CVE-2022-38096  
====================================================================

Summary: 

An update for kernel is now available for Red Hat Enterprise Linux 9.2 Extended Update Support.

Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.

Description:

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

Security Fix(es):

* kernel: GSM multiplexing race condition leads to privilege escalation (CVE-2023-6546)

* kernel: inactive elements in nft_pipapo_walk (CVE-2023-6817)

* kernel: netfilter: use-after-free in nft_trans_gc_catchall_sync leads to privilege escalation (CVE-2024-0193)

* kernel: vmwgfx: NULL pointer dereference in vmw_cmd_dx_define_query (CVE-2022-38096)

* kernel: Use-after-free in nft_verdict_dump due to a race between set GC and transaction (CVE-2023-4244)

* kernel: Out of boundary write in perf_read_group() as result of overflow a perf_event's read_size (CVE-2023-6931)

* kernel: use-after-free in amdgpu_cs_wait_all_fences in drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c (CVE-2023-51042)

* kernel: use-after-free during a race condition between a nonblocking atomic commit and a driver unload in drivers/gpu/drm/drm_atomic.c (CVE-2023-51043)

* kernel: nf_tables: use-after-free vulnerability in the nft_setelem_catchall_deactivate() function (CVE-2024-1085)

* kernel: nf_tables: use-after-free vulnerability in the nft_verdict_init() function (CVE-2024-1086)

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.

Solution:

https://access.redhat.com/articles/11258

CVEs:

CVE-2022-38096

References:

https://access.redhat.com/security/updates/classification/#important  
https://bugzilla.redhat.com/show_bug.cgi?id=2133452  
https://bugzilla.redhat.com/show_bug.cgi?id=2235306  
https://bugzilla.redhat.com/show_bug.cgi?id=2252731  
https://bugzilla.redhat.com/show_bug.cgi?id=2255139  
https://bugzilla.redhat.com/show_bug.cgi?id=2255498  
https://bugzilla.redhat.com/show_bug.cgi?id=2255653  
https://bugzilla.redhat.com/show_bug.cgi?id=2259866  
https://bugzilla.redhat.com/show_bug.cgi?id=2260005  
https://bugzilla.redhat.com/show_bug.cgi?id=2262126  
https://bugzilla.redhat.com/show_bug.cgi?id=2262127

Tag

#amd