CVE-2025-68733

What it actually does

An unprivileged process permitted to relabel itself via a non-empty /smack/relabel-self list can supply an arbitrary new label name when writing to /proc/PID/attr/smack/current; do_setattr() imports the label before the relabel-self restriction is enforced, bypassing the intended authorization check.

Why it matters to the business

Attackers who already have limited access on Linux systems using Smack can escalate their ability to define new security labels, increasing the chance of unauthorized data access or policy evasion on servers, containers, and embedded devices; the issue has been public for over 300 days with stable low exploitation probability and no observed ransomware use.

How an attack unfolds

An attacker obtains a process that is already allowed to change its own Smack label, writes a previously unknown label name into its /proc/self/attr/smack/current file, and the kernel accepts and applies the new label without consulting the permitted relabel-self list, thereby granting the process rights associated with the freshly created label.

How to fix it

Upgrade the Linux kernel to a version containing commit c80173233014a360c13fa5cc79d36bfe6e53a8ed; for wolfictl (Chainguard) and wolfictl (Wolfi) update to package version 0.31.1-r1 or later; rebuild and redeploy any custom kernels or container images that embed the vulnerable Smack implementation.

How to confirm the fix worked

Confirm the running kernel contains commit c80173233014a360c13fa5cc79d36bfe6e53a8ed by checking /proc/version or the package manifest; attempt to create a new label from an unprivileged process whose relabel-self list does not contain that label and verify the write is rejected.

Typical attack path

1. Identify a Linux system running a vulnerable kernel with Smack enabled and a non-empty relabel-self list for the attacker's UID.
2. Obtain code execution or shell access as an unprivileged user permitted to relabel itself.
3. Write an arbitrary new label string to /proc/self/attr/smack/current.
4. Use the newly created label to access resources or perform operations that the original label could not.

How to detect it

Review kernel audit logs or SELinux/Smack-related audit events for unexpected label creations; examine process attribute writes to /proc/*/attr/smack/current by unprivileged users; no public exploit artifacts are known.

What your security team should do

• Prioritize kernel upgrades on all Smack-enabled systems within standard change windows.
• Audit Smack configurations to ensure relabel-self lists are minimal and only granted to necessary processes.
• Monitor upstream stable kernel updates for any additional Smack-related fixes.
• Include the fixed commit hash in SBOM and image scanning policies.