A recent upstream Linux kernel patch fixed a silent but important auditing gap: the "at" variants of two extended-attribute read syscalls—getxattrat() and listxattrat()—were not listed in the kernel's audit
read class, allowing reads of extended attributes to bypass file-read audit rules on unpatched kernels. The change was small — literally a handful of lines in an asm-generic header — but the operational and compliance implications are disproportionate: administrators relying on audit rules to capture sensitive reads of file attributes (including security-related extended attributes) could have blind spots in their logs until they applied the patch or distribution kernels that include it.
Background / Overview
The Linux audit subsystem classifies syscalls into semantic groups (classes) such as
read,
write, and
change attributes so that rules like -w /path -p rwa will match an appropriate set of syscalls without listing every syscall explicitly. When new syscalls are added to the kernel interface, those syscall identifiers must also be mapped into the audit classes if they represent the same semantic operation. In 2024 the kernel added the
at family of xattr syscalls (setxattrat, getxattrat, listxattrat, removexattrat) to support operations relative to a directory file descriptor and to enable operations without needing a readable file descriptor; that change introduced the new syscalls but, in at least one case, neglected to add the "at" read variants to the audit read class.
The omission meant that calls such as getxattrat() and listxattrat() would not be counted as "read" operations by the audit subsystem. A simple audit rule intended to watch reads to a path (for example, -w /tmp/test -p rwa -k test_rwa) could therefore be bypassed, producing no audit type=SYSCALL records when those particular syscalls were used to read extended attributes. The maintainer patch submitted and merged addressed the omission by adding conditional entries for __NR_getxattrat and __NR_listxattrat into include/asm-generic/audit_read.h so the audit read class recognizes them where they exist.
What changed (technical details)
The minimal patch and where it landed
The upstream fix is tiny: conditional macro entries were added to the asm-generic audit header so that if the architecture exposes __NR_getxattrat or __NR_listxattrat, the kernel will include those syscall numbers inside the AUDIT_PERM_READ (read class) list. Concretely the patch inserts:
- An #ifdef __NR_listxattrat / __NR_listxattrat pair to register listxattrat in the read class.
- An #ifdef __NR_getxattrat / __NR_getxattrat pair to register getxattrat in the read class.
Because these syscall names are guarded with #ifdef, the change is forward- and backward-compatible across architectures that do or do not implement the *at variants. The change was merged upstream and propagated into stable/autosel updates across kernel trees.
Why the omission mattered
Extended attributes (xattrs) are used for a range of security-sensitive metadata: SELinux file contexts ("security.selinux"), POSIX capabilities, and vendor-specific security tags are stored in xattrs. The
at functions in particular were introduced to allow manipulation of xattrs relative to directory file descriptors and to do so without requiring an open file descriptor with read permissions — an important capability for avoiding race conditions and for operations done by tools like setfiles. When the xattr at syscalls were added, two of them (setxattrat/removexattrat) were correctly added to the
change attributes class, but the read-oriented pair (getxattrat/listxattrat) were not added to the read class; consequently, read-focused audit rules missed them. The missing entries therefore introduce a blind spot that can affect both security monitoring and post-incident forensics.
Scope and affected systems
- Kernel origins: The *at family of xattr syscalls was introduced in the kernel around the v6.13 timeframe; systems running kernels that include these syscalls but that predate the audit-class fix are affected. The upstream commit that added the syscalls is documented in the v6.13-related tree.
- Where the fix landed: The audit read-class patch was proposed and accepted upstream, merged into the audit/dev tree and pulled into stable autosel branches; distribution kernel maintainers have started shipping the fixes in their kernel updates. Administrators should check whether their vendor kernels include the patch (see mitigation below).
- Distribution coverage: Because the change is an upstream kernel commit, the remediation path is through vendor-supplied kernel updates — not a user-space patch. Most major distributions either applied the change into their stable kernel builds or published advisories calling out kernel updates that include the commit; check your distribution's kernel/changelog and security advisory feed for the specific package version that contains the merge. (If you must stay on an older kernel for compatibility reasons, see the workaround/detection section.)
Practical impact: detection, compliance and risk
Detection blind spots and compliance
Audit rules of the form -w /path -p rwa are commonly used to record reads, writes and attribute changes to files of interest. Because the audit subsystem uses pre-baked syscall-class lists to expand those shorthand rules, a missing syscall mapping causes those shorthand watch rules to silently exclude the missing syscalls. In practice that means:
- Reads of xattrs via getxattrat() or listxattrat() would not trigger a matching audit record of the usual type (for example, type=SYSCALL with related fields), so administrators relying on those rules may see no record of the operation.
- For environments with regulatory or internal compliance requirements that mandate comprehensive logging (for example, capturing reads of certain security attributes), the gap could count as an audit/control failure until patched.
- For incident response and threat hunting, absence of expected audit evidence complicates reconstruction of events, especially for local privilege escalation or misuse that manipulates security metadata via xattr operations.
This is not a kernel memory corruption or remote arbitrary code execution flaw — rather, it is a logging/visibility gap that undermines security telemetry and forensic completeness on affected kernels. That classification alters mitigation priorities: it's urgent for monitoring and compliance teams, but the immediate exploitability profile is different from a remote RCE.
Attack scenarios where the gap matters
- Local attacker or compromised process reads sensitive xattrs (e.g., security.selinux) via the *at syscalls. If forensic reliance is on audit logs that used semantic watch rules, the read will be invisible in logs.
- Automation or scripts that query xattrs for configuration or secret-storing purposes could perform reads that are not captured by auditing, meaning suspicious or improper reads could go unnoticed.
- Sophisticated attackers could deliberately use the *at variants as part of a tactics-to-avoid-logging approach, though this requires local code execution already and is therefore an escalation/path-hardening vector rather than a remote vulnerability.
Detection and verification (how to test if you're affected)
Admins can check if their kernel implements the *at xattr syscalls and whether audit is currently logging them:
- Confirm whether the kernel exposes the syscalls:
- Check kernel headers or syscall table for getxattrat/listxattrat presence; or use strace on a test program that calls getxattrat() and observe whether the syscall name translates.
- Create a simple audit watch and perform a getxattrat() call:
- Example (run as root, adjust paths and arch as needed):
- Add a watch: auditctl -w /tmp/test -p rwa -k test_rwa
- From an unprivileged user, execute a small program or use a utility that invokes getxattrat()/listxattrat() against /tmp/test (or script a syscall via C).
- Inspect /var/log/audit/audit.log or ausearch -k test_rwa to see whether the read operation generated a type=SYSCALL event.
- If the read does not produce an audit event when performed via the *at call, your kernel is missing the mapping and is affected.
If you do not have a program to call the *at syscalls, community testcases and proof-of-concept code have been circulated alongside the patch discussion. Use caution and run tests in a lab environment. The upstream discussion includes concrete syscall examples and rationale that explain behavior and reproduction steps.
Mitigation and recommended actions
Apply vendor kernel updates that include the upstream patch
- The correct long-term fix is to install a kernel that contains the merged upstream commit adding getxattrat and listxattrat to the audit read class. Because this is an upstream kernel change, distribution vendors will release packaged kernel updates that include the fix. Check your vendor's security advisory and kernel changelog for the specific update that includes the commit (look for audit: add missing syscalls to read class or the merge tag audit-pr-20260203).
If you cannot immediately update kernels, consider temporary detection/workarounds
- Add syscall-specific audit rules to catch the missing syscalls explicitly. Audit supports syscall rules directly:
- Example (run on 64-bit systems; tailor arch and path filters as required):
- auditctl -a exit,always -F arch=b64 -S getxattrat -S listxattrat -k xattr_read
- Or use augenrules (rules in /etc/audit/rules.d/) to persist across reboots.
- Caveat: syscall rules differ from -w path-style rules — matching syscalls alone will capture any such call regardless of path unless you also filter by process, uid, or path where supported. Compose filters carefully to avoid noisy logs.
- Instrument critical processes or use file-integrity tools that track xattr access at the filesystem level if appropriate.
- For high-assurance environments, consider temporarily enabling broader syscall-level auditing (with careful filtering and quota planning) until kernels are patched.
Harden monitoring and alerting
- Update detection rules in SIEM and EDR to include the possibility of omitted audit events; escalate unexpected absence of audit entries for known sensitive operations.
- Cross-check other telemetry (process accounting, kernel tracing, eBPF-based observability) to fill gaps while kernel updates roll out.
Longer-term improvements
- Encourage distribution and vendor vendors to include the audit mapping in backported kernels and release clear advisories that identify the change and the affected kernel versions.
- Given the class-of-omission nature of this bug, encourage unit/regression tests in kernel trees that verify new syscalls are mapped into audit classes where appropriate; this reduces the risk of future drift between syscall additions and audit classification. The upstream discussion includes commentary on how this omission likely arose during the introduction of the *at syscalls.
Why this kind of bug happens (root cause & process observations)
This issue demonstrates a common maintenance failure mode in large, long-lived codebases: a new syscall gets added to the kernel core to satisfy functionality needs (in this case, safer/xpath-independent xattr access), but dependent subsystems — here, the audit class macros — require a separate, explicit update to stay semantically consistent. The kernel's audit subsystem historically maintains explicit lists (per architecture) of syscall numbers grouped by semantic classes. When syscall families are extended (the *at family), it becomes a manual chore to update every dependent classification.
Several systemic mitigations would help reduce recurrence:
- Add automated checks in patch pipelines to detect when a syscall is added without corresponding audit-class coverage changes.
- Use centralized metadata or macros that can be expanded automatically rather than scatter conditional lists across asm-generic headers.
- Include audit-focused smoke tests in kernel CI that verify -w style rules produce events for the full, relevant syscall surface.
The kernel community discussion around the patch shows that authors and auditors spotted the omission after-the-fact and submitted a small, well-scoped fix; the fix itself is non-invasive and safe, but the underlying process gap is the broader concern.
What administrators should do now — an action checklist
- Inventory kernels in use:
- Identify hosts running kernels that include the *at xattr syscalls (roughly kernels v6.13 and newer) and determine whether the audit read-class patch is present in the kernel version packaged by your vendor.
- Patch promptly:
- Apply distribution kernel updates that incorporate the audit mapping fix. Priority is higher for hosts in regulatory or high-compliance contexts and for systems that rely on audit for forensic capture.
- Add temporary syscall-level audit rules if immediate kernel updates are delayed:
- Use auditctl/augenrules to explicitly capture getxattrat/listxattrat until kernels are patched.
- Test and validate:
- Reproduce the earlier behavior in a controlled environment to validate that after updating, read operations via the *at syscalls generate the expected audit events.
- Update detection logic and incident response playbooks:
- Document the gap and the mitigation steps so that SOC teams know what to look for in the near term. If a past incident relied on audit evidence that might have been missed, re-evaluate forensic conclusions if the timeline or operations include xattr reads.
- Encourage vendor transparency:
- Where vendors have not clearly identified the kernel change in release notes, contact vendor support channels to request confirmation of the fix and version numbers.
Broader lesson: telemetry is brittle at interfaces
This incident is a textbook example of the brittleness of telemetry that relies on explicit, manual mappings. Adding a syscall — even for good reasons such as race-free SELinux context operations — creates a coupling requirement that must be propagated across subsystems (audit, seccomp, tools, and perhaps BPF programs). Whenever interface expansions occur (new syscalls, new ioctls, extended ABI), maintainers and downstream packagers should treat audit and monitoring as first-class consumers and ensure mappings and tests travel with the feature. Upstream kernel processes are increasingly robust, but human attention is still required in these cross-cutting places.
Final analysis and risk summary
- Severity classification: This is primarily a visibility/auditing gap rather than a memory-corruption or remote-code-execution vulnerability. The immediate risk is to detection and compliance rather than to remote compromise without existing code execution. That said, visibility gaps are non-trivial: they materially reduce defenders' ability to detect and investigate local or post-compromise behavior.
- Exploitability: Low as a standalone attack vector (requires local process execution or prior compromise). However, it increases the value of certain privilege-escalation or persistence techniques because those techniques could be performed with reduced audit visibility.
- Remediation straightforwardness: High — the upstream patch is tiny and already merged; vendors are rolling it into stable kernels. Administrators should prioritize installing vendor kernel updates and, where necessary, apply syscall-level audit rules as a temporary mitigation.
- Long-term risk reduction: Process improvements (automated checks, CI tests, clearer cross-subsystem changelogs) will reduce recurrence and the potential for similar omissions when new syscalls or API surfaces are introduced.
The audit "add missing syscalls to read class" patch is a small but instructive reminder: in security,
what you don't see in logs can be as consequential as what you do. If your compliance, detection, or forensics depend on audit shorthand rules, confirm that your kernel and distro kernel packages include the upstream mapping for getxattrat() and listxattrat(), or apply the temporary syscall-level auditing recommended above until your kernels are updated.
Source: MSRC
Security Update Guide - Microsoft Security Response Center