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

  - mm: fix zswap writeback race condition The zswap writeback mechanism can cause a race condition resulting     in memory corruption, where a swapped out page gets swapped in with data that was written to a different     page. The race unfolds like this: 1. a page with data A and swap offset X is stored in zswap 2. page A is     removed off the LRU by zpool driver for writeback in zswap-shrink work, data for A is mapped by zpool     driver 3. user space program faults and invalidates page entry A, offset X is considered free 4. kswapd     stores page B at offset X in zswap (zswap could also be full, if so, page B would then be IOed to X, then     skip step 5.) 5. entry A is replaced by B in tree->rbroot, this doesn't affect the local reference held by     zswap-shrink work 6. zswap-shrink work writes back A at X, and frees zswap entry A 7. swapin of slot X     brings A in memory instead of B The fix: Once the swap page cache has been allocated (case     ZSWAP_SWAPCACHE_NEW), zswap-shrink work just checks that the local zswap_entry reference is still the same     as the one in the tree. If it's not the same it means that it's either been invalidated or replaced, in     both cases the writeback is aborted because the local entry contains stale data. Reproducer: I originally     found this by running `stress` overnight to validate my work on the zswap writeback mechanism, it     manifested after hours on my test machine. The key to make it happen is having zswap writebacks, so     whatever setup pumps /sys/kernel/debug/zswap/written_back_pages should do the trick. In order to reproduce     this faster on a vm, I setup a system with ~100M of available memory and a 500M swap file, then running     `stress --vm 1 --vm-bytes 300000000 --vm-stride 4000` makes it happen in matter of tens of minutes. One     can speed things up even more by swinging /sys/module/zswap/parameters/max_pool_percent up and down     between, say, 20 and 1; this makes it reproduce in tens of seconds. It's crucial to set `--vm-stride` to     something other than 4096 otherwise `stress` won't realize that memory has been corrupted because all     pages would have the same data. (CVE-2023-53178)

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

Detections

Analytics

Linux Distros Unpatched Vulnerability : CVE-2023-53178

high Nessus Plugin ID 264904

Version 1.8

Version 1.7

Version 1.6

Version 1.2

Version 1.1

Version 1.8 Nov 11, 2025, 12:33 AM CVSS metrics ("CVSSv3 score" set to 7.3) CVSS metrics ("CVSSv3 vector" set to "CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H") CVSSv3 severity (based on None, severity increased from "Medium" to "High") Detection (updated detection logic) Plugin metadata Plugin Feed: 202511110033
Version 1.7 Oct 29, 2025, 3:03 AM Detection (updated detection logic) Plugin Feed: 202510290303
Version 1.6 Oct 28, 2025, 5:56 PM CVSS temporal metrics ("CVSSv2 temporal vector" set to "CVSS2#E:U/RL:U/RC:C") CVSS temporal metrics ("CVSSv3 temporal vector" set to "CVSS:3.0/E:U/RL:U/RC:C") Detection (updated detection logic) Plugin Feed: 202510281756
Version 1.2 Sep 20, 2025, 5:27 AM CVSS metrics ("CVSSv2 score" set to 4.7) CVSS metrics ("CVSSv2 vector" set to "CVSS2#AV:L/AC:M/Au:N/C:N/I:N/A:C") CVSS metrics ("CVSSv3 score" set to 6.3) CVSS metrics ("CVSSv3 vector" set to "CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H") CVSS temporal metrics ("CVSSv2 temporal vector" set to "CVSS2#E:U/RL:OF/RC:C") CVSS temporal metrics ("CVSSv3 temporal vector" set to "CVSS:3.0/E:U/RL:O/RC:C") CVSSv2 score source (set to "CVE-2023-53178") CVSSv2 severity (based on CVE-2023-53178, severity decreased from "High" to "Medium") CVSSv3 severity (based on None, severity decreased from "High" to "Medium") Detection (updated detection logic) Plugin metadata Plugin Feed: 202509200527
Version 1.1 Sep 17, 2025, 9:14 AM New Plugin Feed: 202509170914