eBPF Verifier Discrepancy Revealed: PREVAIL Accepts Safe Code Rejected by Linux Kernel Verifier
Security researchers examining the eBPF verifier encountered a case where two independent static analyzers reached opposite conclusions about the same object file. The program correlated_branch.c from the ebpf-samples repository was accepted by the external verifier PREVAIL yet rejected by the in-kernel Linux verifier during loading via bpftool.
The test was performed on Ubuntu 24.04.1 LTS with kernel Linux 6.14.0-37-generic and clang 18.1.3 targeting the bpf architecture. The XDP function ConvergedBranch first obtains packet boundaries from the context, calls check_packet to verify that at least 14 bytes are available, and only then dereferences the Ethernet header type field at offset 12.
The kernel verifier log shows that the scalar register holding the computed length receives the constraint R2_w=scalar(smin=umin=14,...) after the comparison. However, the pointer stored in r7 is not annotated with a matching packet offset range, causing the subsequent load r3 = *(u16 *)(r7 + 12) to be rejected as an invalid packet access.
In contrast, PREVAIL records the state r7.type=packet packet_size=14 r7.packet_offset=0 after the same check. When the load instruction is reached, the tool evaluates assert valid_access(r7.offset+12, width=2) and permits the read because the offset plus size fits inside the proven 14-byte region.
The root cause is architectural: the kernel verifier treats the length scalar and the packet pointer as separate abstract domains, while PREVAIL preserves relational information across states. When the bounds check was inlined directly in ConvergedBranch instead of being hidden inside check_packet, the kernel verifier successfully accepted the program.
The episode demonstrates that a verifier rejection does not automatically imply the presence of a memory-safety bug. Analysts must examine register states such as R7 pkt(off=0,r=0) to determine whether the required offset range was simply not propagated.
Related articles
Use-After-Free in HTTP/2 Upload Leads to Potential RCE in curl: Detailed Analysis of CVE-2026-92392
In curl 8.23.0, developers fixed a high-severity Use-After-Free vulnerability tracked as CVE-2026-92392 that could allow remote code execution during HTTP/2 uploads. The flaw stems from a dangling pointer left on an easy handle after a server resets an HTTP/2 stream, which later gets dereferenced when the multi handle closes. An attacker controlling the server can influence memory contents to hijack a function pointer and execute arbitrary code, though successful exploitation requires precise conditions including upload size, memory layout, and knowledge of the target architecture. The issue was discovered by Luna Tong at Anthropic using their OSS Scanner and reported to the curl security team on September 15. The team accelerated the release cycle by two weeks to deliver the fix while maintaining standard procedures. curl maintainers continue reducing internal handle pointers in favor of identifiers and are adding more tests and static analysis to prevent similar memory-safety errors. The vulnerability highlights ongoing risks in C-based networking code handling multiplexed protocols like HTTP/2.
Automating Asset Scanning in MaxPatrol VM via API: Part 4 on Authentication
A detailed technical guide explains how to build asset scanning automation in MaxPatrol VM using its API, starting with authentication methods. The author covers three authorization options including local account login-password, domain account credentials, and reference tokens, providing working Python examples for local accounts. Code reads secrets from an .env file and obtains a Bearer token valid for 24 hours from the Core role instance. The post details required privileges in both the Management Console and MaxPatrol 10 for tasks such as vulnerability exports, dynamic asset group management, scan task creation, and report exporting. It credits Alexey Leonov for an early GitHub script that enabled practical API usage and lists additional resources including webinars, SDK, CLI, Jira integration, and a Postman collection. All subsequent API calls rely on the generated headers containing the Bearer token.
Securing Hadoop Clusters: Removing Passwords from XML Configs with Credential Provider API and JCEKS
Hadoop configurations frequently expose sensitive credentials such as database passwords and cloud access keys in plain text within files like hive-site.xml and core-site.xml. The Credential Provider API, introduced in Hadoop 2.6, allows applications to retrieve secrets from an external JCEKS keystore instead of embedding them directly in XML. This mechanism uses conf.getPassword() to fetch decrypted values from the keystore when hadoop.security.credential.provider.path is configured. JCEKS relies on the outdated PBEWithMD5AndTripleDES algorithm, which remains vulnerable to Sweet32 attacks in theory though practical risk for small keystore files is low. Master password protection for the keystore itself is the weakest link, with options including environment variables, protected password files, or HDFS Transparent Data Encryption. Arenadata has automated credential encryption management in its ADH platform through ADCM to handle keystore creation, permission setting, and rotation across cluster nodes.
CISA Adds Five Exploited Vulnerabilities to KEV Catalog Including AhsayCBS Authentication and Command Injection Flaws
The US Cybersecurity and Infrastructure Security Agency (CISA) has added five vulnerabilities to its Known Exploited Vulnerabilities catalog after confirming active exploitation in the wild. Four vulnerabilities were registered on October 14, 2026, and one additional entry followed on October 15. Among the newly listed issues are two critical flaws affecting the AhsayCBS backup management server: CVE-2026-105133, an authentication bypass in the API, and CVE-2026-105134, a command injection vulnerability in the replication feature. When chained together, the pair allows unauthenticated remote attackers to execute arbitrary operating system commands. Vendor Ahsay has released hotfixes in versions 10.3.4.45 and 9.15.2.70 because standard patches cannot fully address the issues. The advisory also references vulnerabilities in Atlassian products and multiple network security solutions from other vendors.