CVE-2021-46971
published 2024-02-27CVE-2021-46971: In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix unconditional security_locked_down() call Currently, the lockdown state is…
PriorityP410low3.3CVSS 3.1
AVLACLPRLUINSUCNILAN
EPSS
0.23%
14.0th percentile
In the Linux kernel, the following vulnerability has been resolved:
perf/core: Fix unconditional security_locked_down() call
Currently, the lockdown state is queried unconditionally, even though
its result is used only if the PERF_SAMPLE_REGS_INTR bit is set in
attr.sample_type. While that doesn't matter in case of the Lockdown LSM,
it causes trouble with the SELinux's lockdown hook implementation.
SELinux implements the locked_down hook with a check whether the current
task's type has the corresponding "lockdown" class permission
("integrity" or "confidentiality") allowed in the policy. This means
that calling the hook when the access control decision would be ignored
generates a bogus permission check and audit record.
Fix this by checking sample_type first and only calling the hook when
its result would be honored.
Affected
15 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 5.10.38-1 (bookworm) | linux 5.10.38-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= b0c8fdc7fdb77586c3d1937050925b960743306e < b246759284d6a2bc5b6f1009caeeb3abce2ec9ff | b246759284d6a2bc5b6f1009caeeb3abce2ec9ff |
| linux | linux | >= b0c8fdc7fdb77586c3d1937050925b960743306e < 4348d3b5027bc3ff6336368b6c60605d4ef8e1ce | 4348d3b5027bc3ff6336368b6c60605d4ef8e1ce |
| linux | linux | >= b0c8fdc7fdb77586c3d1937050925b960743306e < f5809ca4c311b71bfaba6d13f4e39eab0557895e | f5809ca4c311b71bfaba6d13f4e39eab0557895e |
| linux | linux | >= b0c8fdc7fdb77586c3d1937050925b960743306e < c7b0208ee370b89d20486fae71cd9abb759819c1 | c7b0208ee370b89d20486fae71cd9abb759819c1 |
| linux | linux | >= b0c8fdc7fdb77586c3d1937050925b960743306e < 08ef1af4de5fe7de9c6d69f1e22e51b66e385d9b | 08ef1af4de5fe7de9c6d69f1e22e51b66e385d9b |
| linux | linux_kernel | >= 0 < 5.10.38-1 | 5.10.38-1 |
| linux | linux_kernel | >= 0 < 5.10.38-1 | 5.10.38-1 |
| linux | linux_kernel | >= 0 < 5.10.38-1 | 5.10.38-1 |
| linux | linux_kernel | >= 0 < 5.10.38-1 | 5.10.38-1 |
| linux | linux_kernel | >= 5.11 < 5.11.19 | 5.11.19 |
| linux | linux_kernel | >= 5.12 < 5.12.2 | 5.12.2 |
| linux | linux_kernel | >= 5.4 < 5.4.117 | 5.4.117 |
| linux | linux_kernel | >= 5.5 < 5.10.35 | 5.10.35 |
CVSS provenance
nvdv3.13.3LOWCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
osv3.3LOW
vendor_debian3.3LOW
vendor_redhat3.3LOW
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: perf/core: Fix unconditional security_locked_down() call
vendor_redhat·2024-02-27·CVSS 3.3
CVE-2021-46971 [LOW] CWE-413 kernel: perf/core: Fix unconditional security_locked_down() call
kernel: perf/core: Fix unconditional security_locked_down() call
In the Linux kernel, the following vulnerability has been resolved:
perf/core: Fix unconditional security_locked_down() call
Currently, the lockdown state is queried unconditionally, even though
its result is used only if the PERF_SAMPLE_REGS_INTR bit is set in
attr.sample_type. While that doesn't matter in case of the Lockdown LSM,
it causes trouble with the SELinux's lockdown hook implementation.
SELinux implements the locked_down hook with a check whether the current
task's type has the corresponding "lockdown" class permission
("integrity" or "confidentiality") allowed in the policy. This means
that calling the hook when the access control decision would be ignored
generates a bogus permission check and audit record.
Fix
Debian
CVE-2021-46971: linux - In the Linux kernel, the following vulnerability has been resolved: perf/core: ...
vendor_debian·2021·CVSS 3.3
CVE-2021-46971 [LOW] CVE-2021-46971: linux - In the Linux kernel, the following vulnerability has been resolved: perf/core: ...
In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix unconditional security_locked_down() call Currently, the lockdown state is queried unconditionally, even though its result is used only if the PERF_SAMPLE_REGS_INTR bit is set in attr.sample_type. While that doesn't matter in case of the Lockdown LSM, it causes trouble with the SELinux's lockdown hook implementation. SELinux implements the locked_down hook with a check whether the current task's type has the corresponding "lockdown" class permission ("integrity" or "confidentiality") allowed in the policy. This means that calling the hook when the access control decision would be ignored generates a bogus permission check and audit record. Fix this by checking sample_type first and only calling the hook when
OSV
CVE-2021-46971: In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix unconditional security_locked_down() call Currently, the lockdown s
osv·2024-02-27·CVSS 3.3
CVE-2021-46971 [LOW] CVE-2021-46971: In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix unconditional security_locked_down() call Currently, the lockdown s
In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix unconditional security_locked_down() call Currently, the lockdown state is queried unconditionally, even though its result is used only if the PERF_SAMPLE_REGS_INTR bit is set in attr.sample_type. While that doesn't matter in case of the Lockdown LSM, it causes trouble with the SELinux's lockdown hook implementation. SELinux implements the locked_down hook with a check whether the current task's type has the corresponding "lockdown" class permission ("integrity" or "confidentiality") allowed in the policy. This means that calling the hook when the access control decision would be ignored generates a bogus permission check and audit record. Fix this by checking sample_type first and only calling the hook when
GHSA
GHSA-hmgx-rfwx-3mvq: In the Linux kernel, the following vulnerability has been resolved:
perf/core: Fix unconditional security_locked_down() call
Currently, the lockdown
ghsa_unreviewed·2024-02-27
CVE-2021-46971 [LOW] GHSA-hmgx-rfwx-3mvq: In the Linux kernel, the following vulnerability has been resolved:
perf/core: Fix unconditional security_locked_down() call
Currently, the lockdown
In the Linux kernel, the following vulnerability has been resolved:
perf/core: Fix unconditional security_locked_down() call
Currently, the lockdown state is queried unconditionally, even though
its result is used only if the PERF_SAMPLE_REGS_INTR bit is set in
attr.sample_type. While that doesn't matter in case of the Lockdown LSM,
it causes trouble with the SELinux's lockdown hook implementation.
SELinux implements the locked_down hook with a check whether the current
task's type has the corresponding "lockdown" class permission
("integrity" or "confidentiality") allowed in the policy. This means
that calling the hook when the access control decision would be ignored
generates a bogus permission check and audit record.
Fix this by checking sample_type first and only calling the hook
No detection rules found.
No public exploits indexed.
https://git.kernel.org/stable/c/08ef1af4de5fe7de9c6d69f1e22e51b66e385d9bhttps://git.kernel.org/stable/c/4348d3b5027bc3ff6336368b6c60605d4ef8e1cehttps://git.kernel.org/stable/c/b246759284d6a2bc5b6f1009caeeb3abce2ec9ffhttps://git.kernel.org/stable/c/c7b0208ee370b89d20486fae71cd9abb759819c1https://git.kernel.org/stable/c/f5809ca4c311b71bfaba6d13f4e39eab0557895ehttps://git.kernel.org/stable/c/08ef1af4de5fe7de9c6d69f1e22e51b66e385d9bhttps://git.kernel.org/stable/c/4348d3b5027bc3ff6336368b6c60605d4ef8e1cehttps://git.kernel.org/stable/c/b246759284d6a2bc5b6f1009caeeb3abce2ec9ffhttps://git.kernel.org/stable/c/c7b0208ee370b89d20486fae71cd9abb759819c1https://git.kernel.org/stable/c/f5809ca4c311b71bfaba6d13f4e39eab0557895e
2024-02-27
Published