In the Linux kernel, the following vulnerability has been resolved: block: skip sync_blockdev() on surprise removal in bdev_mark_dead() bdev_mark_dead()'s @surprise == true means the device is already gone. The filesystem callback fs_bdev_mark_dead() honours this and skips sync_filesystem(), but the bare block device path (no ->mark_dead op) lost its !surprise guard when the holder ->mark_dead callback was wired up (see Fixes), and now calls sync_blockdev() unconditionally, which can hang forever waiting on writeback that can no longer complete. syzkaller hit this via nvme_reset_work()'s "I/O queues lost" path: nvme_mark_namespaces_dead() -> blk_mark_disk_dead() -> bdev_mark_dead(bdev, true) -> sync_blockdev() blocks in folio_wait_writeback(), wedging the reset worker and every task waiting on it. Skip the sync on surprise removal, matching fs_bdev_mark_dead(); invalidate_bdev() still runs. Orderly removal (surprise == false) is unchanged. Found by FuzzNvme(Syzkaller with FEMU fuzzing framework).

The remote Debian 12 host has packages installed that are affected by multiple vulnerabilities as referenced in the dla-4724 advisory.

    -------------------------------------------------------------------------     Debian LTS Advisory DLA-4724-1                debian-lts@lists.debian.org     https://www.debian.org/lts/security/                        Ben Hutchings     August 07, 2026                               https://wiki.debian.org/LTS
    -------------------------------------------------------------------------

    Package        : linux-6.12     Version        : 6.12.100-1~deb12u1     CVE ID         : CVE-2025-21807 CVE-2026-45944 CVE-2026-46093 CVE-2026-53005                      CVE-2026-53027 CVE-2026-53226 CVE-2026-53260 CVE-2026-53365                      CVE-2026-53392 CVE-2026-53399 CVE-2026-53402 CVE-2026-63815                      CVE-2026-63816 CVE-2026-63818 CVE-2026-63970 CVE-2026-64187                      CVE-2026-64189 CVE-2026-64192 CVE-2026-64206 CVE-2026-64227                      CVE-2026-64241 CVE-2026-64256 CVE-2026-64265 CVE-2026-64266                      CVE-2026-64268 CVE-2026-64269 CVE-2026-64270 CVE-2026-64271                      CVE-2026-64272 CVE-2026-64273 CVE-2026-64274 CVE-2026-64275                      CVE-2026-64276 CVE-2026-64277 CVE-2026-64279 CVE-2026-64284                      CVE-2026-64286 CVE-2026-64287 CVE-2026-64289 CVE-2026-64294                      CVE-2026-64296 CVE-2026-64297 CVE-2026-64298 CVE-2026-64299                      CVE-2026-64301 CVE-2026-64303 CVE-2026-64304 CVE-2026-64305                      CVE-2026-64306 CVE-2026-64307 CVE-2026-64308 CVE-2026-64309                      CVE-2026-64310 CVE-2026-64312 CVE-2026-64313 CVE-2026-64315                      CVE-2026-64316 CVE-2026-64317 CVE-2026-64318 CVE-2026-64319                      CVE-2026-64320 CVE-2026-64321 CVE-2026-64322 CVE-2026-64323                      CVE-2026-64324 CVE-2026-64326 CVE-2026-64327 CVE-2026-64328                      CVE-2026-64329 CVE-2026-64330 CVE-2026-64331 CVE-2026-64332                      CVE-2026-64333 CVE-2026-64334 CVE-2026-64335 CVE-2026-64336                      CVE-2026-64337 CVE-2026-64338 CVE-2026-64340 CVE-2026-64341                      CVE-2026-64342 CVE-2026-64343 CVE-2026-64344 CVE-2026-64345                      CVE-2026-64346 CVE-2026-64347 CVE-2026-64348 CVE-2026-64350                      CVE-2026-64351 CVE-2026-64352 CVE-2026-64354 CVE-2026-64355                      CVE-2026-64357 CVE-2026-64358 CVE-2026-64359 CVE-2026-64360                      CVE-2026-64361 CVE-2026-64362 CVE-2026-64363 CVE-2026-64364                      CVE-2026-64365 CVE-2026-64367 CVE-2026-64368 CVE-2026-64369                      CVE-2026-64370 CVE-2026-64371 CVE-2026-64372 CVE-2026-64373                      CVE-2026-64374 CVE-2026-64375 CVE-2026-64376 CVE-2026-64377                      CVE-2026-64378 CVE-2026-64379 CVE-2026-64380 CVE-2026-64381                      CVE-2026-64382 CVE-2026-64383 CVE-2026-64384 CVE-2026-64385                      CVE-2026-64386 CVE-2026-64387 CVE-2026-64390 CVE-2026-64391                      CVE-2026-64392 CVE-2026-64393 CVE-2026-64394 CVE-2026-64395                      CVE-2026-64396 CVE-2026-64397 CVE-2026-64398 CVE-2026-64399                      CVE-2026-64401 CVE-2026-64402 CVE-2026-64403 CVE-2026-64404                      CVE-2026-64405 CVE-2026-64406 CVE-2026-64407 CVE-2026-64408                      CVE-2026-64409 CVE-2026-64411 CVE-2026-64412 CVE-2026-64413                      CVE-2026-64414 CVE-2026-64415 CVE-2026-64416 CVE-2026-64417                      CVE-2026-64418 CVE-2026-64419 CVE-2026-64420 CVE-2026-64421                      CVE-2026-64422 CVE-2026-64423 CVE-2026-64424 CVE-2026-64425                      CVE-2026-64428 CVE-2026-64429 CVE-2026-64430 CVE-2026-64432                      CVE-2026-64433 CVE-2026-64434 CVE-2026-64435 CVE-2026-64436                      CVE-2026-64437 CVE-2026-64438 CVE-2026-64440 CVE-2026-64441                      CVE-2026-64442 CVE-2026-64443 CVE-2026-64444 CVE-2026-64445                      CVE-2026-64446 CVE-2026-64448 CVE-2026-64449 CVE-2026-64450                      CVE-2026-64452 CVE-2026-64454 CVE-2026-64455 CVE-2026-64456                      CVE-2026-64457 CVE-2026-64458 CVE-2026-64461 CVE-2026-64462                      CVE-2026-64463 CVE-2026-64465 CVE-2026-64468 CVE-2026-64469                      CVE-2026-64470 CVE-2026-64471 CVE-2026-64472 CVE-2026-64473                      CVE-2026-64474 CVE-2026-64475 CVE-2026-64476 CVE-2026-64477                      CVE-2026-64478 CVE-2026-64479 CVE-2026-64480 CVE-2026-64481                      CVE-2026-64482 CVE-2026-64483 CVE-2026-64484 CVE-2026-64486                      CVE-2026-64487 CVE-2026-64488 CVE-2026-64489 CVE-2026-64490                      CVE-2026-64493 CVE-2026-64494 CVE-2026-64495 CVE-2026-64496                      CVE-2026-64497 CVE-2026-64499 CVE-2026-64500 CVE-2026-64503                      CVE-2026-64504 CVE-2026-64505 CVE-2026-64507 CVE-2026-64508                      CVE-2026-64509 CVE-2026-64510 CVE-2026-64511 CVE-2026-64512                      CVE-2026-64514 CVE-2026-64530 CVE-2026-64531 CVE-2026-64532                      CVE-2026-64533 CVE-2026-64534 CVE-2026-64535 CVE-2026-64536                      CVE-2026-64537 CVE-2026-64538 CVE-2026-64539 CVE-2026-64540                      CVE-2026-64541 CVE-2026-64542 CVE-2026-64543 CVE-2026-64544                      CVE-2026-64545 CVE-2026-64546 CVE-2026-64547 CVE-2026-64548                      CVE-2026-64549 CVE-2026-64550 CVE-2026-64551 CVE-2026-64552                      CVE-2026-64553 CVE-2026-64554 CVE-2026-64555 CVE-2026-64556                      CVE-2026-64557 CVE-2026-64558 CVE-2026-64559 CVE-2026-64560                      CVE-2026-64582 CVE-2026-64585 CVE-2026-64589 CVE-2026-64590                      CVE-2026-64592 CVE-2026-64593 CVE-2026-64594 CVE-2026-64597                      CVE-2026-64598 CVE-2026-64599 CVE-2026-64600 CVE-2026-64602                      CVE-2026-64603 CVE-2026-64604     Debian Bug     : 1130336 1140651

    Linux 6.12 has been packaged for Debian 12 bookworm as linux-6.12.
    This provides a supported upgrade path for systems that currently use     kernel packages from the bookworm-backports suite.

    There is no need to upgrade systems using Linux 6.1, as that kernel     version will also continue to be supported in the LTS period.

    The apt full-upgrade command will *not* automatically install the     updated kernel packages.  You should explicitly install one of the     following metapackages first, as appropriate for your system:

        linux-image-6.12-amd64         linux-image-6.12-arm64         linux-image-6.12-arm64-16k         linux-image-6.12-armmp         linux-image-6.12-armmp-lpae         linux-image-6.12-cloud-amd64         linux-image-6.12-cloud-arm64         linux-image-6.12-powerpc64le         linux-image-6.12-powerpc64le-64k         linux-image-6.12-rt-amd64         linux-image-6.12-rt-arm64         linux-image-6.12-rt-armmp

    For example, if the command uname -r currently shows     6.12.95+deb12-amd64, you should install linux-image-6.12-amd64.

    This backport does not include the following binary packages:

        bpftool hyperv-daemons intel-sdsi libcpupower-dev libcpupower1         linux-cpupower linux-libc-dev linux-perf rtla usbip

    Older versions of most of those are built from the linux source     package in Debian 12.

    Several vulnerabilities have been discovered in the Linux kernel that     may lead to a privilege escalation, denial of service or information     leaks.

    For Debian 12 bookworm, these problems have been fixed in version     6.12.100-1~deb12u1.  This update also fixes several bugs reported to     Debian.  It additionally includes many more bug fixes from stable     updates 6.12.96-6.12.100.

    We recommend that you upgrade your linux-6.12 packages.

    For the detailed security status of linux-6.12 please refer to     its security tracker page at:
    https://security-tracker.debian.org/tracker/linux-6.12

    Further information about Debian LTS security advisories, how to apply     these updates to your system and frequently asked questions can be     found at: https://wiki.debian.org/LTS     Attachment:
    signature.asc     Description: PGP signature

Tenable has extracted the preceding description block directly from the Debian security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

An update of the linux package has been released.

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

  - block: skip sync_blockdev() on surprise removal in bdev_mark_dead() bdev_mark_dead()'s @surprise == true     means the device is already gone. The filesystem callback fs_bdev_mark_dead() honours this and skips     sync_filesystem(), but the bare block device path (no ->mark_dead op) lost its !surprise guard when the     holder ->mark_dead callback was wired up (see Fixes), and now calls sync_blockdev() unconditionally, which     can hang forever waiting on writeback that can no longer complete. syzkaller hit this via     nvme_reset_work()'s I/O queues lost path: nvme_mark_namespaces_dead() -> blk_mark_disk_dead() ->     bdev_mark_dead(bdev, true) -> sync_blockdev() blocks in folio_wait_writeback(), wedging the reset worker     and every task waiting on it. Skip the sync on surprise removal, matching fs_bdev_mark_dead();
    invalidate_bdev() still runs. Orderly removal (surprise == false) is unchanged. Found by     FuzzNvme(Syzkaller with FEMU fuzzing framework). (CVE-2026-64326)

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

ID	Name	Product	Family	Type	Severity
337239	Amazon Linux 2023 : bpftool6.12, kernel6.12, kernel6.12-devel (ALAS2023-2026-2057)	Nessus	Amazon Linux Local Security Checks	Local	medium
337207	Amazon Linux 2023 : bpftool6.18, kernel6.18, kernel6.18-devel (ALAS2023-2026-2045)	Nessus	Amazon Linux Local Security Checks	Local	high
333521	Debian dla-4724 : ata-modules-6.12.100+deb12-armmp-di - security update	Nessus	Debian Local Security Checks	Local	medium
332499	Photon OS 5.0: Linux PHSA-2026-5.0-92-0928	Nessus	PhotonOS Local Security Checks	Local	high
329961	Linux Distros Unpatched Vulnerability : CVE-2026-64326	Nessus	Misc.	Local	high
329325	Photon OS 5.0: Linux PHSA-2026-5.0-0928	Nessus	PhotonOS Local Security Checks	Local	medium

Detections

Analytics

CVE-2026-64326

medium

Tenable Plugins

medium

high

medium

high

high

medium