CVE-2025-38241 (GCVE-0-2025-38241)
Vulnerability from cvelistv5
Published
2025-07-09 10:42
Modified
2025-07-28 04:15
Severity ?
VLAI Severity ?
EPSS score ?
Summary
In the Linux kernel, the following vulnerability has been resolved:
mm/shmem, swap: fix softlockup with mTHP swapin
Following softlockup can be easily reproduced on my test machine with:
echo always > /sys/kernel/mm/transparent_hugepage/hugepages-64kB/enabled
swapon /dev/zram0 # zram0 is a 48G swap device
mkdir -p /sys/fs/cgroup/memory/test
echo 1G > /sys/fs/cgroup/test/memory.max
echo $BASHPID > /sys/fs/cgroup/test/cgroup.procs
while true; do
dd if=/dev/zero of=/tmp/test.img bs=1M count=5120
cat /tmp/test.img > /dev/null
rm /tmp/test.img
done
Then after a while:
watchdog: BUG: soft lockup - CPU#0 stuck for 763s! [cat:5787]
Modules linked in: zram virtiofs
CPU: 0 UID: 0 PID: 5787 Comm: cat Kdump: loaded Tainted: G L 6.15.0.orig-gf3021d9246bc-dirty #118 PREEMPT(voluntary)·
Tainted: [L]=SOFTLOCKUP
Hardware name: Red Hat KVM/RHEL-AV, BIOS 0.0.0 02/06/2015
RIP: 0010:mpol_shared_policy_lookup+0xd/0x70
Code: e9 b8 b4 ff ff 31 c0 c3 cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 41 54 55 53 <48> 8b 1f 48 85 db 74 41 4c 8d 67 08 48 89 fb 48 89 f5 4c 89 e7 e8
RSP: 0018:ffffc90002b1fc28 EFLAGS: 00000202
RAX: 00000000001c20ca RBX: 0000000000724e1e RCX: 0000000000000001
RDX: ffff888118e214c8 RSI: 0000000000057d42 RDI: ffff888118e21518
RBP: 000000000002bec8 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000bf4 R11: 0000000000000000 R12: 0000000000000001
R13: 00000000001c20ca R14: 00000000001c20ca R15: 0000000000000000
FS: 00007f03f995c740(0000) GS:ffff88a07ad9a000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f03f98f1000 CR3: 0000000144626004 CR4: 0000000000770eb0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
<TASK>
shmem_alloc_folio+0x31/0xc0
shmem_swapin_folio+0x309/0xcf0
? filemap_get_entry+0x117/0x1e0
? xas_load+0xd/0xb0
? filemap_get_entry+0x101/0x1e0
shmem_get_folio_gfp+0x2ed/0x5b0
shmem_file_read_iter+0x7f/0x2e0
vfs_read+0x252/0x330
ksys_read+0x68/0xf0
do_syscall_64+0x4c/0x1c0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7f03f9a46991
Code: 00 48 8b 15 81 14 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8 20 ad 01 00 f3 0f 1e fa 80 3d 35 97 10 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec
RSP: 002b:00007fff3c52bd28 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
RAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007f03f9a46991
RDX: 0000000000040000 RSI: 00007f03f98ba000 RDI: 0000000000000003
RBP: 00007fff3c52bd50 R08: 0000000000000000 R09: 00007f03f9b9a380
R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000
R13: 00007f03f98ba000 R14: 0000000000000003 R15: 0000000000000000
</TASK>
The reason is simple, readahead brought some order 0 folio in swap cache,
and the swapin mTHP folio being allocated is in conflict with it, so
swapcache_prepare fails and causes shmem_swap_alloc_folio to return
-EEXIST, and shmem simply retries again and again causing this loop.
Fix it by applying a similar fix for anon mTHP swapin.
The performance change is very slight, time of swapin 10g zero folios
with shmem (test for 12 times):
Before: 2.47s
After: 2.48s
[kasong@tencent.com: add comment]
References
Impacted products
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"mm/memory.c",
"mm/shmem.c",
"mm/swap.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "1283dfc1e0cd52cf525c2cb1b59a6f9183aab7ca",
"status": "affected",
"version": "1dd44c0af4fa1e80a4e82faa10cbf5d22da40362",
"versionType": "git"
},
{
"lessThan": "a05dd8ae5cbb1cb45f349922cfea4f548a5e5d6f",
"status": "affected",
"version": "1dd44c0af4fa1e80a4e82faa10cbf5d22da40362",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"mm/memory.c",
"mm/shmem.c",
"mm/swap.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.14"
},
{
"lessThan": "6.14",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.15.*",
"status": "unaffected",
"version": "6.15.5",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.16",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.15.5",
"versionStartIncluding": "6.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.16",
"versionStartIncluding": "6.14",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/shmem, swap: fix softlockup with mTHP swapin\n\nFollowing softlockup can be easily reproduced on my test machine with:\n\necho always \u003e /sys/kernel/mm/transparent_hugepage/hugepages-64kB/enabled\nswapon /dev/zram0 # zram0 is a 48G swap device\nmkdir -p /sys/fs/cgroup/memory/test\necho 1G \u003e /sys/fs/cgroup/test/memory.max\necho $BASHPID \u003e /sys/fs/cgroup/test/cgroup.procs\nwhile true; do\n dd if=/dev/zero of=/tmp/test.img bs=1M count=5120\n cat /tmp/test.img \u003e /dev/null\n rm /tmp/test.img\ndone\n\nThen after a while:\nwatchdog: BUG: soft lockup - CPU#0 stuck for 763s! [cat:5787]\nModules linked in: zram virtiofs\nCPU: 0 UID: 0 PID: 5787 Comm: cat Kdump: loaded Tainted: G L 6.15.0.orig-gf3021d9246bc-dirty #118 PREEMPT(voluntary)\u00b7\nTainted: [L]=SOFTLOCKUP\nHardware name: Red Hat KVM/RHEL-AV, BIOS 0.0.0 02/06/2015\nRIP: 0010:mpol_shared_policy_lookup+0xd/0x70\nCode: e9 b8 b4 ff ff 31 c0 c3 cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 41 54 55 53 \u003c48\u003e 8b 1f 48 85 db 74 41 4c 8d 67 08 48 89 fb 48 89 f5 4c 89 e7 e8\nRSP: 0018:ffffc90002b1fc28 EFLAGS: 00000202\nRAX: 00000000001c20ca RBX: 0000000000724e1e RCX: 0000000000000001\nRDX: ffff888118e214c8 RSI: 0000000000057d42 RDI: ffff888118e21518\nRBP: 000000000002bec8 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000bf4 R11: 0000000000000000 R12: 0000000000000001\nR13: 00000000001c20ca R14: 00000000001c20ca R15: 0000000000000000\nFS: 00007f03f995c740(0000) GS:ffff88a07ad9a000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f03f98f1000 CR3: 0000000144626004 CR4: 0000000000770eb0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u003cTASK\u003e\n shmem_alloc_folio+0x31/0xc0\n shmem_swapin_folio+0x309/0xcf0\n ? filemap_get_entry+0x117/0x1e0\n ? xas_load+0xd/0xb0\n ? filemap_get_entry+0x101/0x1e0\n shmem_get_folio_gfp+0x2ed/0x5b0\n shmem_file_read_iter+0x7f/0x2e0\n vfs_read+0x252/0x330\n ksys_read+0x68/0xf0\n do_syscall_64+0x4c/0x1c0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7f03f9a46991\nCode: 00 48 8b 15 81 14 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8 20 ad 01 00 f3 0f 1e fa 80 3d 35 97 10 00 00 74 13 31 c0 0f 05 \u003c48\u003e 3d 00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec\nRSP: 002b:00007fff3c52bd28 EFLAGS: 00000246 ORIG_RAX: 0000000000000000\nRAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007f03f9a46991\nRDX: 0000000000040000 RSI: 00007f03f98ba000 RDI: 0000000000000003\nRBP: 00007fff3c52bd50 R08: 0000000000000000 R09: 00007f03f9b9a380\nR10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000\nR13: 00007f03f98ba000 R14: 0000000000000003 R15: 0000000000000000\n \u003c/TASK\u003e\n\nThe reason is simple, readahead brought some order 0 folio in swap cache,\nand the swapin mTHP folio being allocated is in conflict with it, so\nswapcache_prepare fails and causes shmem_swap_alloc_folio to return\n-EEXIST, and shmem simply retries again and again causing this loop.\n\nFix it by applying a similar fix for anon mTHP swapin.\n\nThe performance change is very slight, time of swapin 10g zero folios\nwith shmem (test for 12 times):\nBefore: 2.47s\nAfter: 2.48s\n\n[kasong@tencent.com: add comment]"
}
],
"providerMetadata": {
"dateUpdated": "2025-07-28T04:15:58.148Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/1283dfc1e0cd52cf525c2cb1b59a6f9183aab7ca"
},
{
"url": "https://git.kernel.org/stable/c/a05dd8ae5cbb1cb45f349922cfea4f548a5e5d6f"
}
],
"title": "mm/shmem, swap: fix softlockup with mTHP swapin",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-38241",
"datePublished": "2025-07-09T10:42:24.777Z",
"dateReserved": "2025-04-16T04:51:23.996Z",
"dateUpdated": "2025-07-28T04:15:58.148Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1",
"vulnerability-lookup:meta": {
"nvd": "{\"cve\":{\"id\":\"CVE-2025-38241\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-07-09T11:15:26.107\",\"lastModified\":\"2025-07-10T13:17:30.017\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nmm/shmem, swap: fix softlockup with mTHP swapin\\n\\nFollowing softlockup can be easily reproduced on my test machine with:\\n\\necho always \u003e /sys/kernel/mm/transparent_hugepage/hugepages-64kB/enabled\\nswapon /dev/zram0 # zram0 is a 48G swap device\\nmkdir -p /sys/fs/cgroup/memory/test\\necho 1G \u003e /sys/fs/cgroup/test/memory.max\\necho $BASHPID \u003e /sys/fs/cgroup/test/cgroup.procs\\nwhile true; do\\n dd if=/dev/zero of=/tmp/test.img bs=1M count=5120\\n cat /tmp/test.img \u003e /dev/null\\n rm /tmp/test.img\\ndone\\n\\nThen after a while:\\nwatchdog: BUG: soft lockup - CPU#0 stuck for 763s! [cat:5787]\\nModules linked in: zram virtiofs\\nCPU: 0 UID: 0 PID: 5787 Comm: cat Kdump: loaded Tainted: G L 6.15.0.orig-gf3021d9246bc-dirty #118 PREEMPT(voluntary)\u00b7\\nTainted: [L]=SOFTLOCKUP\\nHardware name: Red Hat KVM/RHEL-AV, BIOS 0.0.0 02/06/2015\\nRIP: 0010:mpol_shared_policy_lookup+0xd/0x70\\nCode: e9 b8 b4 ff ff 31 c0 c3 cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 41 54 55 53 \u003c48\u003e 8b 1f 48 85 db 74 41 4c 8d 67 08 48 89 fb 48 89 f5 4c 89 e7 e8\\nRSP: 0018:ffffc90002b1fc28 EFLAGS: 00000202\\nRAX: 00000000001c20ca RBX: 0000000000724e1e RCX: 0000000000000001\\nRDX: ffff888118e214c8 RSI: 0000000000057d42 RDI: ffff888118e21518\\nRBP: 000000000002bec8 R08: 0000000000000001 R09: 0000000000000000\\nR10: 0000000000000bf4 R11: 0000000000000000 R12: 0000000000000001\\nR13: 00000000001c20ca R14: 00000000001c20ca R15: 0000000000000000\\nFS: 00007f03f995c740(0000) GS:ffff88a07ad9a000(0000) knlGS:0000000000000000\\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\\nCR2: 00007f03f98f1000 CR3: 0000000144626004 CR4: 0000000000770eb0\\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\\nPKRU: 55555554\\nCall Trace:\\n \u003cTASK\u003e\\n shmem_alloc_folio+0x31/0xc0\\n shmem_swapin_folio+0x309/0xcf0\\n ? filemap_get_entry+0x117/0x1e0\\n ? xas_load+0xd/0xb0\\n ? filemap_get_entry+0x101/0x1e0\\n shmem_get_folio_gfp+0x2ed/0x5b0\\n shmem_file_read_iter+0x7f/0x2e0\\n vfs_read+0x252/0x330\\n ksys_read+0x68/0xf0\\n do_syscall_64+0x4c/0x1c0\\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\\nRIP: 0033:0x7f03f9a46991\\nCode: 00 48 8b 15 81 14 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8 20 ad 01 00 f3 0f 1e fa 80 3d 35 97 10 00 00 74 13 31 c0 0f 05 \u003c48\u003e 3d 00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec\\nRSP: 002b:00007fff3c52bd28 EFLAGS: 00000246 ORIG_RAX: 0000000000000000\\nRAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007f03f9a46991\\nRDX: 0000000000040000 RSI: 00007f03f98ba000 RDI: 0000000000000003\\nRBP: 00007fff3c52bd50 R08: 0000000000000000 R09: 00007f03f9b9a380\\nR10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000\\nR13: 00007f03f98ba000 R14: 0000000000000003 R15: 0000000000000000\\n \u003c/TASK\u003e\\n\\nThe reason is simple, readahead brought some order 0 folio in swap cache,\\nand the swapin mTHP folio being allocated is in conflict with it, so\\nswapcache_prepare fails and causes shmem_swap_alloc_folio to return\\n-EEXIST, and shmem simply retries again and again causing this loop.\\n\\nFix it by applying a similar fix for anon mTHP swapin.\\n\\nThe performance change is very slight, time of swapin 10g zero folios\\nwith shmem (test for 12 times):\\nBefore: 2.47s\\nAfter: 2.48s\\n\\n[kasong@tencent.com: add comment]\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/shmem, swap: corregir bloqueo suave con swapin mTHP El siguiente bloqueo suave se puede reproducir f\u00e1cilmente en mi m\u00e1quina de prueba con: echo always \u0026gt; /sys/kernel/mm/transparent_hugepage/hugepages-64kB/enabled swapon /dev/zram0 # zram0 es un dispositivo de intercambio de 48G mkdir -p /sys/fs/cgroup/memory/test echo 1G \u0026gt; /sys/fs/cgroup/test/memory.max echo $BASHPID \u0026gt; /sys/fs/cgroup/test/cgroup.procs while true; hacer dd if=/dev/zero of=/tmp/test.img bs=1M count=5120 cat /tmp/test.img \u0026gt; /dev/null rm /tmp/test.img done Luego de un rato: watchdog: BUG: bloqueo suave - \u00a1CPU#0 bloqueada durante 763 s! [cat:5787] M\u00f3dulos vinculados: zram virtiofs CPU: 0 UID: 0 PID: 5787 Comm: cat Kdump: cargado Contaminado: GL 6.15.0.orig-gf3021d9246bc-dirty #118 PREEMPT(voluntario)\u00b7 Contaminado: [L]=SOFTLOCKUP Nombre del hardware: Red Hat KVM/RHEL-AV, BIOS 0.0.0 02/06/2015 RIP: 0010:mpol_shared_policy_lookup+0xd/0x70 Code: e9 b8 b4 ff ff 31 c0 c3 cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 41 54 55 53 \u0026lt;48\u0026gt; 8b 1f 48 85 db 74 41 4c 8d 67 08 48 89 fb 48 89 f5 4c 89 e7 e8 RSP: 0018:ffffc90002b1fc28 EFLAGS: 00000202 RAX: 00000000001c20ca RBX: 0000000000724e1e RCX: 0000000000000001 RDX: ffff888118e214c8 RSI: 0000000000057d42 RDI: ffff888118e21518 RBP: 000000000002bec8 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000bf4 R11: 0000000000000000 R12: 0000000000000001 R13: 00000000001c20ca R14: 00000000001c20ca R15: 0000000000000000 FS: 00007f03f995c740(0000) GS:ffff88a07ad9a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f03f98f1000 CR3: 0000000144626004 CR4: 0000000000770eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: shmem_alloc_folio+0x31/0xc0 shmem_swapin_folio+0x309/0xcf0 ? filemap_get_entry+0x117/0x1e0 ? xas_load+0xd/0xb0 ? filemap_get_entry+0x101/0x1e0 shmem_get_folio_gfp+0x2ed/0x5b0 shmem_file_read_iter+0x7f/0x2e0 vfs_read+0x252/0x330 ksys_read+0x68/0xf0 do_syscall_64+0x4c/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f03f9a46991 Code: 00 48 8b 15 81 14 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8 20 ad 01 00 f3 0f 1e fa 80 3d 35 97 10 00 00 74 13 31 c0 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec RSP: 002b:00007fff3c52bd28 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007f03f9a46991 RDX: 0000000000040000 RSI: 00007f03f98ba000 RDI: 0000000000000003 RBP: 00007fff3c52bd50 R08: 0000000000000000 R09: 00007f03f9b9a380 R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000 R13: 00007f03f98ba000 R14: 0000000000000003 R15: 0000000000000000 La raz\u00f3n es simple, la lectura anticipada trajo alg\u00fan folio de orden 0 en la cach\u00e9 de intercambio y El folio mTHP de intercambio que se est\u00e1 asignando entra en conflicto con \u00e9l, por lo que swapcache_prepare falla y provoca que shmem_swap_alloc_folio devuelva -EEXIST, y shmem simplemente reintenta una y otra vez, causando este bucle. Se puede solucionar aplicando una soluci\u00f3n similar para el intercambio mTHP an\u00f3nimo. El cambio de rendimiento es muy leve; tiempo de intercambio 10g cero folios con shmem (prueba realizada 12 veces): Antes: 2.47 s Despu\u00e9s: 2.48 s [kasong@tencent.com: a\u00f1adir comentario]\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/1283dfc1e0cd52cf525c2cb1b59a6f9183aab7ca\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/a05dd8ae5cbb1cb45f349922cfea4f548a5e5d6f\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
}
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…
Loading…