It’s no exaggeration to call sudo the cornerstone of Linux privilege management. It’s one of the first utilities we configure on fresh installs, and it’s baked into almost every Linux distribution by default. Which is precisely why reports of two significant vulnerabilities in sudo—CVE-2025-32462 and CVE-2025-32463—are grabbing headlines and raising red flags. These are local privilege escalation flaws, and if they’re exploited, an attacker could jump from a non-privileged user account straight into the shoes of the almighty root user. . Root access is the holy grail for attackers. It means complete, unrestricted control over a system—access to sensitive files, logs, software installations, and potentially the ability to pivot to other systems in a network. In short, this isn’t a “patch it later when you have time” scenario. If you’re managing Linux systems—whether a single-host VPS or a sprawling on-premises cluster—this is the time to stop, assess, and act. Let's dig into the details and discuss how to keep your systems out of harm's way. So, What’s the Issue with Sudo? At a high level, the two vulnerabilities affect the sudo utility, which sysadmins rely on to grant temporary elevated privileges to non-root users for executing specific tasks. These vulnerabilities could allow an attacker to leapfrog those enforced boundaries and escalate their privileges to root. Over time, accumulated permissions can quietly become a major risk, which is why addressing privilege creep should be part of any long-term access review process. Details This one is tied to how sudo validates and processes certain inputs from users. The exploit scenario involves carefully crafting input data that tricks sudo into mismanaging permission checks or memory management. The result? An attacker bypasses regular user restrictions. CVE-2025-32463 Details The second vulnerability revolves around a flaw in how sudo handles environment variables or command arguments, depending onthe configuration. By exploiting this flaw within local constraints, an attacker could gain root-level execution. Crucially, neither vulnerability can be exploited remotely—an attacker needs local access first. But even with that barrier, it’s still a high-risk scenario considering the prevalence of shared, multi-user environments in modern Linux deployments. Why These Vulnerabilities Matter Privilege escalation is bad enough on its own, but let’s look at the ripple effects here: System Compromise There’s no sugarcoating it. Once an attacker gains root access, your system is essentially theirs. They can modify critical system files, deploy malware, disable security mechanisms, and generally wreak havoc. Stealth and Obfuscation The problem with giving attackers root access isn’t just what they can do—it’s how well they can hide it. Sudo typically logs privileged operations, which helps admins trace unusual behavior. But with root access, attackers can easily tamper with logs, hide evidence, or even set up backdoors for persistent access. Implications for Shared Systems If you’re running multi-tenant environments—whether shared hosting, development environments, or organizations with separate user accounts—one insecure user could compromise the entire system. Segmenting permissions means nothing if one weak link is exploited. Extended Attack Surface Many organizations automate tasks using cron jobs, scheduled scripts, or privilege delegation. A compromised sudo utility could turn any of these automation points into an auxiliary attack vector. The bottom line: even with local-only prerequisites, the potential damage makes this a serious, immediate threat. Who’s at Risk? Let’s be clear: if you’re running Linux, you’re at risk, unless you’ve already patched sudo. This includes: Popular Distributions Ubuntu, Debian, CentOS, Red Hat Enterprise Linux (RHEL), Fedora, and pretty much any Linux distro with a stock sudo installation arevulnerable. If you’ve got Linux machines in your environment—and if you’re reading this, you probably do—this is potentially impacting you. Shared or Multi-Tenant Systems Think university servers, cloud-based development platforms, or any shared infrastructure. These environments are ripe for exploitation, with local users interacting on the same system. Organizations Delaying Patches If you’ve been putting off updates to get to “later,” this is your wake-up call. The longer these vulnerabilities remain unpatched, the more exposed your systems are. What Should You Do? Fixing the issue boils down to applying patches and hardening your sudo configuration. Here’s how to approach it step-by-step: Patch Sudo Now First, check if you’re running a vulnerable version of sudo: sudo --version Compare the output against advisories from your distribution’s security team. Most maintainers have released patched versions by now. For those on Debian-based systems: sudo apt update && sudo apt upgrade sudo For Red Hat-based systems: sudo yum update sudo Test the patch in your staging environment if possible, especially for production-critical systems. Restrict Who Can Use Sudo Open the /etc/sudoers file and make sure only trusted users have sudo access. Remove redundant entries. Instead of granting full privileges broadly, consider: username ALL=(ALL) ALL Minimize who gets elevated privileges to only what’s absolutely necessary. Enable Auditing and Logging Use centralized logging solutions to monitor sudo activity. Tools like auditd or SIEM solutions can help spot anomalous sudo usage. Prioritize alerts for unexpected actions from routine users: auditctl -w /usr/bin/sudo -p x -k sudo_exec Harden the System with SELinux or AppArmor Mandatory Access Control (MAC) systems like SELinux or AppArmor can provide an extra layer of sandboxing, limiting what users can do, even with root privileges. Segment High-RiskSystems If a system is handling highly sensitive workloads or frequently sees untrusted user interaction, consider isolation techniques. Use sandboxing, virtualization, or physical separation to minimize the blast radius if an exploit occurs. The Final Word: Stay Vigilant Sudo vulnerabilities like CVE-2025-32462 and CVE-2025-32463 are a stark reminder of how foundational tools can sometimes introduce serious risks. Admins and security teams can’t afford to treat privilege escalation bugs lightly. Make patch management routine. Subscribe to LinuxSecurity newsletters and use tools to automate vulnerability scanning . Maintaining continuous awareness is your best defense, as critical issues like these will inevitably resurface. Lastly, think of privilege boundaries as a layered defense, not a guarantee. Harden configurations, audit activity, and segment systems wherever possible. And when vulnerabilities like these roll around, act swiftly. Root is a dangerous power to leave unguarded! . Admin privileges are the ultimate target for hackers. They signify absolute, unbounded authority over a device.. root access, local privilege escalation, patch sudo, Linux security, sudo vulnerabilities. . Brittany Day
Researchers from Qualys recently revealed critical vulnerabilities that have existed in the Linux utility needrestart utility for a decade. This tool is an indispensable resource for administrators as it monitors whether systems or services need restarting after package updates. . Unfortunately, Qualys researchers identified five vulnerabilities that, if exploited by local attackers without user authorization, allow unprivileged local attackers to gain root access without user interaction or any user intervention whatsoever. In this article, I'll analyze these vulnerabilities, potential impacts, exploitation methods, and mitigation strategies you can employ to secure your Linux systems. Let's begin by understanding the vulnerabilities discovered. Understanding the needrestart Linux Utility Needrestart is an essential Linux utility that identifies any running services that need restarting after installing updates to libraries, services, or dependencies currently in use. When updates are applied to these components, simply upgrading is not enough - services using old versions may continue running until rebooted. Needrestart scans the system and alerts sysadmins of such instances so all changes take effect properly and keep systems secure and stable. Practically speaking, Needrestart provides admins with an invaluable asset for maintaining system integrity and security. Automatically detecting services that need restarting after updates help prevent mismatches resulting from running outdated components and related vulnerabilities. Streamlining updates by automating the restart process makes maintenance efficient with lower risks of human error, reducing downtime and decreasing risks for administrators. Overview of the Vulnerabilities Discovered One bug discovered by Qualys, CVE-2024-48990 , allows local attackers to execute arbitrary code as root by manipulating the PYTHONPATH environment variable used by needrestart, which inadequately sanitizes this variable when determining ifa Python process needs restarting. CVE-2024-48991 is another race condition vulnerability that allows attackers to exploit needrestart to execute a fake Python interpreter controlled by them, leading to code execution as root. CVE-2024-48992 similarly exploits the RUBYLIB environment variable to run arbitrary code by tricking needrestart into running an attacker-controlled Ruby interpreter. Additionally, CVE-2024-10224 stems from Perl's ScanDeps module and allows attackers to run shell commands as root by manipulating filenames with shell metacharacters. CVE-2024-11003 presents another flaw within Perl's ScanDeps module, which permits file operations with root privileges. Impact Analysis for These Vulnerabilities These needrestart vulnerabilities threaten Linux systems running Ubuntu Server with significant risks. One major impact is local privilege escalation (LPE), in which unprivileged local users gain root access. Furthermore, these exploits allow attackers to execute arbitrary code with elevated privileges, ultimately leading to complete system compromise or even total takeover by malicious actors. Since needrestart operates with elevated privileges to monitor system services, any flaw in its execution could be exploited by malicious actors to undertake dangerous activities against those systems. Systems running Ubuntu Server versions from 21.04 onwards are at particular risk due to needrestart being enabled by default and thus installed and configured automatically. This impacts a large portion of server deployments worldwide, hence making prompt vulnerability mitigation an essential priority. Exploitation Methods These recently disclosed vulnerabilities exploit environment variables and improperly sanitized input to achieve arbitrary code execution through multiple means. For CVE-2024-48990 and CVE-2024-48992, attackers set PYTHONPATH or RUBYLIB to directories that contain malicious libraries to gain arbitrary code execution. Needrestart may accidentally load malicious librariesthat allow root code execution. Placing one in an area specified by PYTHONPATH could allow its execution without authorization from needrestart. CVE-2024-48991 exploits a race condition where attackers can switch out a valid Python interpreter for one that contains malware just before needrestart runs it, thus leading to code execution and, ultimately, code theft. CVE-2024-10224 and CVE-2024-11003 exploit Perl's ScanDeps module by creating shell metacharacters files. Arbitrary commands may be executed when needrestart scans these files. Reasons Behind Not Releasing Exploit Code Qualys has decided not to publicly release the exploit code for these flaws for several reasons. First, withholding it helps avoid abuse. Publishing exploit details could facilitate immediate exploitation by malicious actors, leading to widespread attacks. Secondarily, by not disclosing exploit details publicly, Qualys encourages responsible patching, allowing administrators and developers to update systems without the immediate pressure of potential attacks looming over them. Furthermore, many systems remain unpatched, or administrators are unaware of vulnerabilities. Hence, withholding the exploit code allows these systems to be updated and protect themselves before anyone can publicly release exploit details. Practical Advice & Mitigation Strategies for Linux Admins Administrators should take several key steps to mitigate these vulnerabilities and limit potential security threats. First, they should ensure they use the latest version of needrestart , including patches addressing these vulnerabilities. Regularly reviewing Ubuntu repository updates and security advisories is crucial. Monitoring package repositories for updates and applying security patches as soon as they become available is vitally important. Debian and Ubuntu have already responded to these bugs by releasing important security advisory updates. Administrators should set policies that restrict and validate environment variables used byprivileged processes, limiting the influence of potentially risky environments such as PYTHONPATH and RUBYLIB variables. Implementing mandatory access control mechanisms like AppArmor or SELinux can increase system security by restricting permissions for processes like needrestart running with root privileges. Routine security audits and process monitoring are invaluable ways to detect suspicious activities or potential exploit attempts while limiting attack surfaces by restricting Ruby interpreter installation on servers. This can lessen risks associated with exploit attempts. Careful implementation of unattended upgrades can prevent unintended privilege escalation. Close monitoring and logging are also recommended to protect system users against manipulating environment variables, race conditions, and other risky behavior. Furthermore, educating users about potential dangers associated with environmental manipulation or risky behaviors is necessary to protect systems against exploitation. How Can Admins Configure needrestart Securely? Linux administrators looking to configure needrestart securely should begin by making sure they use the most recent version since updates often contain critical security fixes and improvements. They can install or upgrade needrestart using their package manager ( apt-get on Debian systems or yum on Red Hat systems). Admins can manage configuration via the /etc/needrestart/needrestart.conf file. This file enables administrators to set different options, such as which services should automatically restart and notifications about critical services that require manual intervention. Admins should take several security measures with needrestart, including setting it to operate with minimum privileges by running it under a user account with least privilege access, thus decreasing risk if the utility is compromised. Furthermore, administrators can leverage system logs to monitor needrestart actions and integrate them with centralized solutions for better oversight.They can also ensure secure access through restricted permissions to the configuration files, which only allows trusted users access to make adjustments, combined with automated restarts and thorough logging capabilities. Our Final Thoughts on Addressing These Easily Exploitable Bugs The vulnerabilities recently identified in needrestart emphasize the necessity of employing stringent security practices and maintaining systems with care. By understanding their nature, potential exploitation methods, and mitigation techniques, administrators can protect their systems against serious harm. Staying updated , applying patches quickly, and employing security mechanisms are vital in protecting against these flaws and guaranteeing server environments' integrity and safety. Are you affected by these bugs? Have You patched? Let us know @lnxsec! . Unfortunately, Qualys researchers identified five vulnerabilities that, if exploited by local attack. researchers, qualys, recently , revealed, critical, vulnerabilities , existed. . Brittany Day
Longevity in computing can be beneficial and threatening. Long-standing software accumulates stability over time while becoming potentially more vulnerable. Recently, X.Org , one of the most ubiquitous display servers within the Linux ecosystem, disclosed an alarming finding : an 18-year-old local privilege escalation vulnerability has been within its code base since 2006. . To help you understand and proactively address this threat, I’ll explain how it works, its impact, who is affected, and practical measures you can implement to mitigate risk. Understanding This X.Org Flaw & Its Impact CVE-2024-9632 is a heap-based buffer overflow vulnerability that allows attackers to gain elevated privileges on impacted systems. The issue stems from a defect within the _XkbSetCompatMap function, which improperly resizes memory buffer sym_interpret without updating its size parameter properly (size_si), instead only updating num_si (which indicates how many elements can fit into its capacity). This grave oversight has far-reaching ramifications. Since its existence in 2006 and the subsequent release of xorg-server-1.1.1, which occurred shortly after, this vulnerability could potentially impact many systems that use various versions and iterations of X.Org server implementations. Versions before 21.1.14 in Xorg-server and 24.1.4 in Xwayland server implementations are most vulnerable. The risk associated with this vulnerability is significant, as it creates the basis for privilege escalation. While X.Org Server typically doesn't run with root privileges, those configured so can be leveraged by local users for privilege escalation and even remote attacks when X11 sessions are tunneled over SSH—an approach commonly taken when remote graphical interfaces are necessary. Navigating This Flaw: Practical Advice for Mitigating Risk The Linux community has responded rapidly to this issue. Leading Linux distributions have issued advisories and patches to protect users against vulnerabilities relatedto CVE-2024-9632. Users and administrators must take immediate, proactive measures to mitigate the associated risks with the X.Org Server. Updates should be installed quickly to implement patched versions such as xorg-server-21.1.14 and Xwayland-24.1.4 or later. Most Linux distributions include updated packages in their default repositories for installation via their package manager. Root access should also be restricted when running the X.Org Server implementation as root—something not typical in modern distributions—to lower the risk of privilege escalation attacks and incidents. In addition, security advisories from Linux distribution security teams and X.Org development teams must be closely followed, with swift responses made upon receipt of new recommendations or issues as soon as they arise. Adopting security best practices on systems running X.Org Server is essential. These should include regular system updates, firewall usage, and applying the principle of least privilege for user accounts so they only possess the permissions required to complete their tasks. Integrating system monitoring tools is highly recommended to increase system protection against anomalous behavior that might indicate the exploitation of this vulnerability. Alternatives like Wayland could provide greater peace of mind for those seeking an added layer of security, although compatibility issues and considerations may exist. When new issues are discovered, researchers must follow responsible disclosure practices and communicate through appropriate channels before going public with any defects. Furthermore, IT staff should receive education on the nature and potential impact of the vulnerability as well as effective mitigation strategies to build up a robust defense. Does this security bug impact your systems? Have you patched to mitigate your risk? Connect with us on X @lnxsec - we’d love to hear how this issue has affected you and how you’ve handled it. Our Final Thoughts on AddressingThis Persistent X.Org Bug CVE-2024-9632 cannot be understated: an 18-year vulnerability within critical Linux infrastructure is rarely seen, especially one capable of local privilege escalation. While a patch for CVE-2024-9632 now exists, its nature underscores the significance of ongoing monitoring, audits, and timely patch management within open-source communities. Although CVE-2024-9632's discovery may be alarming, it also offers an invaluable opportunity to reflect on and improve industry security practices. Both maintainers and users should take proactive steps to help mitigate similar threats in the future. Linux community members now face the daunting task of remediating this specific vulnerability and addressing systemic issues that enabled its existence to go unnoticed. This exploit will undoubtedly raise awareness and spur the adoption of stringent security practices throughout the open-source ecosystem. The digital landscape can become safer through concerted action by users, developers, and vendors. . The X.Org vulnerability poses serious risks to system integrity, affecting Unix-like OS graphical servers and risking data breaches and unauthorized access. X.Org security, buffer overflow risks, privilege escalation threats, Linux update policies, system security practices. . Brittany Day
In the ever-evolving cybersecurity landscape, a new concern has come to light for Linux admins—a claimed zero-day vulnerability for Local Privilege Escalation (LPE) in Linux systems through the GRUB bootloader . This new threat underscores the perpetual cat-and-mouse game between threat actors and the open-source community. . Let's examine the flaw, its impact, and practical strategies for protecting against it to help you understand this threat and the measures you can take to secure your systems against it. Understanding This Vulnerability The GRand Unified Bootloader (GRUB) is an integral component of Linux systems responsible for loading kernel modules and booting the operating system. If GRUB contains undocumented vulnerabilities that allow attackers to gain unauthorized access, like the zero-day recently identified, malicious actors could leverage them to escalate privileges on compromised machines, potentially taking full control of the system without prior authorization. Exploitation of this LPE vulnerability involves manipulating the boot process. Attackers could insert malicious code or modify existing bootloader entries to gain elevated privileges during system startup. Given its high privilege status as one of the initial software services to run on any machine, the potential scope for exploitation of GRUB flaws is significant. This bug impacts GRUB versions 1.98 to 2.02. This is far from the first time GRUB has been targeted. In 2015, CVE-2015-8370 was discovered and fixed, which allowed attackers to bypass authentication by pressing the backspace key 28 times at the GRUB username prompt. Then in 2020, the notorious BootHole flaw ( CVE-2020-10713 ), which could be exploited to install malware during the boot process, was identified and mitigated. What Are the Security Implications for Linux Admins? The security implications of this issue are substantial, including but not limited to: Data Theft: Access to sensitive information and intellectualproperty. System Damage: Potential for wide-reaching damage to system integrity and operations. Persistent Access: Ability to establish a foothold on the system for ongoing exploitation. Lateral Movement: Compromising additional systems within the network from the initial foothold. Compliance Concerns: Violating regulatory requirements by failing to protect against known vulnerabilities. Practical Mitigation Advice for Linux Admins While fixes for this bug have not yet been released, there are several steps that Linux admins can take to mitigate the threat posed by this and similar vulnerabilities: Set Up a GRUB Password: Bypass the security risks caused by unauthenticated users editing boot entries or entering single-user mode with an effective password-protected GRUB menu, as well as safeguarding /etc/grub.d/00_header file to set a secure configuration file GRUB is more difficult for others to gain entry to and edit than before. Secure the GRUB Configuration File: Set the correct file permissions on /boot/grub/grub.cfg to prevent unauthorized modifications of its content. Typically, permissions should be set so that root can read them only (chmod 400 or 0400). Use Full Disk Encryption (FDE): Implementing FDE can prevent attackers from accessing or altering files on the disk, including those associated with the GRUB configuration. Utilize United Extensible Firmware Interface Secure Boot: Secure Boot ensures that only signed bootloaders and kernels approved by the platform owner can be executed, helping prevent the execution of an infected GRUB bootloader. Use Integrity Monitoring Tools (TPMs): These tools should be employed to safeguard bootloader integrity. Integrity-checking mechanisms like Grub-verify can help detect unapproved changes. Restrict Boot Options: Reduce available boot options in GRUB to essential ones, eliminating extraneous options that could weaken boot-time security. Physically Secure Machines: Physicallysecure machines, as attackers with local access could use bootable devices or tools to bypass bootloader security. Back Up the GRUB Configurations Files Regularly: In case of an attack, this will allow for faster restoration and analysis of any changes introduced by threat actors. Monitoring & Auditing: Monitor GRUB logs, audit any modifications to bootloader configuration, and enable auditing for access or alterations of these changes. Restrict Permissions: To prevent any possible tampering with the Grub.cfg file generated in /etc/grub.d/ , its scripts should have restricted permissions and should be owned by root to ensure maximum protection from potential compromise. Use Security Modules: Security modules, like GRUB's own password_pbkdf2 feature, can encrypt passwords within GRUB configuration files. Restrict Recovery Mode: To avoid unauthorized access to recovery options, disable or password-protect recovery mode entry in GRUB to prevent access. Stay Informed: Keep up-to-date with security advisories released by your Linux distribution. Regularly check resources like the CVE database and security mailing lists. Regular Updates: Apply system updates promptly. This includes updates to the bootloader, kernel, and all system packages. To maintain integrity during the update process, use trusted repositories and signatures when updating GRUB. Focusing on these GRUB-specific strategies can significantly decrease the odds of successfully exploiting the bootloader and help uphold system integrity. If new security patches become available that address specific vulnerabilities in GRUB, implement them quickly while adhering to best practices for ongoing security management of this crucial software component. Our Final Thoughts: What Can We Learn From This Discovery? Security in open-source software is community-driven. While a zero-day vulnerability in GRUB poses a severe threat to system integrity, its discovery should serve as a wake-up callfor administrators who must strengthen their defenses against such exploits. As part of its response plan, the Linux ecosystem must collaborate in analyzing, patching, and communicating any vulnerabilities like these to ensure its resilience against further attacks. Diligence is critical in cybersecurity. A combination of proactive measures, community cooperation, and robust policies can help protect Linux systems against current and potential future exploits. . Assess the recent zero-day local privilege escalation (LPE) vulnerability found in GRUB and explore effective measures to secure your Linux environments.. Linux GRUB Threat, Privilege Escalation Linux, GRUB Vulnerability Management. . Brittany Day
Multiple security vulnerabilities have recently been discovered in the XOrg Server prior to 21.1.11, and Xwayland display implementations prior to 23.2.4. These vulnerabilities could potentially result in heap overflows, out-of-bounds writes, and local privilege escalation, potentially enabling attackers to view additional infrastructure to attack, add or delete users, or modify permissions of files or other users. . The xorg-server v21.1.11 and xwayland v23.2.4 have been released to address these issues. It was recently discovered that the fix for these vulnerabilities was incomplete, resulting in a possible regression. Updates have now been released to fix this issue. What Are The Implications of These Flaws? How Can I Mitigate My Risk? These issues are an important warning to Linux admins, infosec professionals, internet security enthusiasts, and sysadmins, urging them to take immediate action to protect their systems. The potential consequences of ignoring these vulnerabilities could be severe, ranging from unauthorized access to system compromise. The fact that some of these vulnerabilities have remained unpatched for several years raises concerns about the overall security of the X server. Switching to Wayland instead of relying on the X server may be beneficial for admins, as the X server remains unpatched against many security vulnerabilities , facilitating the need for the migration to a more secure alternative. This raises the question of whether the open-source community should shift its focus toward Wayland and encourage Linux distribution maintainers to make it the default display server. Even if a Linux distribution already uses Wayland by default, the Xwayland implementation is likely still in use for compatibility with X11 apps. This highlights the importance of ensuring that systems are updated with the latest version and patched against these vulnerabilities . The impact of failing to do so could be significant, as any breach in the Xwayland implementation couldpotentially compromise the security-conscious infrastructure. The implications of these security vulnerabilities extend beyond immediate patches. It prompts reflection on the open-source community's approach to security, raising questions about the overall effectiveness of the current security practices. How can future vulnerabilities be prevented or detected earlier? We'd like to see increased scrutiny of the codebase by the community and regular security audits to identify and patch potential vulnerabilities. Our Final Thoughts on The Impact & Implications of These Bugs In conclusion, these vulnerabilities are a stern reminder for Linux admins, infosec professionals, internet security enthusiasts, and sysadmins to prioritize patching the XOrg Server and Xwayland vulnerabilities. The long-term consequences of any compromises could be severe, necessitating a proactive approach to ensure system integrity. We encourage a critical examination of current security practices, potentially paving the way for a broader discussion on the future of display servers in the Linux ecosystem. Above all, security practitioners must stay informed about vulnerabilities, their impact, and effective mitigation strategies by subscribing to industry newsletters like our Linux Advisory Watch . Stay safe out there, fellow Linux users! . Recent advancements in xorg-server and xwayland address significant security gaps, enhancing overall system integrity and robustness.. XOrg Security,Xwayland Update,Linux Admin Practices,System Compromise Prevention,Open Source Security. . Anthony Pell
For over a decade now the X.Org Server has been seeing routine security disclosures in its massive codebase with some security researchers saying it's even worse than it looks and security researchers frequently finding multiple vulnerabilities at a time in the large and aging code-base that these days rarely sees new feature work. Now another disclosure has made by security researchers. . CVE-2023-1393 is a use-after-free vulnerability where it could lead to local privilege escalation if the xorg-server is still running as root and remote code execution for SSH X forwarding sessions. If a client explicitly destroys the compositor overlay window, the X.Org Server leaves a dangling pointer to that window and will trigger a use-after-free later on. The disclosure was made a few minutes ago on the mailing list . The link for this article located at Phoronix is no longer available. . An attacker could exploit this flaw to gain elevated access permissions, impacting memory management and potentially allowing unauthorized access to sensitive resources. X.Org Server Vulnerability, Privilege Escalation, Code Execution, Security Advisory. . Brittany Day
Redhat has just just published a risk advisory about a vulnerability in the Linux Kernel that allows for local privilege escalation. This vulnerability is tracked as CVE-2022-3910 (CVSS score: 7.4). . This vulnerability is referred to be a use-after-free problem, and it can be found in io uring on the Update of Reference Count. io uring is an interface for making system calls in Linux. It made its debut for the very first time in the mainline Linux Kernel version 5.1 in the year 2019. It gives an application the ability to start system calls that may be carried out in an asynchronous manner. A Use-After-Free vulnerability and a Local Privilege Escalation may be caused in the Linux kernel by incorrectly updating the reference count in the io uring function. When io msg ring is called with a fixed file, it invokes io fput file(), which incorrectly lowers its reference count. Fixed files are those that are permanently registered to the ring and must not be stored in a separate location. . A critical out-of-bounds memory access vulnerability in the Linux Kernel presents a potential risk for local privilege escalation. Immediate attention required.. Local Privilege Escalation, Kernel Patching, Red Hat Security. . Brittany Day
The local privilege escalation vulnerability in the Linux Kernel was reported by Redhat, and its CVE code is 2022-3977 . The problem is that the most recent Linux kernel upstream contains a use-after-free vulnerability called mctp sk unhash that may be exploited to elevate privileges to root. . When a program tries to utilize memory that has been released or no longer assigned to it after it has been given to another application, it is known as a use-after-free vulnerability. In cyber attack situations, this might result in arbitrary code execution or provide an attacker access to remote code execution capabilities. It can also cause crashes and unintentional data overwriting. The concurrent DROPTAG ioctl and socket close may result in a race scenario, which is the cause of the vulnerability . The Active Defense Lab of Venustech has reported the vulnerability . “An unprivileged user duplicated it using new namespaces. Local Privilege Escalation would result from it (LPE). It was first made available in v5.18.0; the commit is 63ed1aab3d40aa61aaa66819bdce9377ac7f40fa. It had an impact on stable and upstream v6.0.0. The mctp kernel module, however, is not loaded automatically, according to the seclists website. . An urgent vulnerability related to local privilege elevation in the Linux kernel requires swift updates to avert potential misuse.. Linux Kernel Security, Privilege Escalation, Critical Patch. . Brittany Day
Get the latest Linux and open source security news straight to your inbox.