cve-2021-47041
Vulnerability from cvelistv5
Published
2024-02-28 08:13
Modified
2024-11-04 11:58
Severity ?
EPSS score ?
Summary
nvmet-tcp: fix incorrect locking in state_change sk callback
References
{ "containers": { "adp": [ { "metrics": [ { "other": { "content": { "id": "CVE-2021-47041", "options": [ { "Exploitation": "none" }, { "Automatable": "no" }, { "Technical Impact": "partial" } ], "role": "CISA Coordinator", "timestamp": "2024-02-28T20:52:02.308204Z", "version": "2.0.3" }, "type": "ssvc" } } ], "providerMetadata": { "dateUpdated": "2024-06-04T17:14:31.732Z", "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP" }, "title": "CISA ADP Vulnrichment" }, { "providerMetadata": { "dateUpdated": "2024-08-04T05:24:39.551Z", "orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE" }, "references": [ { "tags": [ "x_transferred" ], "url": "https://git.kernel.org/stable/c/999d606a820c36ae9b9e9611360c8b3d8d4bb777" }, { "tags": [ "x_transferred" ], "url": "https://git.kernel.org/stable/c/60ade0d56b06537a28884745059b3801c78e03bc" }, { "tags": [ "x_transferred" ], "url": "https://git.kernel.org/stable/c/06beaa1a9f6e501213195e47c30416032fd2bbd5" }, { "tags": [ "x_transferred" ], "url": "https://git.kernel.org/stable/c/906c538340dde6d891df89fe7dac8eaa724e40da" }, { "tags": [ "x_transferred" ], "url": "https://git.kernel.org/stable/c/b5332a9f3f3d884a1b646ce155e664cc558c1722" } ], "title": "CVE Program Container" } ], "cna": { "affected": [ { "defaultStatus": "unaffected", "product": "Linux", "programFiles": [ "drivers/nvme/target/tcp.c" ], "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "versions": [ { "lessThan": "999d606a820c", "status": "affected", "version": "872d26a391da", "versionType": "git" }, { "lessThan": "60ade0d56b06", "status": "affected", "version": "872d26a391da", "versionType": "git" }, { "lessThan": "06beaa1a9f6e", "status": "affected", "version": "872d26a391da", "versionType": "git" }, { "lessThan": "906c538340dd", "status": "affected", "version": "872d26a391da", "versionType": "git" }, { "lessThan": "b5332a9f3f3d", "status": "affected", "version": "872d26a391da", "versionType": "git" } ] }, { "defaultStatus": "affected", "product": "Linux", "programFiles": [ "drivers/nvme/target/tcp.c" ], "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "versions": [ { "status": "affected", "version": "5.0" }, { "lessThan": "5.0", "status": "unaffected", "version": "0", "versionType": "semver" }, { "lessThanOrEqual": "5.4.*", "status": "unaffected", "version": "5.4.119", "versionType": "semver" }, { "lessThanOrEqual": "5.10.*", "status": "unaffected", "version": "5.10.37", "versionType": "semver" }, { "lessThanOrEqual": "5.11.*", "status": "unaffected", "version": "5.11.21", "versionType": "semver" }, { "lessThanOrEqual": "5.12.*", "status": "unaffected", "version": "5.12.4", "versionType": "semver" }, { "lessThanOrEqual": "*", "status": "unaffected", "version": "5.13", "versionType": "original_commit_for_fix" } ] } ], "descriptions": [ { "lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-tcp: fix incorrect locking in state_change sk callback\n\nWe are not changing anything in the TCP connection state so\nwe should not take a write_lock but rather a read lock.\n\nThis caused a deadlock when running nvmet-tcp and nvme-tcp\non the same system, where state_change callbacks on the\nhost and on the controller side have causal relationship\nand made lockdep report on this with blktests:\n\n================================\nWARNING: inconsistent lock state\n5.12.0-rc3 #1 Tainted: G I\n--------------------------------\ninconsistent {IN-SOFTIRQ-W} -\u003e {SOFTIRQ-ON-R} usage.\nnvme/1324 [HC0[0]:SC0[0]:HE1:SE1] takes:\nffff888363151000 (clock-AF_INET){++-?}-{2:2}, at: nvme_tcp_state_change+0x21/0x150 [nvme_tcp]\n{IN-SOFTIRQ-W} state was registered at:\n __lock_acquire+0x79b/0x18d0\n lock_acquire+0x1ca/0x480\n _raw_write_lock_bh+0x39/0x80\n nvmet_tcp_state_change+0x21/0x170 [nvmet_tcp]\n tcp_fin+0x2a8/0x780\n tcp_data_queue+0xf94/0x1f20\n tcp_rcv_established+0x6ba/0x1f00\n tcp_v4_do_rcv+0x502/0x760\n tcp_v4_rcv+0x257e/0x3430\n ip_protocol_deliver_rcu+0x69/0x6a0\n ip_local_deliver_finish+0x1e2/0x2f0\n ip_local_deliver+0x1a2/0x420\n ip_rcv+0x4fb/0x6b0\n __netif_receive_skb_one_core+0x162/0x1b0\n process_backlog+0x1ff/0x770\n __napi_poll.constprop.0+0xa9/0x5c0\n net_rx_action+0x7b3/0xb30\n __do_softirq+0x1f0/0x940\n do_softirq+0xa1/0xd0\n __local_bh_enable_ip+0xd8/0x100\n ip_finish_output2+0x6b7/0x18a0\n __ip_queue_xmit+0x706/0x1aa0\n __tcp_transmit_skb+0x2068/0x2e20\n tcp_write_xmit+0xc9e/0x2bb0\n __tcp_push_pending_frames+0x92/0x310\n inet_shutdown+0x158/0x300\n __nvme_tcp_stop_queue+0x36/0x270 [nvme_tcp]\n nvme_tcp_stop_queue+0x87/0xb0 [nvme_tcp]\n nvme_tcp_teardown_admin_queue+0x69/0xe0 [nvme_tcp]\n nvme_do_delete_ctrl+0x100/0x10c [nvme_core]\n nvme_sysfs_delete.cold+0x8/0xd [nvme_core]\n kernfs_fop_write_iter+0x2c7/0x460\n new_sync_write+0x36c/0x610\n vfs_write+0x5c0/0x870\n ksys_write+0xf9/0x1d0\n do_syscall_64+0x33/0x40\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nirq event stamp: 10687\nhardirqs last enabled at (10687): [\u003cffffffff9ec376bd\u003e] _raw_spin_unlock_irqrestore+0x2d/0x40\nhardirqs last disabled at (10686): [\u003cffffffff9ec374d8\u003e] _raw_spin_lock_irqsave+0x68/0x90\nsoftirqs last enabled at (10684): [\u003cffffffff9f000608\u003e] __do_softirq+0x608/0x940\nsoftirqs last disabled at (10649): [\u003cffffffff9cdedd31\u003e] do_softirq+0xa1/0xd0\n\nother info that might help us debug this:\n Possible unsafe locking scenario:\n\n CPU0\n ----\n lock(clock-AF_INET);\n \u003cInterrupt\u003e\n lock(clock-AF_INET);\n\n *** DEADLOCK ***\n\n5 locks held by nvme/1324:\n #0: ffff8884a01fe470 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xf9/0x1d0\n #1: ffff8886e435c090 (\u0026of-\u003emutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x216/0x460\n #2: ffff888104d90c38 (kn-\u003eactive#255){++++}-{0:0}, at: kernfs_remove_self+0x22d/0x330\n #3: ffff8884634538d0 (\u0026queue-\u003equeue_lock){+.+.}-{3:3}, at: nvme_tcp_stop_queue+0x52/0xb0 [nvme_tcp]\n #4: ffff888363150d30 (sk_lock-AF_INET){+.+.}-{0:0}, at: inet_shutdown+0x59/0x300\n\nstack backtrace:\nCPU: 26 PID: 1324 Comm: nvme Tainted: G I 5.12.0-rc3 #1\nHardware name: Dell Inc. PowerEdge R640/06NR82, BIOS 2.10.0 11/12/2020\nCall Trace:\n dump_stack+0x93/0xc2\n mark_lock_irq.cold+0x2c/0xb3\n ? verify_lock_unused+0x390/0x390\n ? stack_trace_consume_entry+0x160/0x160\n ? lock_downgrade+0x100/0x100\n ? save_trace+0x88/0x5e0\n ? _raw_spin_unlock_irqrestore+0x2d/0x40\n mark_lock+0x530/0x1470\n ? mark_lock_irq+0x1d10/0x1d10\n ? enqueue_timer+0x660/0x660\n mark_usage+0x215/0x2a0\n __lock_acquire+0x79b/0x18d0\n ? tcp_schedule_loss_probe.part.0+0x38c/0x520\n lock_acquire+0x1ca/0x480\n ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp]\n ? rcu_read_unlock+0x40/0x40\n ? tcp_mtu_probe+0x1ae0/0x1ae0\n ? kmalloc_reserve+0xa0/0xa0\n ? sysfs_file_ops+0x170/0x170\n _raw_read_lock+0x3d/0xa0\n ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp]\n nvme_tcp_state_change+0x21/0x150 [nvme_tcp]\n ? sysfs_file_ops\n---truncated---" } ], "providerMetadata": { "dateUpdated": "2024-11-04T11:58:16.709Z", "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux" }, "references": [ { "url": "https://git.kernel.org/stable/c/999d606a820c36ae9b9e9611360c8b3d8d4bb777" }, { "url": "https://git.kernel.org/stable/c/60ade0d56b06537a28884745059b3801c78e03bc" }, { "url": "https://git.kernel.org/stable/c/06beaa1a9f6e501213195e47c30416032fd2bbd5" }, { "url": "https://git.kernel.org/stable/c/906c538340dde6d891df89fe7dac8eaa724e40da" }, { "url": "https://git.kernel.org/stable/c/b5332a9f3f3d884a1b646ce155e664cc558c1722" } ], "title": "nvmet-tcp: fix incorrect locking in state_change sk callback", "x_generator": { "engine": "bippy-9e1c9544281a" } } }, "cveMetadata": { "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "assignerShortName": "Linux", "cveId": "CVE-2021-47041", "datePublished": "2024-02-28T08:13:47.182Z", "dateReserved": "2024-02-27T18:42:55.968Z", "dateUpdated": "2024-11-04T11:58:16.709Z", "state": "PUBLISHED" }, "dataType": "CVE_RECORD", "dataVersion": "5.1", "meta": { "nvd": "{\"cve\":{\"id\":\"CVE-2021-47041\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-02-28T09:15:40.037\",\"lastModified\":\"2024-02-28T14:06:45.783\",\"vulnStatus\":\"Awaiting Analysis\",\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nnvmet-tcp: fix incorrect locking in state_change sk callback\\n\\nWe are not changing anything in the TCP connection state so\\nwe should not take a write_lock but rather a read lock.\\n\\nThis caused a deadlock when running nvmet-tcp and nvme-tcp\\non the same system, where state_change callbacks on the\\nhost and on the controller side have causal relationship\\nand made lockdep report on this with blktests:\\n\\n================================\\nWARNING: inconsistent lock state\\n5.12.0-rc3 #1 Tainted: G I\\n--------------------------------\\ninconsistent {IN-SOFTIRQ-W} -\u003e {SOFTIRQ-ON-R} usage.\\nnvme/1324 [HC0[0]:SC0[0]:HE1:SE1] takes:\\nffff888363151000 (clock-AF_INET){++-?}-{2:2}, at: nvme_tcp_state_change+0x21/0x150 [nvme_tcp]\\n{IN-SOFTIRQ-W} state was registered at:\\n __lock_acquire+0x79b/0x18d0\\n lock_acquire+0x1ca/0x480\\n _raw_write_lock_bh+0x39/0x80\\n nvmet_tcp_state_change+0x21/0x170 [nvmet_tcp]\\n tcp_fin+0x2a8/0x780\\n tcp_data_queue+0xf94/0x1f20\\n tcp_rcv_established+0x6ba/0x1f00\\n tcp_v4_do_rcv+0x502/0x760\\n tcp_v4_rcv+0x257e/0x3430\\n ip_protocol_deliver_rcu+0x69/0x6a0\\n ip_local_deliver_finish+0x1e2/0x2f0\\n ip_local_deliver+0x1a2/0x420\\n ip_rcv+0x4fb/0x6b0\\n __netif_receive_skb_one_core+0x162/0x1b0\\n process_backlog+0x1ff/0x770\\n __napi_poll.constprop.0+0xa9/0x5c0\\n net_rx_action+0x7b3/0xb30\\n __do_softirq+0x1f0/0x940\\n do_softirq+0xa1/0xd0\\n __local_bh_enable_ip+0xd8/0x100\\n ip_finish_output2+0x6b7/0x18a0\\n __ip_queue_xmit+0x706/0x1aa0\\n __tcp_transmit_skb+0x2068/0x2e20\\n tcp_write_xmit+0xc9e/0x2bb0\\n __tcp_push_pending_frames+0x92/0x310\\n inet_shutdown+0x158/0x300\\n __nvme_tcp_stop_queue+0x36/0x270 [nvme_tcp]\\n nvme_tcp_stop_queue+0x87/0xb0 [nvme_tcp]\\n nvme_tcp_teardown_admin_queue+0x69/0xe0 [nvme_tcp]\\n nvme_do_delete_ctrl+0x100/0x10c [nvme_core]\\n nvme_sysfs_delete.cold+0x8/0xd [nvme_core]\\n kernfs_fop_write_iter+0x2c7/0x460\\n new_sync_write+0x36c/0x610\\n vfs_write+0x5c0/0x870\\n ksys_write+0xf9/0x1d0\\n do_syscall_64+0x33/0x40\\n entry_SYSCALL_64_after_hwframe+0x44/0xae\\nirq event stamp: 10687\\nhardirqs last enabled at (10687): [\u003cffffffff9ec376bd\u003e] _raw_spin_unlock_irqrestore+0x2d/0x40\\nhardirqs last disabled at (10686): [\u003cffffffff9ec374d8\u003e] _raw_spin_lock_irqsave+0x68/0x90\\nsoftirqs last enabled at (10684): [\u003cffffffff9f000608\u003e] __do_softirq+0x608/0x940\\nsoftirqs last disabled at (10649): [\u003cffffffff9cdedd31\u003e] do_softirq+0xa1/0xd0\\n\\nother info that might help us debug this:\\n Possible unsafe locking scenario:\\n\\n CPU0\\n ----\\n lock(clock-AF_INET);\\n \u003cInterrupt\u003e\\n lock(clock-AF_INET);\\n\\n *** DEADLOCK ***\\n\\n5 locks held by nvme/1324:\\n #0: ffff8884a01fe470 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xf9/0x1d0\\n #1: ffff8886e435c090 (\u0026of-\u003emutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x216/0x460\\n #2: ffff888104d90c38 (kn-\u003eactive#255){++++}-{0:0}, at: kernfs_remove_self+0x22d/0x330\\n #3: ffff8884634538d0 (\u0026queue-\u003equeue_lock){+.+.}-{3:3}, at: nvme_tcp_stop_queue+0x52/0xb0 [nvme_tcp]\\n #4: ffff888363150d30 (sk_lock-AF_INET){+.+.}-{0:0}, at: inet_shutdown+0x59/0x300\\n\\nstack backtrace:\\nCPU: 26 PID: 1324 Comm: nvme Tainted: G I 5.12.0-rc3 #1\\nHardware name: Dell Inc. PowerEdge R640/06NR82, BIOS 2.10.0 11/12/2020\\nCall Trace:\\n dump_stack+0x93/0xc2\\n mark_lock_irq.cold+0x2c/0xb3\\n ? verify_lock_unused+0x390/0x390\\n ? stack_trace_consume_entry+0x160/0x160\\n ? lock_downgrade+0x100/0x100\\n ? save_trace+0x88/0x5e0\\n ? _raw_spin_unlock_irqrestore+0x2d/0x40\\n mark_lock+0x530/0x1470\\n ? mark_lock_irq+0x1d10/0x1d10\\n ? enqueue_timer+0x660/0x660\\n mark_usage+0x215/0x2a0\\n __lock_acquire+0x79b/0x18d0\\n ? tcp_schedule_loss_probe.part.0+0x38c/0x520\\n lock_acquire+0x1ca/0x480\\n ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp]\\n ? rcu_read_unlock+0x40/0x40\\n ? tcp_mtu_probe+0x1ae0/0x1ae0\\n ? kmalloc_reserve+0xa0/0xa0\\n ? sysfs_file_ops+0x170/0x170\\n _raw_read_lock+0x3d/0xa0\\n ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp]\\n nvme_tcp_state_change+0x21/0x150 [nvme_tcp]\\n ? sysfs_file_ops\\n---truncated---\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvmet-tcp: corrige el bloqueo incorrecto en la devoluci\u00f3n de llamada de state_change sk No estamos cambiando nada en el estado de la conexi\u00f3n TCP, por lo que no debemos tomar un bloqueo de escritura sino un bloqueo de lectura. Esto caus\u00f3 un punto muerto al ejecutar nvmet-tcp y nvme-tcp en el mismo sistema, donde las devoluciones de llamada state_change en el host y en el lado del controlador tienen una relaci\u00f3n causal y generaron un informe de lockdep sobre esto con blktests: ========= ======================= ADVERTENCIA: estado de bloqueo inconsistente 5.12.0-rc3 #1 Contaminado: GI ------------ -------------------- uso inconsistente de {IN-SOFTIRQ-W} -\u0026gt; {SOFTIRQ-ON-R}. nvme/1324 [HC0[0]:SC0[0]:HE1:SE1] toma: ffff888363151000 (reloj-AF_INET){++-?}-{2:2}, en: nvme_tcp_state_change+0x21/0x150 [nvme_tcp] { IN-SOFTIRQ-W} el estado se registr\u00f3 en: __lock_acquire+0x79b/0x18d0 lock_acquire+0x1ca/0x480 _raw_write_lock_bh+0x39/0x80 nvmet_tcp_state_change+0x21/0x170 [nvmet_tcp] tcp_fin+0x2a8/0x780 tcp_data_queue +0xf94/0x1f20 tcp_rcv_establecido+0x6ba/0x1f00 tcp_v4_do_rcv +0x502/0x760 tcp_v4_rcv+0x257e/0x3430 ip_protocol_deliver_rcu+0x69/0x6a0 ip_local_deliver_finish+0x1e2/0x2f0 ip_local_deliver+0x1a2/0x420 ip_rcv+0x4fb/0x6b0 __netif_receive _skb_one_core+0x162/0x1b0 proceso_backlog+0x1ff/0x770 __napi_poll.constprop.0+0xa9/0x5c0 net_rx_action+ 0x7b3/0xb30 __do_softirq+0x1f0/0x940 do_softirq+0xa1/0xd0 __local_bh_enable_ip+0xd8/0x100 ip_finish_output2+0x6b7/0x18a0 __ip_queue_xmit+0x706/0x1aa0 __tcp_transmit_skb+0 x2068/0x2e20 tcp_write_xmit+0xc9e/0x2bb0 __tcp_push_pending_frames+0x92/0x310 inet_shutdown+0x158/0x300 __nvme_tcp_stop_queue+ 0x36/0x270 [nvme_tcp] nvme_tcp_stop_queue+0x87/0xb0 [nvme_tcp] nvme_tcp_teardown_admin_queue+0x69/0xe0 [nvme_tcp] nvme_do_delete_ctrl+0x100/0x10c [nvme_core] nv me_sysfs_delete.cold+0x8/0xd [nvme_core] kernfs_fop_write_iter+0x2c7/0x460 new_sync_write+0x36c/0x610 vfs_write+0x5c0/0x870 ksys_write+0xf9/0x1d0 do_syscall_64+0x33/0x40 Entry_SYSCALL_64_after_hwframe+0x44/0xae Sello de evento irq: 10687 hardirqs habilitado por \u00faltima vez en (10687): [] _raw_spin_unlock _irqrestore+0x2d/0x40 hardirqs se deshabilit\u00f3 por \u00faltima vez en (10686) : [] _raw_spin_lock_irqsave+0x68/0x90 softirqs habilitado por \u00faltima vez en (10684): [] __do_softirq+0x608/0x940 softirqs deshabilitado por \u00faltima vez en (10649): [] do_softirq+0xa1 /0xd0 otra informaci\u00f3n que podr\u00eda ayudarnos a depurar esto: Posible escenario de bloqueo inseguro: CPU0 ---- lock(clock-AF_INET); bloqueo(reloj-AF_INET); *** DEADLOCK *** 5 bloqueos retenidos por nvme/1324: #0: ffff8884a01fe470 (sb_writers#4){.+.+}-{0:0}, en: ksys_write+0xf9/0x1d0 #1: ffff8886e435c090 (\u0026amp;of -\u0026gt;mutex){+.+.}-{3:3}, en: kernfs_fop_write_iter+0x216/0x460 #2: ffff888104d90c38 (kn-\u0026gt;active#255){++++}-{0:0}, en : kernfs_remove_self+0x22d/0x330 #3: ffff8884634538d0 (\u0026amp;queue-\u0026gt;queue_lock){+.+.}-{3:3}, en: nvme_tcp_stop_queue+0x52/0xb0 [nvme_tcp] #4: ffff888363150d30 (sk_lock-AF _INET){+ .+.}-{0:0}, en: inet_shutdown+0x59/0x300 seguimiento de pila: CPU: 26 PID: 1324 Comunicaciones: nvme Contaminado: GI 5.12.0-rc3 #1 Nombre de hardware: Dell Inc. PowerEdge R640/06NR82 , BIOS 2.10.0 12/11/2020 Seguimiento de llamadas: dump_stack+0x93/0xc2 mark_lock_irq.cold+0x2c/0xb3? verificar_lock_unused+0x390/0x390? stack_trace_consume_entry+0x160/0x160? lock_downgrade+0x100/0x100? save_trace+0x88/0x5e0? _raw_spin_unlock_irqrestore+0x2d/0x40 mark_lock+0x530/0x1470 ? mark_lock_irq+0x1d10/0x1d10? enqueue_timer+0x660/0x660 mark_usage+0x215/0x2a0 __lock_acquire+0x79b/0x18d0? tcp_schedule_loss_probe.part.0+0x38c/0x520 lock_acquire+0x1ca/0x480? nvme_tcp_state_change+0x21/0x150 [nvme_tcp] ? rcu_read_unlock+0x40/0x40? tcp_mtu_probe+0x1ae0/0x1ae0? kmalloc_reserve+0xa0/0xa0? sysfs_file_ops+0x170/0x170 _raw_read_lock+0x3d/0xa0 ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp] nvme_tcp_state_change+0x21/0x150 [nvme_tcp] ? sysfs_file_ops ---truncado---\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/06beaa1a9f6e501213195e47c30416032fd2bbd5\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/60ade0d56b06537a28884745059b3801c78e03bc\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/906c538340dde6d891df89fe7dac8eaa724e40da\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/999d606a820c36ae9b9e9611360c8b3d8d4bb777\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/b5332a9f3f3d884a1b646ce155e664cc558c1722\",\"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.