The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - In the Linux kernel, the following vulnerability has been resolved: bpf, lockdown, audit: Fix buggy     SELinux lockdown permission checks Commit 59438b46471a (security,lockdown,selinux: implement SELinux     lockdown) added an implementation of the locked_down LSM hook to SELinux, with the aim to restrict which     domains are allowed to perform operations that would breach lockdown. This is indirectly also getting     audit subsystem involved to report events. The latter is problematic, as reported by Ondrej and Serhei,     since it can bring down the whole system via audit: 1) The audit events that are triggered due to calls to     security_locked_down() can OOM kill a machine, see below details [0]. 2) It also seems to be causing a     deadlock via avc_has_perm()/slow_avc_audit() when trying to wake up kauditd, for example, when using     trace_sched_switch() tracepoint, see details in [1]. Triggering this was not via some hypothetical corner     case, but with existing tools like runqlat & runqslower from bcc, for example, which make use of this     tracepoint. Rough call sequence goes like: rq_lock(rq) -> -------------------------+ trace_sched_switch()
    -> | bpf_prog_xyz() -> +-> deadlock selinux_lockdown() -> | audit_log_end() -> | wake_up_interruptible()
    -> | try_to_wake_up() -> | rq_lock(rq) --------------+ What's worse is that the intention of 59438b46471a     to further restrict lockdown settings for specific applications in respect to the global lockdown policy     is completely broken for BPF. The SELinux policy rule for the current lockdown check looks something like     this: allow <who> <who> : lockdown { <reason> }; However, this doesn't match with the 'current' task where     the security_locked_down() is executed, example: httpd does a syscall. There is a tracing program attached     to the syscall which triggers a BPF program to run, which ends up doing a bpf_probe_read_kernel{,_str}()     helper call. The selinux_lockdown() hook does the permission check against 'current', that is, httpd in     this example. httpd has literally zero relation to this tracing program, and it would be nonsensical     having to write an SELinux policy rule against httpd to let the tracing helper pass. The policy in this     case needs to be against the entity that is installing the BPF program. For example, if bpftrace would     generate a histogram of syscall counts by user space application: bpftrace -e     'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }' bpftrace would then go and generate a BPF     program from this internally. One way of doing it [for the sake of the example] could be to call     bpf_get_current_task() helper and then access current->comm via one of bpf_probe_read_kernel{,_str}()     helpers. So the program itself has nothing to do with httpd or any other random app doing a syscall here.
    The BPF program _explicitly initiated_ the lockdown check. The allow/deny policy belongs in the context of     bpftrace: meaning, you want to grant bpftrace access to use these helpers, but other tracers on the system     like my_random_tracer _not_. Therefore fix all three issues at the same time by taking a completely     different approach for the security_locked_down() hook, that is, move the check into the program     verification phase where we actually retrieve the BPF func proto. This also reliably gets the task     (current) that is trying to install the BPF tracing program, e.g. bpftrace/bcc/perf/systemtap/etc, and it     also fixes the OOM since we're moving this out of the BPF helper's fast-path which can be called several     millions of times per second. The check is then also in line with other security_locked_down() hooks in     the system where the enforcement is performed at open/load time, for example, open_kcore() for /proc/kcore     access or module_sig_check() for module signatures just to pick f ---truncated--- (CVE-2021-47128)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Published	Updated	Severity
247937	Linux Distros Unpatched Vulnerability : CVE-2021-47128	Nessus	Misc.	8/11/2025	8/11/2025	medium
160459	Amazon Linux 2 : kernel (ALASKERNEL-5.10-2022-002)	Nessus	Amazon Linux Local Security Checks	5/2/2022	9/25/2025	high

Detections

Analytics

Plugins Search

medium

high