CVE-2025-22059 (GCVE-0-2025-22059)
Vulnerability from cvelistv5
Published
2025-04-16 14:12
Modified
2026-08-05 11:56
Severity ?
VLAI Severity ?
EPSS score ?
Summary
In the Linux kernel, the following vulnerability has been resolved:
udp: Fix multiple wraparounds of sk->sk_rmem_alloc.
__udp_enqueue_schedule_skb() has the following condition:
if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf)
goto drop;
sk->sk_rcvbuf is initialised by net.core.rmem_default and later can
be configured by SO_RCVBUF, which is limited by net.core.rmem_max,
or SO_RCVBUFFORCE.
If we set INT_MAX to sk->sk_rcvbuf, the condition is always false
as sk->sk_rmem_alloc is also signed int.
Then, the size of the incoming skb is added to sk->sk_rmem_alloc
unconditionally.
This results in integer overflow (possibly multiple times) on
sk->sk_rmem_alloc and allows a single socket to have skb up to
net.core.udp_mem[1].
For example, if we set a large value to udp_mem[1] and INT_MAX to
sk->sk_rcvbuf and flood packets to the socket, we can see multiple
overflows:
# cat /proc/net/sockstat | grep UDP:
UDP: inuse 3 mem 7956736 <-- (7956736 << 12) bytes > INT_MAX * 15
^- PAGE_SHIFT
# ss -uam
State Recv-Q ...
UNCONN -1757018048 ... <-- flipping the sign repeatedly
skmem:(r2537949248,rb2147483646,t0,tb212992,f1984,w0,o0,bl0,d0)
Previously, we had a boundary check for INT_MAX, which was removed by
commit 6a1f12dd85a8 ("udp: relax atomic operation on sk->sk_rmem_alloc").
A complete fix would be to revert it and cap the right operand by
INT_MAX:
rmem = atomic_add_return(size, &sk->sk_rmem_alloc);
if (rmem > min(size + (unsigned int)sk->sk_rcvbuf, INT_MAX))
goto uncharge_drop;
but we do not want to add the expensive atomic_add_return() back just
for the corner case.
Casting rmem to unsigned int prevents multiple wraparounds, but we still
allow a single wraparound.
# cat /proc/net/sockstat | grep UDP:
UDP: inuse 3 mem 524288 <-- (INT_MAX + 1) >> 12
# ss -uam
State Recv-Q ...
UNCONN -2147482816 ... <-- INT_MAX + 831 bytes
skmem:(r2147484480,rb2147483646,t0,tb212992,f3264,w0,o0,bl0,d14468947)
So, let's define rmem and rcvbuf as unsigned int and check skb->truesize
only when rcvbuf is large enough to lower the overflow possibility.
Note that we still have a small chance to see overflow if multiple skbs
to the same socket are processed on different core at the same time and
each size does not exceed the limit but the total size does.
Note also that we must ignore skb->truesize for a small buffer as
explained in commit 363dc73acacb ("udp: be less conservative with
sock rmem accounting").
References
| URL | Tags | |
|---|---|---|
Impacted products
{
"containers": {
"adp": [
{
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
}
},
{
"other": {
"content": {
"id": "CVE-2025-22059",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-01T17:41:49.675955Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-190",
"description": "CWE-190 Integer Overflow or Wraparound",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2025-10-01T17:41:54.297Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/ipv4/udp.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "94d5ad7b41122be33ebc2a6830fe710cba1ecd75",
"status": "affected",
"version": "6a1f12dd85a8b24f871dfcf467378660af9c064d",
"versionType": "git"
},
{
"lessThan": "1f529988efe9870db802cb79d01d8f473099b4d7",
"status": "affected",
"version": "6a1f12dd85a8b24f871dfcf467378660af9c064d",
"versionType": "git"
},
{
"lessThan": "7571aadd20289e9ea10ebfed0986f39ed8b3c16b",
"status": "affected",
"version": "6a1f12dd85a8b24f871dfcf467378660af9c064d",
"versionType": "git"
},
{
"lessThan": "5a465a0da13ee9fbd7d3cd0b2893309b0fe4b7e3",
"status": "affected",
"version": "6a1f12dd85a8b24f871dfcf467378660af9c064d",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/ipv4/udp.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.10"
},
{
"lessThan": "6.10",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.23",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.13.*",
"status": "unaffected",
"version": "6.13.11",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.14.*",
"status": "unaffected",
"version": "6.14.2",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.15",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.23",
"versionStartIncluding": "6.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.13.11",
"versionStartIncluding": "6.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.14.2",
"versionStartIncluding": "6.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.15",
"versionStartIncluding": "6.10",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nudp: Fix multiple wraparounds of sk-\u003esk_rmem_alloc.\n\n__udp_enqueue_schedule_skb() has the following condition:\n\n if (atomic_read(\u0026sk-\u003esk_rmem_alloc) \u003e sk-\u003esk_rcvbuf)\n goto drop;\n\nsk-\u003esk_rcvbuf is initialised by net.core.rmem_default and later can\nbe configured by SO_RCVBUF, which is limited by net.core.rmem_max,\nor SO_RCVBUFFORCE.\n\nIf we set INT_MAX to sk-\u003esk_rcvbuf, the condition is always false\nas sk-\u003esk_rmem_alloc is also signed int.\n\nThen, the size of the incoming skb is added to sk-\u003esk_rmem_alloc\nunconditionally.\n\nThis results in integer overflow (possibly multiple times) on\nsk-\u003esk_rmem_alloc and allows a single socket to have skb up to\nnet.core.udp_mem[1].\n\nFor example, if we set a large value to udp_mem[1] and INT_MAX to\nsk-\u003esk_rcvbuf and flood packets to the socket, we can see multiple\noverflows:\n\n # cat /proc/net/sockstat | grep UDP:\n UDP: inuse 3 mem 7956736 \u003c-- (7956736 \u003c\u003c 12) bytes \u003e INT_MAX * 15\n ^- PAGE_SHIFT\n # ss -uam\n State Recv-Q ...\n UNCONN -1757018048 ... \u003c-- flipping the sign repeatedly\n skmem:(r2537949248,rb2147483646,t0,tb212992,f1984,w0,o0,bl0,d0)\n\nPreviously, we had a boundary check for INT_MAX, which was removed by\ncommit 6a1f12dd85a8 (\"udp: relax atomic operation on sk-\u003esk_rmem_alloc\").\n\nA complete fix would be to revert it and cap the right operand by\nINT_MAX:\n\n rmem = atomic_add_return(size, \u0026sk-\u003esk_rmem_alloc);\n if (rmem \u003e min(size + (unsigned int)sk-\u003esk_rcvbuf, INT_MAX))\n goto uncharge_drop;\n\nbut we do not want to add the expensive atomic_add_return() back just\nfor the corner case.\n\nCasting rmem to unsigned int prevents multiple wraparounds, but we still\nallow a single wraparound.\n\n # cat /proc/net/sockstat | grep UDP:\n UDP: inuse 3 mem 524288 \u003c-- (INT_MAX + 1) \u003e\u003e 12\n\n # ss -uam\n State Recv-Q ...\n UNCONN -2147482816 ... \u003c-- INT_MAX + 831 bytes\n skmem:(r2147484480,rb2147483646,t0,tb212992,f3264,w0,o0,bl0,d14468947)\n\nSo, let\u0027s define rmem and rcvbuf as unsigned int and check skb-\u003etruesize\nonly when rcvbuf is large enough to lower the overflow possibility.\n\nNote that we still have a small chance to see overflow if multiple skbs\nto the same socket are processed on different core at the same time and\neach size does not exceed the limit but the total size does.\n\nNote also that we must ignore skb-\u003etruesize for a small buffer as\nexplained in commit 363dc73acacb (\"udp: be less conservative with\nsock rmem accounting\")."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.5,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:N - The overflow is driven entirely by received UDP datagrams arriving via `udp_rcv()`/`__udp4_lib_rcv()` (and the IPv6 equivalent) in softirq context, so a remote attacker anywhere on the network triggers it by flooding an open UDP port. No local access is needed to drive the flood.\nAC:L - On an affected host (a daemon using SO_RCVBUFFORCE, or the common high-throughput tuning `net.core.rmem_max` \u2265 512MB), a plain sustained UDP flood deterministically drives `sk_rmem_alloc` past INT_MAX \u2014 there is no race to win, no memory-layout dependence, and no timing requirement.\nPR:N - UDP is connectionless with no authentication; any unauthenticated remote host can send datagrams to the bound port and reach `__udp_enqueue_schedule_skb()`. No privileges or credentials exist on that receive path.\nUI:N - Packet reception and enqueue happen in softirq context with no involvement from any local user or application. The attacker needs only to send packets.\nS:U - The overflow, the corrupted accounting counters, and the resulting memory exhaustion are all confined to the kernel\u0027s own networking layer, which is the same security authority as the vulnerable component. No hypervisor, IOMMU, or sandbox boundary is crossed.\nC:N - The bug corrupts only integer accounting counters (`sk_rmem_alloc`, `sk_forward_alloc`, `udp_memory_allocated`); there is no out-of-bounds read, no use-after-free, and no path by which kernel memory contents are exposed to the attacker.\nI:N - There is no out-of-bounds or arbitrary write and no control-flow hijack primitive \u2014 the only state altered is internal memory bookkeeping, whose sole security-relevant manifestation is the availability loss already scored under A.\nA:H - Bypassing the per-socket receive limit lets one socket pin skb memory up to the system-global `udp_mem` hard limit (~18.75% of RAM), starving every UDP socket on the host across all namespaces and driving the machine into severe memory pressure/OOM \u2014 a complete denial of UDP service."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T11:56:26.071Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/94d5ad7b41122be33ebc2a6830fe710cba1ecd75"
},
{
"url": "https://git.kernel.org/stable/c/1f529988efe9870db802cb79d01d8f473099b4d7"
},
{
"url": "https://git.kernel.org/stable/c/7571aadd20289e9ea10ebfed0986f39ed8b3c16b"
},
{
"url": "https://git.kernel.org/stable/c/5a465a0da13ee9fbd7d3cd0b2893309b0fe4b7e3"
}
],
"title": "udp: Fix multiple wraparounds of sk-\u003esk_rmem_alloc.",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-22059",
"datePublished": "2025-04-16T14:12:15.505Z",
"dateReserved": "2024-12-29T08:45:45.812Z",
"dateUpdated": "2026-08-05T11:56:26.071Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"vulnrichment": {
"containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"cvssV3_1\": {\"scope\": \"UNCHANGED\", \"version\": \"3.1\", \"baseScore\": 5.5, \"attackVector\": \"LOCAL\", \"baseSeverity\": \"MEDIUM\", \"vectorString\": \"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\", \"integrityImpact\": \"NONE\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"LOW\", \"availabilityImpact\": \"HIGH\", \"privilegesRequired\": \"LOW\", \"confidentialityImpact\": \"NONE\"}}, {\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2025-22059\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2025-10-01T17:41:49.675955Z\"}}}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-190\", \"description\": \"CWE-190 Integer Overflow or Wraparound\"}]}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2025-10-01T14:40:55.818Z\"}}], \"cna\": {\"title\": \"udp: Fix multiple wraparounds of sk-\u003esk_rmem_alloc.\", \"affected\": [{\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"6a1f12dd85a8b24f871dfcf467378660af9c064d\", \"lessThan\": \"94d5ad7b41122be33ebc2a6830fe710cba1ecd75\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"6a1f12dd85a8b24f871dfcf467378660af9c064d\", \"lessThan\": \"1f529988efe9870db802cb79d01d8f473099b4d7\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"6a1f12dd85a8b24f871dfcf467378660af9c064d\", \"lessThan\": \"7571aadd20289e9ea10ebfed0986f39ed8b3c16b\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"6a1f12dd85a8b24f871dfcf467378660af9c064d\", \"lessThan\": \"5a465a0da13ee9fbd7d3cd0b2893309b0fe4b7e3\", \"versionType\": \"git\"}], \"programFiles\": [\"net/ipv4/udp.c\"], \"defaultStatus\": \"unaffected\"}, {\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"6.10\"}, {\"status\": \"unaffected\", \"version\": \"0\", \"lessThan\": \"6.10\", \"versionType\": \"semver\"}, {\"status\": \"unaffected\", \"version\": \"6.12.23\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.12.*\"}, {\"status\": \"unaffected\", \"version\": \"6.13.11\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.13.*\"}, {\"status\": \"unaffected\", \"version\": \"6.14.2\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.14.*\"}, {\"status\": \"unaffected\", \"version\": \"6.15\", \"versionType\": \"original_commit_for_fix\", \"lessThanOrEqual\": \"*\"}], \"programFiles\": [\"net/ipv4/udp.c\"], \"defaultStatus\": \"affected\"}], \"references\": [{\"url\": \"https://git.kernel.org/stable/c/94d5ad7b41122be33ebc2a6830fe710cba1ecd75\"}, {\"url\": \"https://git.kernel.org/stable/c/1f529988efe9870db802cb79d01d8f473099b4d7\"}, {\"url\": \"https://git.kernel.org/stable/c/7571aadd20289e9ea10ebfed0986f39ed8b3c16b\"}, {\"url\": \"https://git.kernel.org/stable/c/5a465a0da13ee9fbd7d3cd0b2893309b0fe4b7e3\"}], \"x_generator\": {\"engine\": \"bippy-1.2.0\"}, \"descriptions\": [{\"lang\": \"en\", \"value\": \"In the Linux kernel, the following vulnerability has been resolved:\\n\\nudp: Fix multiple wraparounds of sk-\u003esk_rmem_alloc.\\n\\n__udp_enqueue_schedule_skb() has the following condition:\\n\\n if (atomic_read(\u0026sk-\u003esk_rmem_alloc) \u003e sk-\u003esk_rcvbuf)\\n goto drop;\\n\\nsk-\u003esk_rcvbuf is initialised by net.core.rmem_default and later can\\nbe configured by SO_RCVBUF, which is limited by net.core.rmem_max,\\nor SO_RCVBUFFORCE.\\n\\nIf we set INT_MAX to sk-\u003esk_rcvbuf, the condition is always false\\nas sk-\u003esk_rmem_alloc is also signed int.\\n\\nThen, the size of the incoming skb is added to sk-\u003esk_rmem_alloc\\nunconditionally.\\n\\nThis results in integer overflow (possibly multiple times) on\\nsk-\u003esk_rmem_alloc and allows a single socket to have skb up to\\nnet.core.udp_mem[1].\\n\\nFor example, if we set a large value to udp_mem[1] and INT_MAX to\\nsk-\u003esk_rcvbuf and flood packets to the socket, we can see multiple\\noverflows:\\n\\n # cat /proc/net/sockstat | grep UDP:\\n UDP: inuse 3 mem 7956736 \u003c-- (7956736 \u003c\u003c 12) bytes \u003e INT_MAX * 15\\n ^- PAGE_SHIFT\\n # ss -uam\\n State Recv-Q ...\\n UNCONN -1757018048 ... \u003c-- flipping the sign repeatedly\\n skmem:(r2537949248,rb2147483646,t0,tb212992,f1984,w0,o0,bl0,d0)\\n\\nPreviously, we had a boundary check for INT_MAX, which was removed by\\ncommit 6a1f12dd85a8 (\\\"udp: relax atomic operation on sk-\u003esk_rmem_alloc\\\").\\n\\nA complete fix would be to revert it and cap the right operand by\\nINT_MAX:\\n\\n rmem = atomic_add_return(size, \u0026sk-\u003esk_rmem_alloc);\\n if (rmem \u003e min(size + (unsigned int)sk-\u003esk_rcvbuf, INT_MAX))\\n goto uncharge_drop;\\n\\nbut we do not want to add the expensive atomic_add_return() back just\\nfor the corner case.\\n\\nCasting rmem to unsigned int prevents multiple wraparounds, but we still\\nallow a single wraparound.\\n\\n # cat /proc/net/sockstat | grep UDP:\\n UDP: inuse 3 mem 524288 \u003c-- (INT_MAX + 1) \u003e\u003e 12\\n\\n # ss -uam\\n State Recv-Q ...\\n UNCONN -2147482816 ... \u003c-- INT_MAX + 831 bytes\\n skmem:(r2147484480,rb2147483646,t0,tb212992,f3264,w0,o0,bl0,d14468947)\\n\\nSo, let\u0027s define rmem and rcvbuf as unsigned int and check skb-\u003etruesize\\nonly when rcvbuf is large enough to lower the overflow possibility.\\n\\nNote that we still have a small chance to see overflow if multiple skbs\\nto the same socket are processed on different core at the same time and\\neach size does not exceed the limit but the total size does.\\n\\nNote also that we must ignore skb-\u003etruesize for a small buffer as\\nexplained in commit 363dc73acacb (\\\"udp: be less conservative with\\nsock rmem accounting\\\").\"}], \"cpeApplicability\": [{\"nodes\": [{\"negate\": false, \"cpeMatch\": [{\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.12.23\", \"versionStartIncluding\": \"6.10\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.13.11\", \"versionStartIncluding\": \"6.10\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.14.2\", \"versionStartIncluding\": \"6.10\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.15\", \"versionStartIncluding\": \"6.10\"}], \"operator\": \"OR\"}]}], \"providerMetadata\": {\"orgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"shortName\": \"Linux\", \"dateUpdated\": \"2025-05-26T05:17:34.456Z\"}}}",
"cveMetadata": "{\"cveId\": \"CVE-2025-22059\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2025-10-01T17:41:54.297Z\", \"dateReserved\": \"2024-12-29T08:45:45.812Z\", \"assignerOrgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"datePublished\": \"2025-04-16T14:12:15.505Z\", \"assignerShortName\": \"Linux\"}",
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
}
}
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.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- 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…