GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | ||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | ||||||||||||
GeezerVison is showing linuxsecurity.com — Features Category Critical WordPress Flaw Exploited in the Wild: Learn how to protect your site and check your core update window.× Stay Ahead With Linux Security Features
 privilege escalation root access Privilege Escalation: Five Linux Exploits Give Ordinary Users RootLinux researcher Hyunwoo Kim has shown five ways to turn a limited account into root on tested Linux systems. . Root is the system’s administrator, with much more power than an ordinary user. The attacks show privilege escalation: gaining rights an account should not have. Several attacks also worked from inside containers, the separate spaces used to run apps. Shared servers let people run code without giving them control of the host. Kim’s tests show how a flaw can break that rule, allowing... 
Oct 19, 2026
 Andrew Kowal
security advisory networking What Is a Hypervisor? How It Works and Where Isolation Can FailA hypervisor creates and runs virtual machines, or VMs. . A Linux server can use one to run a Windows guest without handing Windows the whole machine. The guest gets virtual disks and processors; the server's real hardware can serve other guests at the same time. PwnEscape showed how a flaw in that shared host could break the separation. Researcher Paulos Yibelo sent packets from a Vercel cloud sandbox and received memory from the Linux host running it. The flaw was in the host's networking...
Oct 16, 2026
MaK Ulac
security advisory public-key infrastructure What Is an X.509 Certificate, and Why Can TLS Libraries Disagree?An X.509 certificate names an identity and its public key; libraries can disagree over whether the issuer was allowed to certify that name. . Those checks are part of how Transport Layer Security (TLS) establishes whom to trust. Name Constraints let a parent certificate authority (CA) limit the names a subordinate CA can sign for. A CA is a service that issues signed certificates. Those limits have to survive the full chain of checks performed by the application receiving the certificate. That...
Oct 15, 2026
Dave Wreski
security practices open-source Cultivating a Collaborative Cybersecurity Culture Against PhishingRemember when you were sent an email from a purported "bank" informing you of suspicious transactions? Phishing attacks use deceptive messages to steal information, deliver malware, or trick people into sending money. Cybersecurity awareness helps people respond safely, but it cannot prevent every attack. . Developing a collective culture around cybersecurity awareness can turn these "phishing for trouble" emails into collective eye rolls rather than cause anxiety among internet denizens....
Oct 15, 2026
Brittany Day
security tools data collection ClatScope: Powerful OSINT Integration for Linux AdministratorsCyber threats never clock out, and neither do the challenges of staying ahead. . For me, OSINT isn't just about gathering data. It's about cutting through the noise to find what truly matters. Searching various sources, dealing with different platforms, and manually cross-referencing information is time-consuming and inefficient. So, I'm constantly on the lookout for tools that simplify the process and put actionable intelligence front and center. ClatScope is one of these. It brings a range...
Oct 15, 2026
MaK Ulac
X Clear Filters
|
Refine features|
| ||
Community Poll
Explore Latest Linux Security features
risk managementopen-sourcedata integrityData Governance Framework: Linux Security and Open-Source Controls
Data governance consultancy is a compliance tool many businesses have started relying on due to the constantly changing data management environment. These tactics help businesses develop strategies and policies to ensure data and network security, privacy-enhancing technology, and integrity. Open-source security on Linux plays a crucial role in creating cloud security frameworks that provide the protection that every Linux user needs and deserves.
Linux administrationmail serveremail encryptionHow to Secure Linux Email with TLS in Postfix
It is no secret that email is the preferred method of communication for businesses - a trend that has only been magnified with the increase in remote workers brought on by the pandemic. That being said, email is effectively a plaintext communication sent from email clients to receiving email servers or from one server to another, leaving the content of messages in transit vulnerable to compromise without additional protection via encryption technology such as the Transport Layer Security (TLS) standard.
security advisoryphishing awarenessemail phishing trainingKali Linux Phishing Tools for Email Phishing Training
So long as you navigate the Internet, you will encounter a phishing attack attempt sooner or later. Cybersecurity professionals seek solutions to these threats so that attacks in network security are not as common and harmful to online users.
data protectionidentity managementcloud securityCloud Security for Small Business: A Linux Administrator’s Guide
About half of all small businesses use cloud-based hosting and infrastructure. Small- and Medium-Sized Businesses (SMBs) work with cloud security frameworks since the enterprise-grade technology is affordable and easy to use. However, there are still significant risks that users must consider when utilizing these services.
security advisoryprivilege escalationdaemonPrivilege Escalation in Linux Build Services: What Nix and Lix Exposed
Say a developer queues a build on a shared Linux host. . The Nix daemon does the sensitive work as root. A mistake between those two sides can turn an ordinary build request into control of the host. That is why the Nix and Lix security release from October 13, 2026 matters. One bug let an unprivileged repair request alter a store path too early. The other hit memory outside an allocated buffer during untrusted evaluation. First job: patch the daemon that is running. Next, ask who sends it work and which secrets the worker can read. That answer sets the possible blast radius. Where is the privilege boundary? It sits between the client request and the daemon action. Picture a university build server. A student can request a package build but cannot edit /nix/store. The daemon can. If the daemon changes that store on the student's behalf before it has checked the request, the root boundary has failed. Root gets attention. Build credentials deserve it too. A builder may reach a cache, signing key, registry login, or release job. Control of any one of those may taint software sent to other machines. How did the repair bug work? The check came after the destructive step. A client without store access could still request a repair. The daemon removed the good object and restored the supplied data. Only afterward did it check the hash. A bad hash lost the check, but by then the trusted file was gone. Here was the order: remove the known object accept the proposed replacement calculate its hash reject it if the hash is wrong The diagram compares the unsafe repair order with a safer verify-and-authorize sequence. The safe order is to prove what the replacement is before it can touch trusted state . Maintained Lix releases now refuse repair requests from unprivileged clients. Nix shipped corrected releases too. What went wrong with list allocation? The evaluator mishandled a hostile list size. An extremely large list length could overflow theallocation calculation. The program reserved too little memory and then wrote pointers past that buffer. Lix says it did not find the extra steps needed to turn this write, by itself, into a working takeover. That distinction matters. A heap out-of-bounds write is serious; it isn't proof that a researcher achieved root code execution. The practical question is where evaluation happens. A personal workstation that evaluates its owner's code is one case. A public build farm processing pull requests from strangers is another. Why do CI workers need special attention? They mix outside input with valuable credentials. One worker might publish a package, push a container, sign a build, and start a release. Take that worker, and there may be no need to visit each production host. The poisoned output can carry the damage downstream. The NixOS advisory calls out systems that build untrusted derivations. Check shared dev hosts and community farms. Check pull-request runners too, along with multi-user machines that expose the daemon. When possible, do not let the build job deploy. A production server can install an artifact built elsewhere without retaining permission to evaluate arbitrary projects. That smaller role gives an attacker less to inherit. Which releases fix the Nix and Lix flaws? Fixed Nix releases are 2.35.3, 2.34.9, 2.31.6, 2.30.6, and 2.28.8. The advisory treats older releases as affected. No fixes are planned for the unsupported 2.29, 2.32, or 2.33 branches. On Lix, move to 2.94.3, 2.95.4, 2.96.0, or newer. Lix 2.93 and older are affected and out of support. Do not rely on a version shown in a channel announcement. A flake, overlay, user profile, or old worker image may pin something else. Check the executable used by the live daemon and trace where that package came from. Lix also has specific upgrade instructions for some 2.95 overlay installations. For some of them, nix upgrade-nix is the wrong route. Use the instructions that match how this host got Lix. What should you check today? Start at the live process. The package you remember installing may not be the one in service. 1. Record the daemon version and package source. 2. Upgrade to a fixed Nix or Lix release . 3. Restart it, then inspect the live binary once more. 4. Write down each user, repository, and CI job that can submit work. 5. Move signing and deployment secrets off general-purpose builders. 6. Look through daemon, crash, and integrity logs for odd repair requests. Now ask the uncomfortable question: if this builder falls, what falls next? Isolation, brief credentials, and a separate release approval can keep the list short. This incident is a privilege escalation lesson, not just a Nix patch notice. Any root daemon taking requests from less-trusted users marks a boundary. Its checks must finish before the first privileged change. . Uncover the privilege escalation risks in Nix and Lix builds and check your deployment practices to prevent exploits.. Build Automation Risks, CI/CD Security, Nix Build Services, Lix Security Issues__EOC__. Andrew Kowal
cyber threatssecurity measuressoftware developmentIntegrating Email Security in SDLC to Combat Cyber Threats
Imagine releasing a software solution into the market only to realize the user cannot use the app properly. They have been reporting numerous bugs, which has lowered your reputation and reliability.
security advisorydebianmemory accessLinux TCP Fast Open Use After Free Leaves a Packet Pointer Behind
A bug in Linux’s TCP Fast Open code can leave it reading memory that has already been released. . TCP stands for Transmission Control Protocol, used to establish reliable network connections. In CVE-2026-98374, the kernel replaces a packet but keeps a reference to the old one. The useful lesson is about replacement. The kernel corrected one reference to the old packet, but missed another. Code that remembers an object for later use must stay in step when that object is replaced. The documented fix updates the missed reference to point to the replacement packet. It does not simply clear both references. How the Old Packet Remains Reachable The Fast Open design lets applications exchange data while a connection is being established. Debian’s CVE-2026-98374 record traces this bug to tcp_send_synack() , which handles part of that setup. It copies a cloned connection-opening packet, known as a SYN packet, and releases the original memory. The packet sits in a buffer, a piece of memory reserved for its information. A pointer stores that buffer’s address. Here there are two pointers to consider. The replacement code repairs highest_sack but leaves retransmit_skb_hint with the old address. TCP may need to send a packet again. When it examines packets for this retransmission, it uses the second pointer as a shortcut into the queue. By then, the buffer at the saved address has been freed. How the Test Reached the Old Buffer An unprivileged client starts the reported sequence with sendmsg() and its MSG_FASTOPEN option. The attacker supplies an Internet Control Message Protocol (ICMP) fragmentation-needed message , normally a warning that a packet is too large to pass along a network path without being split. That message gets the reference set. Next comes a simultaneous open , where both ends initiate a connection. This is the step that frees the packet. The reference survives, which explains why later code can reach released memory. The Kernel Address Sanitizer,or KASAN, is a debugging tool that detects invalid memory access. Its report shows a four-byte read from freed memory in tcp_mark_skb_lost() . This confirms the invalid read in the reported test; it does not demonstrate a working attack against an arbitrary internet-facing server. What the Fix Changes The correction makes retransmit_skb_hint refer to the copied packet. The new buffer remains the object that the retransmission code is meant to use, so the saved shortcut has to follow it. Debian’s tracker lists its unstable linux package 7.2.9-1 as fixed. At this review, it still labels the listed bookworm and trixie packages as vulnerable. Those are Debian package findings, not a claim that every distribution has shipped the same versions. Check your own distribution’s CVE status before choosing an update. A package number from another release or vendor is not enough to establish that your running kernel contains this change. What Linux Administrators Should Verify Identify Fast Open use: Check which applications and systems use the affected networking feature. CVE status: Find the entry for CVE-2026-98374 in your distribution’s security tracker. Package choice: Match the vendor’s corrected package to the distribution release you run. Verify the running kernel: After the required restart, check that the machine is using the intended package. Keep relevant diagnostics: Preserve existing crash reports from affected test systems for investigation. These are deployment checks, not a replacement for the patch. The report does not establish that a particular firewall rule or a broad configuration change reliably removes the bug. The Lesson for Packet Replacement The available record documents a use-after-free read. It does not demonstrate privilege escalation, arbitrary code execution, or exploitation in production. Those outcomes should not be added to the story simply because the error involves kernel memory. For administrators, TCP Fast Open exposureand the distribution’s patch status are the practical questions. For developers, the case is a reminder to review every saved reference when replacing a packet, including pointers used only to speed up a later lookup. Get more original Linux security research by subscribing to the LinuxSecurity newsletter . Related Reading BPF Congestion Control Exposed Two Linux TCP Use-After-Free Paths New Linux Private Futex Race Can Trigger Kernel Use-After-Free AppArmor Credential Fix Prevents In-Hook Use-After-Free Risk . A bug in Linux’s TCP Fast Open code can lead to memory issues, affecting network connections, as addressed in CVE-2026-98374.. TCP Fast Open, Memory Access, Linux Kernel__EOC__. Andrew Kowal
security advisorykernelSELinuxSELinux NFS Security Update Fixes File Labeling Problems Effectively
On an affected host, a second mount of the same NFSv4 share could alter SELinux label handling on the first. . The new kernel change keeps the capability flag in place. The issue matters on systems that use labels supplied by an NFS server to make SELinux access decisions. SELinux labels are extra file identities used by security policy. They sit alongside familiar owner, group, and permission bits. This bug did not delete files or rewrite those Unix permissions. Its path was narrower: NFSv4 native labels, SELinux, and kernel state shared by two mounts. What Happened on the Second Mount? Two directory paths can point to the same remote NFS export and still share lower-level state inside the kernel. In the reported sequence, the first mount began with native labels available. A later mount reused an initialized filesystem superblock and received an incomplete answer from SELinux. The important pieces were: Filesystem: NFSv4 with server-supplied security labels Security module: SELinux Reused object: an initialized superblock Shared NFS flag: NFS_CAP_SECURITY_LABEL NFS treated the missing SELinux signal as “no native labels” and cleared the shared NFS flag. The earlier mount used that state too, so its label behavior could change even though it had not been remounted. Which Flag Was Missing? The kernel function involved is security_sb_set_mnt_opts() . It handles security options when a filesystem is mounted. If its superblock had already been initialized, the function returned early. Here is the difference that mattered: Return status: success Missing output: SECURITY_LSM_NATIVE_LABELS Meaning of that output: labels come from individual files on the remote filesystem NFS reaction when absent: clear NFS_CAP_SECURITY_LABEL Success alone was not enough. “This superblock is ready” and “this filesystem uses native labels” answer different questions. The old early return answered the first and silentlyomitted the second. Why Could Two Paths Share the Problem? Users see mount points as separate paths. The kernel can place connection and capability information in a shared NFS server record underneath them. A change made through either mount could reach the same record. Possible clues for an administrator: Security contexts shown by ls -Z change after mount activity. New SELinux denials begin after a mount or remount. Neither clue proves this bug. Fixed-label mount options, server settings, policy edits, and ordinary labeling mistakes belong in the investigation too. The kernel record supports these conclusions: A shared native-label capability could be cleared. A second mount could trigger the change. The fix preserves the missing SELinux signal. Not shown in the public record: A working exploit A privilege-escalation demonstration An incident attributed to the flaw What Should Linux Administrators Inspect? Focus first on hosts that mount one NFSv4 export more than once and depend on labels supplied by the server. Run findmnt and group mounts by server and export. Compare ls -Z output before and after another mount is added. Review audit logs for denials that begin after a mount or remount. Record mount options, especially options that assign one fixed SELinux context. Check vendor kernel updates for the fix or a backport. After updating, retest applications that read or write labeled files. Keep the evidence tied to a time and a mount operation. That makes it easier to separate this kernel path from a policy edit or server-side labeling change. What Does the Patch Prove? The detailed SELinux fix changes the early-return case so it still reports native-label support on an initialized superblock. The related Linux security merge records the correction. Once the signal is present, NFS keeps the label capability. The public record leaves several questions open: CVE: none assigned in thecommits Full affected-release list: not provided Active exploitation: not established Distribution kernels do not all take fixes on the same schedule. Check the advisory and package status published by the Linux vendor in use. This SELinux fix shows why two mount paths are not always two independent security boundaries. For NFS security, check both the label visible on the file and the shared kernel capability that allows the client to obtain it. Get more original Linux security research by subscribing to the LinuxSecurity newsletter . Related Reading Configuring SELinux: An In-Depth Guide to Securing Your Linux System Seccomp, AppArmor, SELinux: Where Linux Security Controls Fall Short Understanding SELinux for Linux Admins and Its Impact on Security SELinux Troubleshooting: What to Check Before You Disable SELinux . SELinux fix addresses issues where NFS mounts may lose file labels, affecting access decisions and security measures. SELinux Fixes, NFS Security, Linux Labels, Kernel Updates, File Permissions__EOC__. MaK Ulac
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
|
| ||
Community Poll
Search Topics
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.