gsd-2021-46939
Vulnerability from gsd
Modified
2024-02-26 06:03
Details
In the Linux kernel, the following vulnerability has been resolved:
tracing: Restructure trace_clock_global() to never block
It was reported that a fix to the ring buffer recursion detection would
cause a hung machine when performing suspend / resume testing. The
following backtrace was extracted from debugging that case:
Call Trace:
trace_clock_global+0x91/0xa0
__rb_reserve_next+0x237/0x460
ring_buffer_lock_reserve+0x12a/0x3f0
trace_buffer_lock_reserve+0x10/0x50
__trace_graph_return+0x1f/0x80
trace_graph_return+0xb7/0xf0
? trace_clock_global+0x91/0xa0
ftrace_return_to_handler+0x8b/0xf0
? pv_hash+0xa0/0xa0
return_to_handler+0x15/0x30
? ftrace_graph_caller+0xa0/0xa0
? trace_clock_global+0x91/0xa0
? __rb_reserve_next+0x237/0x460
? ring_buffer_lock_reserve+0x12a/0x3f0
? trace_event_buffer_lock_reserve+0x3c/0x120
? trace_event_buffer_reserve+0x6b/0xc0
? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0
? dpm_run_callback+0x3b/0xc0
? pm_ops_is_empty+0x50/0x50
? platform_get_irq_byname_optional+0x90/0x90
? trace_device_pm_callback_start+0x82/0xd0
? dpm_run_callback+0x49/0xc0
With the following RIP:
RIP: 0010:native_queued_spin_lock_slowpath+0x69/0x200
Since the fix to the recursion detection would allow a single recursion to
happen while tracing, this lead to the trace_clock_global() taking a spin
lock and then trying to take it again:
ring_buffer_lock_reserve() {
trace_clock_global() {
arch_spin_lock() {
queued_spin_lock_slowpath() {
/* lock taken */
(something else gets traced by function graph tracer)
ring_buffer_lock_reserve() {
trace_clock_global() {
arch_spin_lock() {
queued_spin_lock_slowpath() {
/* DEAD LOCK! */
Tracing should *never* block, as it can lead to strange lockups like the
above.
Restructure the trace_clock_global() code to instead of simply taking a
lock to update the recorded "prev_time" simply use it, as two events
happening on two different CPUs that calls this at the same time, really
doesn't matter which one goes first. Use a trylock to grab the lock for
updating the prev_time, and if it fails, simply try again the next time.
If it failed to be taken, that means something else is already updating
it.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761
Aliases
{
"gsd": {
"metadata": {
"exploitCode": "unknown",
"remediation": "unknown",
"reportConfidence": "confirmed",
"type": "vulnerability"
},
"osvSchema": {
"aliases": [
"CVE-2021-46939"
],
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Restructure trace_clock_global() to never block\n\nIt was reported that a fix to the ring buffer recursion detection would\ncause a hung machine when performing suspend / resume testing. The\nfollowing backtrace was extracted from debugging that case:\n\nCall Trace:\n trace_clock_global+0x91/0xa0\n __rb_reserve_next+0x237/0x460\n ring_buffer_lock_reserve+0x12a/0x3f0\n trace_buffer_lock_reserve+0x10/0x50\n __trace_graph_return+0x1f/0x80\n trace_graph_return+0xb7/0xf0\n ? trace_clock_global+0x91/0xa0\n ftrace_return_to_handler+0x8b/0xf0\n ? pv_hash+0xa0/0xa0\n return_to_handler+0x15/0x30\n ? ftrace_graph_caller+0xa0/0xa0\n ? trace_clock_global+0x91/0xa0\n ? __rb_reserve_next+0x237/0x460\n ? ring_buffer_lock_reserve+0x12a/0x3f0\n ? trace_event_buffer_lock_reserve+0x3c/0x120\n ? trace_event_buffer_reserve+0x6b/0xc0\n ? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0\n ? dpm_run_callback+0x3b/0xc0\n ? pm_ops_is_empty+0x50/0x50\n ? platform_get_irq_byname_optional+0x90/0x90\n ? trace_device_pm_callback_start+0x82/0xd0\n ? dpm_run_callback+0x49/0xc0\n\nWith the following RIP:\n\nRIP: 0010:native_queued_spin_lock_slowpath+0x69/0x200\n\nSince the fix to the recursion detection would allow a single recursion to\nhappen while tracing, this lead to the trace_clock_global() taking a spin\nlock and then trying to take it again:\n\nring_buffer_lock_reserve() {\n trace_clock_global() {\n arch_spin_lock() {\n queued_spin_lock_slowpath() {\n /* lock taken */\n (something else gets traced by function graph tracer)\n ring_buffer_lock_reserve() {\n trace_clock_global() {\n arch_spin_lock() {\n queued_spin_lock_slowpath() {\n /* DEAD LOCK! */\n\nTracing should *never* block, as it can lead to strange lockups like the\nabove.\n\nRestructure the trace_clock_global() code to instead of simply taking a\nlock to update the recorded \"prev_time\" simply use it, as two events\nhappening on two different CPUs that calls this at the same time, really\ndoesn\u0027t matter which one goes first. Use a trylock to grab the lock for\nupdating the prev_time, and if it fails, simply try again the next time.\nIf it failed to be taken, that means something else is already updating\nit.\n\n\nBugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761",
"id": "GSD-2021-46939",
"modified": "2024-02-26T06:03:52.286280Z",
"schema_version": "1.4.0"
}
},
"namespaces": {
"cve.org": {
"CVE_data_meta": {
"ASSIGNER": "cve@kernel.org",
"ID": "CVE-2021-46939",
"STATE": "PUBLIC"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "Linux",
"version": {
"version_data": [
{
"version_affected": "\u003c",
"version_name": "14131f2f98ac",
"version_value": "91ca6f6a91f6"
},
{
"version_value": "not down converted",
"x_cve_json_5_version_data": {
"defaultStatus": "affected",
"versions": [
{
"status": "affected",
"version": "2.6.30"
},
{
"lessThan": "2.6.30",
"status": "unaffected",
"version": "0",
"versionType": "custom"
},
{
"lessThanOrEqual": "4.4.*",
"status": "unaffected",
"version": "4.4.269",
"versionType": "custom"
},
{
"lessThanOrEqual": "4.9.*",
"status": "unaffected",
"version": "4.9.269",
"versionType": "custom"
},
{
"lessThanOrEqual": "4.14.*",
"status": "unaffected",
"version": "4.14.233",
"versionType": "custom"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.191",
"versionType": "custom"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.118",
"versionType": "custom"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.36",
"versionType": "custom"
},
{
"lessThanOrEqual": "5.11.*",
"status": "unaffected",
"version": "5.11.20",
"versionType": "custom"
},
{
"lessThanOrEqual": "5.12.*",
"status": "unaffected",
"version": "5.12.3",
"versionType": "custom"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "5.13",
"versionType": "original_commit_for_fix"
}
]
}
}
]
}
}
]
},
"vendor_name": "Linux"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Restructure trace_clock_global() to never block\n\nIt was reported that a fix to the ring buffer recursion detection would\ncause a hung machine when performing suspend / resume testing. The\nfollowing backtrace was extracted from debugging that case:\n\nCall Trace:\n trace_clock_global+0x91/0xa0\n __rb_reserve_next+0x237/0x460\n ring_buffer_lock_reserve+0x12a/0x3f0\n trace_buffer_lock_reserve+0x10/0x50\n __trace_graph_return+0x1f/0x80\n trace_graph_return+0xb7/0xf0\n ? trace_clock_global+0x91/0xa0\n ftrace_return_to_handler+0x8b/0xf0\n ? pv_hash+0xa0/0xa0\n return_to_handler+0x15/0x30\n ? ftrace_graph_caller+0xa0/0xa0\n ? trace_clock_global+0x91/0xa0\n ? __rb_reserve_next+0x237/0x460\n ? ring_buffer_lock_reserve+0x12a/0x3f0\n ? trace_event_buffer_lock_reserve+0x3c/0x120\n ? trace_event_buffer_reserve+0x6b/0xc0\n ? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0\n ? dpm_run_callback+0x3b/0xc0\n ? pm_ops_is_empty+0x50/0x50\n ? platform_get_irq_byname_optional+0x90/0x90\n ? trace_device_pm_callback_start+0x82/0xd0\n ? dpm_run_callback+0x49/0xc0\n\nWith the following RIP:\n\nRIP: 0010:native_queued_spin_lock_slowpath+0x69/0x200\n\nSince the fix to the recursion detection would allow a single recursion to\nhappen while tracing, this lead to the trace_clock_global() taking a spin\nlock and then trying to take it again:\n\nring_buffer_lock_reserve() {\n trace_clock_global() {\n arch_spin_lock() {\n queued_spin_lock_slowpath() {\n /* lock taken */\n (something else gets traced by function graph tracer)\n ring_buffer_lock_reserve() {\n trace_clock_global() {\n arch_spin_lock() {\n queued_spin_lock_slowpath() {\n /* DEAD LOCK! */\n\nTracing should *never* block, as it can lead to strange lockups like the\nabove.\n\nRestructure the trace_clock_global() code to instead of simply taking a\nlock to update the recorded \"prev_time\" simply use it, as two events\nhappening on two different CPUs that calls this at the same time, really\ndoesn\u0027t matter which one goes first. Use a trylock to grab the lock for\nupdating the prev_time, and if it fails, simply try again the next time.\nIf it failed to be taken, that means something else is already updating\nit.\n\n\nBugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761"
}
]
},
"generator": {
"engine": "bippy-1e70cc10feda"
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "n/a"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://git.kernel.org/stable/c/91ca6f6a91f679c8645d7f3307e03ce86ad518c4",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/91ca6f6a91f679c8645d7f3307e03ce86ad518c4"
},
{
"name": "https://git.kernel.org/stable/c/859b47a43f5a0e5b9a92b621dc6ceaad39fb5c8b",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/859b47a43f5a0e5b9a92b621dc6ceaad39fb5c8b"
},
{
"name": "https://git.kernel.org/stable/c/1fca00920327be96f3318224f502e4d5460f9545",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/1fca00920327be96f3318224f502e4d5460f9545"
},
{
"name": "https://git.kernel.org/stable/c/d43d56dbf452ccecc1ec735cd4b6840118005d7c",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/d43d56dbf452ccecc1ec735cd4b6840118005d7c"
},
{
"name": "https://git.kernel.org/stable/c/c64da3294a7d59a4bf6874c664c13be892f15f44",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/c64da3294a7d59a4bf6874c664c13be892f15f44"
},
{
"name": "https://git.kernel.org/stable/c/a33614d52e97fc8077eb0b292189ca7d964cc534",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/a33614d52e97fc8077eb0b292189ca7d964cc534"
},
{
"name": "https://git.kernel.org/stable/c/6e2418576228eeb12e7ba82edb8f9500623942ff",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/6e2418576228eeb12e7ba82edb8f9500623942ff"
},
{
"name": "https://git.kernel.org/stable/c/2a1bd74b8186d7938bf004f5603f25b84785f63e",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/2a1bd74b8186d7938bf004f5603f25b84785f63e"
},
{
"name": "https://git.kernel.org/stable/c/aafe104aa9096827a429bc1358f8260ee565b7cc",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/aafe104aa9096827a429bc1358f8260ee565b7cc"
}
]
}
},
"nvd.nist.gov": {
"cve": {
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "08CFB593-6583-4E68-8BFB-9326D7B17183",
"versionEndExcluding": "4.4.269",
"versionStartIncluding": "2.6.30",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "8413F613-F1EE-430D-9972-52EEF6C49672",
"versionEndExcluding": "4.9.269",
"versionStartIncluding": "4.5.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "20505383-2EB8-41EF-A91B-F185B4FB81DF",
"versionEndExcluding": "4.14.233",
"versionStartIncluding": "4.10.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "B7281E1E-A00B-49C0-A849-9CE1CE780227",
"versionEndExcluding": "4.19.191",
"versionStartIncluding": "4.15.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "5670AEA3-082C-42D6-A067-CD9ECED4B84B",
"versionEndExcluding": "5.4.118",
"versionStartIncluding": "4.20.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "C7148769-B830-4B8F-986F-E0C85A19FC7F",
"versionEndExcluding": "5.10.36",
"versionStartIncluding": "5.5.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "EFB425F0-C28C-4B44-8B4C-AD512AA832DE",
"versionEndExcluding": "5.11.20",
"versionStartIncluding": "5.11.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "C3814FA3-8141-4313-A852-8C4212BE12AD",
"versionEndExcluding": "5.12.3",
"versionStartIncluding": "5.12.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Restructure trace_clock_global() to never block\n\nIt was reported that a fix to the ring buffer recursion detection would\ncause a hung machine when performing suspend / resume testing. The\nfollowing backtrace was extracted from debugging that case:\n\nCall Trace:\n trace_clock_global+0x91/0xa0\n __rb_reserve_next+0x237/0x460\n ring_buffer_lock_reserve+0x12a/0x3f0\n trace_buffer_lock_reserve+0x10/0x50\n __trace_graph_return+0x1f/0x80\n trace_graph_return+0xb7/0xf0\n ? trace_clock_global+0x91/0xa0\n ftrace_return_to_handler+0x8b/0xf0\n ? pv_hash+0xa0/0xa0\n return_to_handler+0x15/0x30\n ? ftrace_graph_caller+0xa0/0xa0\n ? trace_clock_global+0x91/0xa0\n ? __rb_reserve_next+0x237/0x460\n ? ring_buffer_lock_reserve+0x12a/0x3f0\n ? trace_event_buffer_lock_reserve+0x3c/0x120\n ? trace_event_buffer_reserve+0x6b/0xc0\n ? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0\n ? dpm_run_callback+0x3b/0xc0\n ? pm_ops_is_empty+0x50/0x50\n ? platform_get_irq_byname_optional+0x90/0x90\n ? trace_device_pm_callback_start+0x82/0xd0\n ? dpm_run_callback+0x49/0xc0\n\nWith the following RIP:\n\nRIP: 0010:native_queued_spin_lock_slowpath+0x69/0x200\n\nSince the fix to the recursion detection would allow a single recursion to\nhappen while tracing, this lead to the trace_clock_global() taking a spin\nlock and then trying to take it again:\n\nring_buffer_lock_reserve() {\n trace_clock_global() {\n arch_spin_lock() {\n queued_spin_lock_slowpath() {\n /* lock taken */\n (something else gets traced by function graph tracer)\n ring_buffer_lock_reserve() {\n trace_clock_global() {\n arch_spin_lock() {\n queued_spin_lock_slowpath() {\n /* DEAD LOCK! */\n\nTracing should *never* block, as it can lead to strange lockups like the\nabove.\n\nRestructure the trace_clock_global() code to instead of simply taking a\nlock to update the recorded \"prev_time\" simply use it, as two events\nhappening on two different CPUs that calls this at the same time, really\ndoesn\u0027t matter which one goes first. Use a trylock to grab the lock for\nupdating the prev_time, and if it fails, simply try again the next time.\nIf it failed to be taken, that means something else is already updating\nit.\n\n\nBugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo: reestructurar trace_clock_global() para no bloquear nunca. Se inform\u00f3 que una soluci\u00f3n a la detecci\u00f3n de recursividad del b\u00fafer circular provocar\u00eda que la m\u00e1quina se bloqueara al realizar pruebas de suspensi\u00f3n/reanudaci\u00f3n. El siguiente seguimiento se extrajo de la depuraci\u00f3n de ese caso: Call Trace: trace_clock_global+0x91/0xa0 __rb_reserve_next+0x237/0x460 ring_buffer_lock_reserve+0x12a/0x3f0 trace_buffer_lock_reserve+0x10/0x50 __trace_graph_return+0x1f/0x80 trace_graph_return+0xb7 /0xf0? trace_clock_global+0x91/0xa0 ftrace_return_to_handler+0x8b/0xf0 ? pv_hash+0xa0/0xa0 return_to_handler+0x15/0x30 ? ftrace_graph_caller+0xa0/0xa0? trace_clock_global+0x91/0xa0? __rb_reserve_next+0x237/0x460? ring_buffer_lock_reserve+0x12a/0x3f0? trace_event_buffer_lock_reserve+0x3c/0x120? trace_event_buffer_reserve+0x6b/0xc0? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0? dpm_run_callback+0x3b/0xc0? pm_ops_is_empty+0x50/0x50? platform_get_irq_byname_opcional+0x90/0x90? trace_device_pm_callback_start+0x82/0xd0? dpm_run_callback+0x49/0xc0 Con el siguiente RIP: RIP: 0010:native_queued_spin_lock_slowpath+0x69/0x200 Dado que la soluci\u00f3n a la detecci\u00f3n de recursi\u00f3n permitir\u00eda que ocurriera una sola recursi\u00f3n durante el seguimiento, esto llev\u00f3 a trace_clock_global() a tomar un bloqueo de giro y luego intentarlo para tomarlo de nuevo: ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { /* bloqueo tomado */ (algo m\u00e1s es rastreado por la funci\u00f3n de seguimiento del gr\u00e1fico) ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath () { /* \u00a1BLOQUEO MUERTO! */ El rastreo *nunca* debe bloquearse, ya que puede provocar bloqueos extra\u00f1os como el anterior. Reestructura el c\u00f3digo trace_clock_global() para que, en lugar de simplemente tomar un bloqueo para actualizar el \"prev_time\" registrado, simplemente lo uses, ya que dos eventos suceden en dos CPU diferentes que llaman a esto al mismo tiempo, realmente no importa cu\u00e1l va primero. Utilice un trylock para obtener el bloqueo para actualizar prev_time y, si falla, simplemente int\u00e9ntelo de nuevo la pr\u00f3xima vez. Si no se pudo tomar, eso significa que algo m\u00e1s ya lo est\u00e1 actualizando. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761"
}
],
"id": "CVE-2021-46939",
"lastModified": "2024-04-10T19:49:03.580",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"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"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
}
]
},
"published": "2024-02-27T19:04:05.873",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/1fca00920327be96f3318224f502e4d5460f9545"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/2a1bd74b8186d7938bf004f5603f25b84785f63e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/6e2418576228eeb12e7ba82edb8f9500623942ff"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/859b47a43f5a0e5b9a92b621dc6ceaad39fb5c8b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/91ca6f6a91f679c8645d7f3307e03ce86ad518c4"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a33614d52e97fc8077eb0b292189ca7d964cc534"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/aafe104aa9096827a429bc1358f8260ee565b7cc"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/c64da3294a7d59a4bf6874c664c13be892f15f44"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/d43d56dbf452ccecc1ec735cd4b6840118005d7c"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-662"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
}
}
}
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.