Latest Linux Security News & Information

security advisorydenial of serviceOpenSSL

Linux: OpenSSL Flaws Important DoS Issues CVE-2025-9230, 9231, 9232

Three new OpenSSL flaws, CVE-2025-9230, 9231, and 9232, were patched upstream this week. They aren’t another Heartbleed, but they still matter. Each one can open a small gap in encryption or memory handling, depending on how your distribution builds and ships OpenSSL. . Right now, the question isn’t whether the fixes exist; it’s how fast they reach your systems. Some distros have moved already. Others are still packaging or backporting. The difference between those timelines is where exposure lives. For administrators, this update is about knowing which paths are safe and which still lead through vulnerable code. The broader context for linux security comes down to visibility: who’s patched, who hasn’t, and what that means for the infrastructure that depends on OpenSSL every day. Distro Patch Status & Timelines Patch coverage is uneven across distributions, and that’s where most of the current exposure lives. Some have already moved; others are still packaging or staging fixes. Debian: Patched with OpenSSL 3.5.4-1 in unstable (sid) on September 30, with stable-security updates following on October 1. Ubuntu: No USN for these CVEs yet , but ESM and Pro users will receive backports once builds are complete. Arch Linux: Still on OpenSSL 3.5.3; 3.5.4 hasn’t landed in core yet. Alpine: Patched early with OpenSSL 3.5.4-r0 in edge on September 30. Fedora / RHEL / CentOS: No public advisory yet, though fixes are likely being rolled out quietly through standard backports. SUSE / openSUSE: No listing for these CVEs as of October 3; previous patches like SU-20251550-1 suggest ongoing review. Special cases matter too. Long-term Ubuntu LTS versions fall under ESM coverage, while Red Hat and SUSE users need to confirm patch status through advisories, not just package numbers. For the linux security community, this is the usual bottleneck: patch speed versus patch existence. Knowing which systems are actually fixed defines strong linuxsecurity practice in fast-moving vulnerability cycles. OpenSSL Vulnerabilities: Technical Breakdown and Linux Exposure The three OpenSSL flaws, CVE-2025-9230, 9231, and 9232, target separate code paths, each tied to specific feature use. Most Linux systems won’t see full exposure, but the potential for disruption is real enough to take seriously. CVE-2025-9230 (CMS PWRI Out-of-Bounds Read/Write) This flaw affects how OpenSSL handles CMS PasswordRecipientInfo structures. When applications decrypt attacker-supplied CMS messages, memory access errors can occur, leading to denial of service and, in rare cases, code execution. It appears mainly in S/MIME mail processing, PKI automation tools, and certain gateways that handle encrypted messages, as outlined in the OpenSSL CMS documentation and detailed further by Tenable . CVE-2025-9231 (SM2 Timing Side-Channel on 64-Bit ARM) This bug opens a timing side-channel in the SM2 implementation, allowing potential private-key recovery on 64-bit ARM. It mainly affects deployments that actively use SM2, which is common in Chinese cryptographic stacks but rarely enabled elsewhere. Real usage shows up in GmSSL and openEuler’s ShangMi frameworks; administrators using those variants should review the OpenSSL SM2 API for affected code paths. CVE-2025-9232 (HTTP Client no_proxy + IPv6 Out-of-Bounds Read) This issue appears when an HTTP client relies on the no_proxy environment variable with IPv6 hosts. The condition can cause an out-of-bounds read and crash, impacting tools like curl, wget, Python requests, and Go’s net/http stack. It’s easy to trigger, which makes it more visible in developer and CI environments than on production servers. Upstream fixes have landed across maintained branches: 3.5.4, 3.4.3, 3.3.5, 3.2.6, 3.0.18, 1.1.1zd, and 1.0.2zm, in both the OpenSSL vulnerability index and release notes . Unlike Heartbleed, these are not broad memory-leak issues or remote exploits waiting to happen. They’re narrower,context-driven flaws, closer in scope to the ROBOT class of OpenSSL bugs, yet still a priority for anyone managing linux security in production. Effective linux security means mapping feature usage to risk: CMS in mail gateways, SM2 in region-specific stacks, and no_proxy with IPv6 in client tools. Inventory, verify, and patch fast. Exploitability & Threat Evidence As of October 3, 2025, there is no public proof of concept for these three CVEs and no confirmed in-the-wild exploitation. They are not listed in CISA’s Known Exploited Vulnerabilities catalog, which means urgency is real but not an emergency. PoCs / public code: None published as of October 3, 2025. Continue to monitor research feeds and vendor advisories and verify any third-party claims before acting on them. In-the-wild: No reports of active exploitation; the CVEs do not appear in CISA KEV at this time. Difficulty (quick triage): CVE-2025-9230: Exploitation requires a CMS decryption path in the application stack. Denial of service is the realistic outcome; RCE is possible only when an application actively decrypts attacker-supplied CMS messages. CVE-2025-9231: The SM2 timing channel needs ARM64 hardware plus SM2 usage. Remote timing attacks are difficult; the highest risk is local or co-located attackers with precise measurement access. CVE-2025-9232: Easy to trigger when NO_PROXY interacts with IPv6 hosts. Impact is typically a client crash or DoS, not data theft. Track ongoing signals on active monitoring sites like inthewild.io and vendor trackers. For the linux security practitioner, that means prioritizing hosts by feature exposure and attacker accessibility rather than treating every OpenSSL instance the same. Patch Lag and Exposure in ARM, IoT, and Edge Linux Systems Server updates happen fast. Embedded devices move at a different pace. ARM boards, IoT firmware, and edge systems often run the same code for years without revision. Once OpenSSL gets baked into a firmware image, itrarely moves again. The same build can sit in production for years, unchanged except for what runs around it. On boards like Raspberry Pi or BeagleBone, the library often comes from a cross-compile step or a vendor SDK that ships with its own version pinned. Developers following community toolchains sometimes miss upstream patches because builds are frozen between releases. By the time those binaries are reused in another project, the upstream source has already moved on. A version checked months ago may already be behind. IoT introduces a harder problem. Firmware updates are rare, and many vendors use internal OpenSSL forks that never see maintenance. The result is silent drift. Devices that appear stable may still be running code with known flaws. SM2 support raises risk in certain markets. Some regional cryptography stacks enable it by default, particularly in appliances built for Chinese networks. For those environments, CVE-2025-9231 is not theoretical. It’s active exposure waiting on a rebuild. For teams managing linux security across mixed hardware, visibility is the challenge. Most tools track package versions, not the libraries baked into firmware. Knowing what’s actually compiled is the first step toward control. The slower the patch cycle, the more important the audit becomes. That’s the quiet side of linux security, the part that fails when attention fades. Closing the Gaps: Patching and Hardening OpenSSL The patches are out. The work now is confirming they’ve landed everywhere they should. Start by checking what version you’re running: openssl version -a You’re safe if it reports 3.5.4, 3.4.3, 3.3.5, 3.2.6, 3.0.18, 1.1.1zd, or 1.0.2zm. Anything older should be upgraded right away. Upgrade commands: Debian / Ubuntu: sudo apt update && sudo apt install --only-upgrade openssl RHEL / CentOS / Fedora: sudo dnf upgrade openssl SUSE: sudo zypper refresh && sudo zypper update openssl Arch: sudo pacman -Syuopenssl Alpine: sudo apk update && sudo apk upgrade openssl If patching takes time, there are a few stopgaps that reduce exposure. Disable CMS PWRI support until fixed. Leave SM2 turned off on ARM64 unless absolutely required. Avoid IPv6 entries in the NO_PROXY variable until updated builds are confirmed. Monitoring helps catch what patches miss. Watch for new OpenSSL-related crashes or odd traffic around CMS or IPv6 parsing. Update IDS or IPS signatures that detect malformed CMS messages or proxy anomalies. Audit configurations for any accidental use of SM2 in production paths. The deeper lesson sits below the patch notes. Memory safety in C is still the root problem here, and fragile modules like ASN.1 and CMS keep showing it. Rewriting them in safer languages like Rust would stop this class of issue before it starts. Silent backports also add confusion; administrators need advisories that say what’s fixed, not just version numbers. For Linux security, this is the day-to-day reality: patch what you can, mitigate what you can’t, and keep an eye on what breaks. Strong security doesn’t just mean quick updates. It means verifying them, documenting them, and knowing where the blind spots are. Staying Ahead of the Next OpenSSL Flaw Patch OpenSSL as soon as possible, but don’t stop at version numbers. Read the advisories, confirm what’s fixed, and make sure the changes actually reached your systems. Audit where CMS, SM2, or no_proxy are in use, especially on ARM and IoT fleets, where updates move more slowly. Those are the environments most likely to fall behind. Keep monitoring for OpenSSL-related crashes or denial-of-service attempts until every patch is confirmed live. The larger point hasn’t changed. Vulnerabilities like these will keep appearing, not because the software is neglected, but because the codebase is vast and written in a language that allows small mistakes to matter. Sustained linux security depends on fast patch cycles, honest advisories, andpressure on upstream projects to make those details clear. . Discover the recent vulnerabilities discovered within OpenSSL and the approaches being taken by various Linux distributions to address patching and the associated security concerns.. OpenSSL flaws,Linux security,patch coverage,DoS risks,CVE-2025-9230. . MaK Ulac

Oct 06, 2025 •

MaK Ulac Security Vulnerabilities

security advisorypatchlinux distribution

Linux BPF Update: Speculation Barriers Against Spectre Threats

In our ongoing quest to combat sophisticated security vulnerabilities, we Linux admins are always looking for innovative new tools and techniques to safeguard our systems. On Monday, a "request for comments" patch series introduced key Spectre mitigations by adding speculation barriers specifically for Berkeley Packet Filter programs. . Spectre vulnerabilities continue to pose a significant Linux security threat. Thus, these patches aim to close any security holes within BPF programs, which are widely used for dynamic network monitoring, tracing, and various low-level Linux system operations. To help you understand these proposed patches and their potential impact on your security posture, I'll explain the role of speculation barriers in mitigating the risk of Spectre flaws, the potential impact of these patches, and my predictions for the future of BPF security. Let's begin by understanding Spectre vulnerabilities and how they are exploited. Understanding Spectre and Speculative Execution Bugs To fully grasp the significance of the recently proposed patches for Spectre vulnerabilities , it's essential to understand their nature. Modern CPUs use "speculative execution" as a performance-boosting strategy. This involves making educated guesses about which path code might take to execute instructions before actual CPU instructions confirm them. While this helps programs run more quickly, it also introduces security issues. Spectre flaws exploit this behavior to access sensitive information like passwords and encryption keys that should remain out of reach to unauthorized users. Examining The Role of Speculation Barriers in Mitigations Recent patches aim to address these issues by implementing speculation barriers - safeguards that stop CPUs from speculatively executing code paths that could expose sensitive information. By strategically placing these barriers within BPF programs, developers can ensure any potentially dangerous speculative execution is immediately stopped before itcauses harm. From a security perspective, this significantly reduces the attack surface and disrupts speculative execution processes, making it much harder for attackers to exploit vulnerabilities and access sensitive information. This is particularly significant in BPF programs, as they regularly manage and monitor system operations. The Potential Performance Impact of These Patches Though speculation barriers increase security, they do come with potential downsides. One major concern is their impact on performance, as speculation barriers can add unnecessary overhead that delays certain operations from being executed efficiently and swiftly - especially in environments that rely heavily on BPF programs for their efficiency and speed. To prevent potential performance degradation, admins must ensure they test patches thoroughly in their environments to gauge the full extent of their performance implications. Achieving an appropriate balance between improved security and acceptable performance is essential, including tweaking configuration settings or optimizing other areas to lessen their effect. Compatibility and Planning for Updates Administrators can ensure a seamless transition by verifying compatibility between patches and their current kernel versions and identifying which versions include updates that must be planned for. This is especially critical in systems handling sensitive information, as staying current with security patches is integral to maintaining a secure environment. Promptly implementing updates is of utmost importance, as delays in applying security patches could expose systems to attacks. Therefore, Linux admins must devise an update strategy that includes testing patches in non-production environments before rolling them out gradually to production servers to minimize disruption while simultaneously applying all relevant patches. The Importance of Continuous Monitoring and Adaptation Regardless of recent efforts to implement speculation barriers, cyberthreats are ever-evolving and new vulnerabilities emerge daily while attackers devise novel methods of exploiting system weaknesses. Therefore, constant monitoring and adaptation are vital to maintaining robust security. Administrators must focus on installing current patches and pay close attention to future developments. This means staying informed with recent security research findings, attending relevant conferences, and joining community discussions to anticipate emerging threats and be better positioned when they arise. Admins should regularly conduct security audits and vulnerability assessments as part of their security strategy, alongside applying patches. These audits allow us to detect potential weaknesses that have been overlooked or have arisen due to changes in the environment, giving an opportunity to proactively address such weaknesses to maintain a strong security posture. Balancing Security and Performance Linux administrators face an ongoing struggle between security and performance regarding speculation barriers - while they are critical in mitigating Spectre vulnerabilities, they may negatively affect BPF programs essential to various system operations. To achieve balance, administrators should consider employing additional performance optimization techniques. These could include fine-tuning system configurations, augmenting hardware capabilities to better work within new security constraints, or optimizing code to function more efficiently within these parameters. By monitoring system performance closely and making necessary adjustments, they can ensure that security improvements do not significantly compromise overall functionality. Looking Ahead: The Future of BPF Security Introducing speculation barriers into BPF programs is just the first step on a long road toward more secure systems. As cybersecurity advances, new techniques and tools will emerge to combat emerging threats. We Linux administrators must remain aware of these developments to secure oursystems. One area of focus should be the ongoing development of BPF itself. As more sophisticated programs and uses arise for BPF executions, their need for robust security measures increases exponentially - possibly including new types of barriers or entirely novel approaches for protecting executions of the service. Collaboration among security communities will be essential in shaping BPF security going forward. By sharing knowledge, insights, and best practices, the community can work collectively toward strengthening BPF programs and their supporting systems' security. Our Final Thoughts on Mitigating Spectre Vulnerabilities in BPF Programs Recent patches introducing speculation barriers for BPF programs represent a substantial step toward protecting Linux systems against Spectre vulnerabilities. By understanding their role and planning for potential performance impacts and compatibility concerns, Linux administrators can effectively enhance system security. By monitoring new threats as they emerge and working with the security community to adapt systems against them, administrators will also ensure a robust environment where sensitive data remains safe while performance is optimized. . Meltdown exploits represent a serious risk; updates incorporate speculative safeguards to enhance Windows protection.. BPF Security, Linux Admin Strategies, Spectre Mitigations, Performance Optimization, System Security Strategies. . Brittany Day

Feb 27, 2025 •

Brittany Day Security Projects

security advisoryremote code executionaccess control

Ubuntu: Secure rsync from RCE issues with critical patches

Are you using rsync to synchronize files on your Ubuntu-based Linux systems? If so, s everal severe remote code execution (RCE) vulnerabilities recently found in the widely used file synchronization utility could put you at risk of full system compromise! Left unpatched, these RCE flaws allow attackers to execute arbitrary code and compromise entire systems. . In this article, I'll walk you through determining if your systems are vulnerable and applying necessary updates to secure your rsync setup. By taking immediate action and adhering to best practices, you can ensure a robust security posture in your Linux environment. Understanding These Rsync RCE Vulnerabilities Rsync has long been an indispensable tool in a Linux administrator's arsenal, revered for its speed in synchronizing files and copying changes between systems. Various RCE vulnerabilities have recently been found in the popular utility , including a critical buffer overflow on the server's heap (CVSS 9.8, CVE-2024-12084 ) . Attention has turned towards the security implications of these severe bugs, impacting up to 660,000 servers. These vulnerabilities allow attackers to execute code remotely with elevated privileges, making fixing these holes an urgent priority. A typical exploitation scenario might involve an attacker gaining access to a system where rsync is improperly configured to operate in a daemon mode without proper security structures. This can allow unauthorized users to send malicious payloads that rsync executes, inadvertently providing access to critical infrastructure. Understanding these implications, admins must assess their systems, ensuring they’re not vulnerable to such straightforward yet devastating avenues of attack. Assessing Your Risk Determining whether your systems are at risk is a vital first step. The process begins with identifying the currently installed version of rsync across all servers. This can be done easily through the command line . Upon establishing whichversion you're dealing with, the next task is to cross-reference this with the Ubuntu security advisory detailing affected versions. This step ensures that you have a clear picture of your exposure. Admins should routinely check system logs for any signs of unusual activity related to rsync, such as unexpected access requests or error messages. Ensuring access controls are in place is crucial. You can significantly reduce your risk exposure by designating rsync to operate only for trusted users and networks. Through diligent checks and balances, identifying and understanding potential risk factors become a part of routine maintenance, which creates a robust security environment. Applying the Necessary Patches Once you have assessed your risk, the next crucial step is promptly applying the necessary updates. Updating rsync to version 3.4.0, which has patched these vulnerabilities, is vital. This is a straightforward task in Ubuntu-based systems through package managers that offer seamless upgrade paths. By executing simple commands, you can ensure that your system runs the secure version of rsync, mitigating immediate risks. After applying these updates, verification is essential. It’s important to verify that the patches have been applied correctly. This means checking the version of rsync and ensuring there are no lingering issues. Regularly running system health checks post-update ensures everything operates smoothly and according to your expectations. Best Practices for Robust Rsync Security Mitigation isn't just about patching vulnerabilities; it's about instituting best practices that future-proof your systems. Establishing strict access controls on rsync usage can vastly improve security. Limiting its operation via network security groups ensures only trusted systems and users can engage with rsync services, preventing unauthorized attempts. Enabling a secure shell (SSH) for rsync operations adds another layer of security. SSH provides encrypted channels for data transfer,ensuring that even if data were intercepted, it wouldn't be usable to potential attackers. Configuring rsync to log activity diligently allows admins to monitor its usage effectively, pinpointing any unusual patterns that might indicate a security threat. Regular security audits can help uncover potential misconfigurations or overlooked vulnerabilities. Automated vulnerability scanning tools can provide robust checks across your infrastructure, assisting in the early identification and mitigation of security gaps. Combining these practices creates an environment where security isn't an afterthought but a continuous, proactive process. Preparing for the Future Staying ahead of potential security vulnerabilities requires a forward-looking approach. Stay informed by subscribing to security newsletters . This proactive information gathering allows admins to be among the first to know about potential threats and the solutions that accompany them. Education and user awareness are also significant factors. Regular training sessions can ensure all stakeholders are aware of security protocols and the importance of maintaining them. Encouraging a culture of security mindfulness means everyone is vigilant, reducing the likelihood of vulnerabilities being overlooked. Moreover, maintaining comprehensive documentation of your systems and the changes applied is critical. This documentation aids in compliance with internal and external policies, providing a clear audit trail. Should any security incident occur, detailed records of updates and configurations can be invaluable for forensics and analysis, helping you understand what went wrong and how to prevent similar incidents. Our Final Thoughts on Mitigating These Recent Rsync Flaws These recently identified rsync vulnerabilities serve as a reminder of the constant vigilance required in IT security. For us Linux security admins, taking steps to address these vulnerabilities via the patches released and engaging in best practices is imperative.Integrating these measures with ongoing education and documentation means you’re not just reacting but preparing for tomorrow’s challenges. With the right strategies and a proactive approach, you can ensure that your systems remain secure without sacrificing the efficiency that tools like rsync bring. Safeguarded systems protect sensitive data and maintain stakeholders' trust, enabling you and your organization to focus on growth and innovation without risking compromise. . Discover methods to safeguard your rsync configuration from Remote Code Execution risks, address weaknesses, and adopt optimal strategies for Unix environments.. Rsync Security, Remote Code Execution, Ubuntu Security, Linux Administration, Rsync Vulnerabilities. . Brittany Day

Jan 20, 2025 •

Brittany Day Security Vulnerabilities

security advisoryupdatecritical

Linux Kernel Netfilter Vulnerability: CVE-2024-26925 Critical DoS Threat

A critical vulnerability was discovered in the Linux kernel's netfilter subsystem, specifically within the nf_tables component, posing potential risks to systems worldwide. The vulnerability, CVE-2024-26925 , arises from improperly releasing a mutex within the garbage collection (GC) sequence of nf_tables. It could potentially lead to race conditions and compromise the stability and security of the Linux kernel. . What Is the Impact of This Vulnerability on Linux Security? The technical details of the vulnerability and its impact on the Linux kernel's security should be highlighted. During the critical section, the commit mutex must not be released between nft_gc_seq_begin() and nft_gc_seq_end. The async GC worker could collect expired objects and get the released commit lock within the same GC sequence if this occurs. The implications of this kernel flaw are severe for systems utilizing the nf_tables for network packet filtering. Thus, admins and users should apply the latest updates to safeguard their systems. This proactive patching underscores the Linux community's commitment to security and stability and the importance of staying updated and informed on Linux security patches and best practices. For Linux admins, infosec professionals, internet security enthusiasts, and sysadmins, this vulnerability could have substantial long-term consequences for their systems and networks. It raises questions about the overall security of the Linux kernel and prompts critical analysis of the patching process and its effectiveness. However, the implications of this vulnerability extend beyond the immediate need for patching, elevating the importance of understanding and addressing potential weaknesses in open source and Linux security . This article aims to ensure that users are aware of their risks and equipped to take necessary actions to mitigate potential threats. Our Final Thoughts on This Critical Kernel Bug The critical vulnerability identified in the Linux kernel's netfiltersubsystem underscores the ongoing challenges in maintaining robust security measures for open-source software. The implications of this vulnerability on systems worldwide necessitate a heightened focus on proactive security measures, patching, and ongoing monitoring to ensure the resilience of Linux environments. This article aims to provide valuable insights and takeaways for the global community of Linux admins, infosec professionals, internet security enthusiasts, and sysadmins by emphasizing the impact of this flaw on security practitioners and offering actionable mitigation recommendations. . This critical weakness in the Linux kernel presents considerable dangers, requiring immediate response from system administrators and cybersecurity personnel.. Linux Kernel, Netfilter, Critical Risk, DoS, Security Update. . Brittany Day

Apr 30, 2024 •

Brittany Day Security Vulnerabilities

security advisorypatchSpectre mitigation

Linux Kernel: STIBP Coverage Fix for Skylake Systems Under Review

The Linux kernel since last year has mistakenly left systems relying on the original Indirect Branch Restricted Speculation (IBRS) for Spectre V2 mitigation without Single Threaded Indirect Branch Predictor (STIBP) coverage for cross-HyperThread dealing with this Spectre vulnerability. There is a patch underway that is resolving this issue for Intel Skylake era systems. . Since a change merged last June and being mainlined in Linux 5.19-rc2, there is no STIBP support when IBRS (the original, not to be confused with Intel eIBRS) is engaged. So in order to protect user-space threads with STIBP, this patch by Google engineer KP Singh is under review to allow having STIBP enabled with the "legacy" IBRS. Again, this just affects older processors relying on plain IBRS like those from Skylake/Skylake-derived designs. The patch is marked already for back-porting to stable Linux kernel series as well once its mainlined. The link for this article located at Phoronix is no longer available. . The Linux kernel currently does not provide STIBP capabilities for IBRS configurations, which impacts the effectiveness of Spectre V2 defenses. A patch addressing this issue is pending review.. Spectre V2, Linux Kernel Patch, Indirect Branch Mitigation, Intel Skylake Systems. . Brittany Day

Feb 28, 2023 •

Brittany Day Security Vulnerabilities

security advisorydenial of serviceupdate

Ubuntu Kernel Security Update: Critical Threats Patch for Multiple Releases

Canonical has published new kernel security updates for all of its supported Ubuntu Linux releases as a massive update that addresses more than 20 security vulnerabilities discovered by various researchers in the upstream kernels. . The new kernel security updates are available for Ubuntu 22.10 (Kinetic Kudu) , Ubuntu 22.04 LTS (Jammy Jellyfish), Ubuntu 20.04 LTS (Focal Fossa) , Ubuntu 18.04 LTS (Bionic Beaver), as well as Ubuntu 16.04 and Ubuntu 14.04 ESM (Extended Security Maintenance) releases. The most critical security vulnerability patched in these massive Ubuntu kernel updates is CVE-2022-2663 , a flaw discovered by David Leadbeater in the netfilter IRC protocol tracking implementation that could allow a remote attacker to cause a denial of service or bypass firewall filtering. This affects all Ubuntu flavors except for Ubuntu 18.04 LTS, Ubuntu 16.04 ESM, and Ubuntu 14.04 ESM systems running Linux kernel 4.15. The link for this article located at 9 to 5 Linux is no longer available. . Recent kernel security patches released for various Ubuntu versions target significant vulnerabilities and bolster overall system defenses.. Ubuntu Kernel Security Updates, Kernel Updates, Ubuntu LTS Security Patches. . Brittany Day

Jan 09, 2023 •

Brittany Day Security Vulnerabilities

security advisorypatchkernel

Linux Kernel Update: Maximum Severity RCE Threat for SMB Servers

Most businesses running SMB servers are believed to be shielded but one expert likened potential exploits to Heartbleed. . Linux has issued an update to address a kernel-level security vulnerability that affected server message block (SMB) servers. The remote code execution (RCE) flaw allowed unauthenticated users to execute kernel-level code and received the maximum possible severity rating on the common vulnerability reporting system (CVSS). Most businesses and enterprise users are believed to be safe from any potential exploitation given that the vulnerability only affected the lesser-used KSMBD module rather than the more popular Samba suite. . An urgent patch has been released by Linux to rectify a critical kernel-level vulnerability impacting SMB servers.. kernel Vulnerability, SMB Security, RCE Exploit, Linux Update, Server Protection. . Brittany Day

Dec 26, 2022 •

Brittany Day Security Vulnerabilities

security advisorycritical issuelocal privilege escalation

Linux Kernel: Critical Local Privilege Escalation Advisory CVE-2022-3977

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

Nov 16, 2022 •

Brittany Day Security Vulnerabilities

Community Poll

More Polls

Stay Ahead With Linux Security News

Refine news

Get the latest News and Insights

Community Poll

Is continuous patching actually viable?

Trending News

Misuse of Cron Jobs for Long-Term Access in Linux Environments

MXDR Provider Selection for Linux Environments and Security Services

Risks of GitHub Repo Breach on Linux Supply Chain Security

After Years of Supply Chain Attacks, npm Is Finally Closing the Door on Auto-Scripts

Explore Latest Linux Security news

Linux: OpenSSL Flaws Important DoS Issues CVE-2025-9230, 9231, 9232

Linux BPF Update: Speculation Barriers Against Spectre Threats

Ubuntu: Secure rsync from RCE issues with critical patches

Linux Kernel Netfilter Vulnerability: CVE-2024-26925 Critical DoS Threat

Linux Kernel: STIBP Coverage Fix for Skylake Systems Under Review

Ubuntu Kernel Security Update: Critical Threats Patch for Multiple Releases

Linux Kernel Update: Maximum Severity RCE Threat for SMB Servers

Linux Kernel: Critical Local Privilege Escalation Advisory CVE-2022-3977

Get the latest News and Insights

Community Poll

Is continuous patching actually viable?

Trending News

Misuse of Cron Jobs for Long-Term Access in Linux Environments

MXDR Provider Selection for Linux Environments and Security Services

Risks of GitHub Repo Breach on Linux Supply Chain Security

After Years of Supply Chain Attacks, npm Is Finally Closing the Door on Auto-Scripts

Powered By

Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases

QUICK LINKS

subscribe to newsletters!

Stay Ahead With Linux Security News

Refine news

Topics

Category

Authors

Published Date

Get the latest News and Insights

Community Poll

Is continuous patching actually viable?

Trending News

Explore Latest Linux Security news

Get the latest News and Insights

Community Poll

Is continuous patching actually viable?

Trending News

Search Topics

Powered By

Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases

QUICK LINKS

subscribe to newsletters!