There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel/pt: Fix stop/start with
    no update If pt_event_stop() is called without PERF_EF_UPDATE flag, then perf_aux_output_end() is not
    called. A subsequent call to pt_event_start() will call perf_aux_output_begin() again which violates the
    rule against nesting and triggers a WARNING in perf_aux_output_begin(). Originally, pt_event_stop() was
    never called without PERF_EF_UPDATE, because the only code paths to do so are from event overflow, and
    Intel PT does not do that. However the introduction of group throttling by commit 9734e25fbf5ae ("perf:
    Fix the throttle logic for a group") meant that an Intel PT event could be throttled if it was part of a
    group. Throttling calls PMU ->stop() / ->start() callbacks without flags. An example is when AUX area
    sampling is used. The following commands hit the issue: echo 10000 >
    /proc/sys/kernel/perf_event_max_sample_rate perf record -F32000 --aux-sample -e '{intel_pt//u,cycles:u}' \
    -- bash -c 'for i in `seq 1 100000` ; do true ; done' Use PERF_HES_UPTODATE to track whether
    perf_aux_output_begin() and perf_aux_output_end() are balanced. A cleared PERF_HES_UPTODATE bit indicates
    that an AUX output context is still open. Amend pt_event_start() / pt_event_stop() accordingly so that
    begin/end stay balanced: - In non-snapshot mode, stop() always closes the buffer (the buffer may have run
    out of space, and that accounting is done by the update), so a following start() opens a fresh one as
    before. - In snapshot/overwrite mode, stop() without PERF_EF_UPDATE leaves the buffer open so that
    pt_event_snapshot_aux() can still copy from it, and start() then only re-enables tracing instead of
    calling perf_aux_output_begin() again. Note that pt_event_del() calls pt_event_stop() with PERF_EF_UPDATE
    flag set (as is required by the documentation), so a final call to perf_aux_output_end() is assured.
    (CVE-2026-93275)

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

  - perf/x86/intel/pt: Fix stop/start with no update If pt_event_stop() is called without PERF_EF_UPDATE flag,     then perf_aux_output_end() is not called. A subsequent call to pt_event_start() will call     perf_aux_output_begin() again which violates the rule against nesting and triggers a WARNING in     perf_aux_output_begin(). Originally, pt_event_stop() was never called without PERF_EF_UPDATE, because the     only code paths to do so are from event overflow, and Intel PT does not do that. However the introduction     of group throttling by commit 9734e25fbf5ae (perf: Fix the throttle logic for a group) meant that an     Intel PT event could be throttled if it was part of a group. Throttling calls PMU ->stop() / ->start()     callbacks without flags. An example is when AUX area sampling is used. The following commands hit the     issue: echo 10000 > /proc/sys/kernel/perf_event_max_sample_rate perf record -F32000 --aux-sample -e     '{intel_pt//u,cycles:u}' \ -- bash -c 'for i in `seq 1 100000` ; do true ; done' Use PERF_HES_UPTODATE to     track whether perf_aux_output_begin() and perf_aux_output_end() are balanced. A cleared PERF_HES_UPTODATE     bit indicates that an AUX output context is still open. Amend pt_event_start() / pt_event_stop()     accordingly so that begin/end stay balanced: - In non-snapshot mode, stop() always closes the buffer (the     buffer may have run out of space, and that accounting is done by the update), so a following start() opens     a fresh one as before. - In snapshot/overwrite mode, stop() without PERF_EF_UPDATE leaves the buffer open     so that pt_event_snapshot_aux() can still copy from it, and start() then only re-enables tracing instead     of calling perf_aux_output_begin() again. Note that pt_event_del() calls pt_event_stop() with     PERF_EF_UPDATE flag set (as is required by the documentation), so a final call to perf_aux_output_end() is     assured. (CVE-2026-93275)

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

ID	Name	Product	Family	Published	Updated	Severity
475207	Google: sys-kernel/cchost-kernel-6_12, sys-kernel/cchost-kernel-6_18, sys-kernel/csql-kernel-6_12, sys-kernel/csql-kernel-6_18, sys-kernel/lakitu-kernel-6_12, sys-kernel/lakitu-kernel-6_18, sys-kernel/lakitu-nc-kernel-6_12, sys-kernel/lakitu-nc-kernel-6_18: security update to 19999.44.106	Tenable Self-Hosted Container Security	Google COS Security Checks	10/16/2026	10/16/2026	high
475207	Google: sys-kernel/cchost-kernel-6_12, sys-kernel/cchost-kernel-6_18, sys-kernel/csql-kernel-6_12, sys-kernel/csql-kernel-6_18, sys-kernel/lakitu-kernel-6_12, sys-kernel/lakitu-kernel-6_18, sys-kernel/lakitu-nc-kernel-6_12, sys-kernel/lakitu-nc-kernel-6_18: security update to 19999.44.106	Tenable Cloud Security	Google COS Security Checks	10/16/2026	10/16/2026	high
351155	Debian dsa-6528 : ata-modules-6.12.111+deb13-armmp-di - security update	Nessus	Debian Local Security Checks	9/29/2026	9/29/2026	high
362907	Debian dla-4817 : ata-modules-6.12.107+deb12-armmp-di - security update	Nessus	Debian Local Security Checks	10/4/2026	10/4/2026	high
349825	Linux Distros Unpatched Vulnerability : CVE-2026-93275	Nessus	Misc.	9/24/2026	9/30/2026	high
365279	Amazon Linux 2023 : bpftool6.12, kernel6.12, kernel6.12-devel (ALAS2023-2026-3196)	Nessus	Amazon Linux Local Security Checks	10/12/2026	10/15/2026	medium

Detections

Analytics

Plugins Search

high

high

high

high

high

medium