CVE-2025-71306: ima: Fix stack-out-of-bounds in is_bprm_creds_for_exec()
In the Linux kernel, the following vulnerability has been resolved:
ima: Fix stack-out-of-bounds in isbprmcredsforexec()
KASAN reported a stack-out-of-bounds access in imaappraisemeasurement from isbprmcredsforexec:
BUG: KASAN: stack-out-of-bounds in imaappraisemeasurement+0x12dc/0x16a0 Read of size 1 at addr ffffc9000160f940 by task sudo/550 The buggy address belongs to stack of task sudo/550 and is located at offset 24 in frame: imaappraisemeasurement+0x0/0x16a0 This frame has 2 objects: [48, 56) 'file' [80, 148) 'hash'
This is caused by using containerof on the file pointer. This offset calculation is what triggers the stack-out-of-bounds error.
In order to fix this, pass in a bprmischeck boolean which can be set depending on how processmeasurement is called. If the caller has a linuxbinprm pointer and the function is BPRMCHECK we can determine ischeck and set it then. Otherwise set it to false.
Affected Software
Event History
Frequently Asked Questions
Who is exposed to this issue?
Systems running the Linux kernel with IMA appraisal or measurement paths that reach ima_appraise_measurement during an executable credential check are exposed. The reported failing task was sudo, indicating the issue can be reached during program execution handling.
What level of access does an attacker need?
The CVSS vector indicates local access and low privileges are required, with no user interaction. The available data does not describe a specific exploit sequence beyond reaching the affected kernel path.
What happens if the vulnerability is triggered?
It causes a KASAN-detected stack out-of-bounds read in ima_appraise_measurement. The supplied severity vector rates confidentiality and availability impact as high, while integrity impact is none.
What is the remediation?
Apply a kernel update containing the fix referenced by the stable kernel commits. The fix avoids using container_of on the file pointer and instead passes a bprm_is_check boolean to determine whether the call is a BPRM_CHECK.