gsd-2024-26616
Vulnerability from gsd
Modified
2024-02-20 06:02
Details
In the Linux kernel, the following vulnerability has been resolved:
btrfs: scrub: avoid use-after-free when chunk length is not 64K aligned
[BUG]
There is a bug report that, on a ext4-converted btrfs, scrub leads to
various problems, including:
- "unable to find chunk map" errors
BTRFS info (device vdb): scrub: started on devid 1
BTRFS critical (device vdb): unable to find chunk map for logical 2214744064 length 4096
BTRFS critical (device vdb): unable to find chunk map for logical 2214744064 length 45056
This would lead to unrepariable errors.
- Use-after-free KASAN reports:
==================================================================
BUG: KASAN: slab-use-after-free in __blk_rq_map_sg+0x18f/0x7c0
Read of size 8 at addr ffff8881013c9040 by task btrfs/909
CPU: 0 PID: 909 Comm: btrfs Not tainted 6.7.0-x64v3-dbg #11 c50636e9419a8354555555245df535e380563b2b
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 2023.11-2 12/24/2023
Call Trace:
<TASK>
dump_stack_lvl+0x43/0x60
print_report+0xcf/0x640
kasan_report+0xa6/0xd0
__blk_rq_map_sg+0x18f/0x7c0
virtblk_prep_rq.isra.0+0x215/0x6a0 [virtio_blk 19a65eeee9ae6fcf02edfad39bb9ddee07dcdaff]
virtio_queue_rqs+0xc4/0x310 [virtio_blk 19a65eeee9ae6fcf02edfad39bb9ddee07dcdaff]
blk_mq_flush_plug_list.part.0+0x780/0x860
__blk_flush_plug+0x1ba/0x220
blk_finish_plug+0x3b/0x60
submit_initial_group_read+0x10a/0x290 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]
flush_scrub_stripes+0x38e/0x430 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]
scrub_stripe+0x82a/0xae0 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]
scrub_chunk+0x178/0x200 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]
scrub_enumerate_chunks+0x4bc/0xa30 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]
btrfs_scrub_dev+0x398/0x810 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]
btrfs_ioctl+0x4b9/0x3020 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]
__x64_sys_ioctl+0xbd/0x100
do_syscall_64+0x5d/0xe0
entry_SYSCALL_64_after_hwframe+0x63/0x6b
RIP: 0033:0x7f47e5e0952b
- Crash, mostly due to above use-after-free
[CAUSE]
The converted fs has the following data chunk layout:
item 2 key (FIRST_CHUNK_TREE CHUNK_ITEM 2214658048) itemoff 16025 itemsize 80
length 86016 owner 2 stripe_len 65536 type DATA|single
For above logical bytenr 2214744064, it's at the chunk end
(2214658048 + 86016 = 2214744064).
This means btrfs_submit_bio() would split the bio, and trigger endio
function for both of the two halves.
However scrub_submit_initial_read() would only expect the endio function
to be called once, not any more.
This means the first endio function would already free the bbio::bio,
leaving the bvec freed, thus the 2nd endio call would lead to
use-after-free.
[FIX]
- Make sure scrub_read_endio() only updates bits in its range
Since we may read less than 64K at the end of the chunk, we should not
touch the bits beyond chunk boundary.
- Make sure scrub_submit_initial_read() only to read the chunk range
This is done by calculating the real number of sectors we need to
read, and add sector-by-sector to the bio.
Thankfully the scrub read repair path won't need extra fixes:
- scrub_stripe_submit_repair_read()
With above fixes, we won't update error bit for range beyond chunk,
thus scrub_stripe_submit_repair_read() should never submit any read
beyond the chunk.
Aliases
{ "gsd": { "metadata": { "exploitCode": "unknown", "remediation": "unknown", "reportConfidence": "confirmed", "type": "vulnerability" }, "osvSchema": { "aliases": [ "CVE-2024-26616" ], "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: scrub: avoid use-after-free when chunk length is not 64K aligned\n\n[BUG]\nThere is a bug report that, on a ext4-converted btrfs, scrub leads to\nvarious problems, including:\n\n- \"unable to find chunk map\" errors\n BTRFS info (device vdb): scrub: started on devid 1\n BTRFS critical (device vdb): unable to find chunk map for logical 2214744064 length 4096\n BTRFS critical (device vdb): unable to find chunk map for logical 2214744064 length 45056\n\n This would lead to unrepariable errors.\n\n- Use-after-free KASAN reports:\n ==================================================================\n BUG: KASAN: slab-use-after-free in __blk_rq_map_sg+0x18f/0x7c0\n Read of size 8 at addr ffff8881013c9040 by task btrfs/909\n CPU: 0 PID: 909 Comm: btrfs Not tainted 6.7.0-x64v3-dbg #11 c50636e9419a8354555555245df535e380563b2b\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 2023.11-2 12/24/2023\n Call Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x43/0x60\n print_report+0xcf/0x640\n kasan_report+0xa6/0xd0\n __blk_rq_map_sg+0x18f/0x7c0\n virtblk_prep_rq.isra.0+0x215/0x6a0 [virtio_blk 19a65eeee9ae6fcf02edfad39bb9ddee07dcdaff]\n virtio_queue_rqs+0xc4/0x310 [virtio_blk 19a65eeee9ae6fcf02edfad39bb9ddee07dcdaff]\n blk_mq_flush_plug_list.part.0+0x780/0x860\n __blk_flush_plug+0x1ba/0x220\n blk_finish_plug+0x3b/0x60\n submit_initial_group_read+0x10a/0x290 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]\n flush_scrub_stripes+0x38e/0x430 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]\n scrub_stripe+0x82a/0xae0 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]\n scrub_chunk+0x178/0x200 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]\n scrub_enumerate_chunks+0x4bc/0xa30 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]\n btrfs_scrub_dev+0x398/0x810 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]\n btrfs_ioctl+0x4b9/0x3020 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]\n __x64_sys_ioctl+0xbd/0x100\n do_syscall_64+0x5d/0xe0\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\n RIP: 0033:0x7f47e5e0952b\n\n- Crash, mostly due to above use-after-free\n\n[CAUSE]\nThe converted fs has the following data chunk layout:\n\n item 2 key (FIRST_CHUNK_TREE CHUNK_ITEM 2214658048) itemoff 16025 itemsize 80\n length 86016 owner 2 stripe_len 65536 type DATA|single\n\nFor above logical bytenr 2214744064, it\u0027s at the chunk end\n(2214658048 + 86016 = 2214744064).\n\nThis means btrfs_submit_bio() would split the bio, and trigger endio\nfunction for both of the two halves.\n\nHowever scrub_submit_initial_read() would only expect the endio function\nto be called once, not any more.\nThis means the first endio function would already free the bbio::bio,\nleaving the bvec freed, thus the 2nd endio call would lead to\nuse-after-free.\n\n[FIX]\n- Make sure scrub_read_endio() only updates bits in its range\n Since we may read less than 64K at the end of the chunk, we should not\n touch the bits beyond chunk boundary.\n\n- Make sure scrub_submit_initial_read() only to read the chunk range\n This is done by calculating the real number of sectors we need to\n read, and add sector-by-sector to the bio.\n\nThankfully the scrub read repair path won\u0027t need extra fixes:\n\n- scrub_stripe_submit_repair_read()\n With above fixes, we won\u0027t update error bit for range beyond chunk,\n thus scrub_stripe_submit_repair_read() should never submit any read\n beyond the chunk.", "id": "GSD-2024-26616", "modified": "2024-02-20T06:02:29.128460Z", "schema_version": "1.4.0" } }, "namespaces": { "cve.org": { "CVE_data_meta": { "ASSIGNER": "cve@kernel.org", "ID": "CVE-2024-26616", "STATE": "PUBLIC" }, "affects": { "vendor": { "vendor_data": [ { "product": { "product_data": [ { "product_name": "Linux", "version": { "version_data": [ { "version_affected": "\u003c", "version_name": "e02ee89baa66", "version_value": "642b9c520ef2" }, { "version_value": "not down converted", "x_cve_json_5_version_data": { "defaultStatus": "affected", "versions": [ { "status": "affected", "version": "6.4" }, { "lessThan": "6.4", "status": "unaffected", "version": "0", "versionType": "custom" }, { "lessThanOrEqual": "6.6.*", "status": "unaffected", "version": "6.6.15", "versionType": "custom" }, { "lessThanOrEqual": "6.7.*", "status": "unaffected", "version": "6.7.3", "versionType": "custom" }, { "lessThanOrEqual": "*", "status": "unaffected", "version": "6.8", "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\nbtrfs: scrub: avoid use-after-free when chunk length is not 64K aligned\n\n[BUG]\nThere is a bug report that, on a ext4-converted btrfs, scrub leads to\nvarious problems, including:\n\n- \"unable to find chunk map\" errors\n BTRFS info (device vdb): scrub: started on devid 1\n BTRFS critical (device vdb): unable to find chunk map for logical 2214744064 length 4096\n BTRFS critical (device vdb): unable to find chunk map for logical 2214744064 length 45056\n\n This would lead to unrepariable errors.\n\n- Use-after-free KASAN reports:\n ==================================================================\n BUG: KASAN: slab-use-after-free in __blk_rq_map_sg+0x18f/0x7c0\n Read of size 8 at addr ffff8881013c9040 by task btrfs/909\n CPU: 0 PID: 909 Comm: btrfs Not tainted 6.7.0-x64v3-dbg #11 c50636e9419a8354555555245df535e380563b2b\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 2023.11-2 12/24/2023\n Call Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x43/0x60\n print_report+0xcf/0x640\n kasan_report+0xa6/0xd0\n __blk_rq_map_sg+0x18f/0x7c0\n virtblk_prep_rq.isra.0+0x215/0x6a0 [virtio_blk 19a65eeee9ae6fcf02edfad39bb9ddee07dcdaff]\n virtio_queue_rqs+0xc4/0x310 [virtio_blk 19a65eeee9ae6fcf02edfad39bb9ddee07dcdaff]\n blk_mq_flush_plug_list.part.0+0x780/0x860\n __blk_flush_plug+0x1ba/0x220\n blk_finish_plug+0x3b/0x60\n submit_initial_group_read+0x10a/0x290 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]\n flush_scrub_stripes+0x38e/0x430 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]\n scrub_stripe+0x82a/0xae0 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]\n scrub_chunk+0x178/0x200 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]\n scrub_enumerate_chunks+0x4bc/0xa30 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]\n btrfs_scrub_dev+0x398/0x810 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]\n btrfs_ioctl+0x4b9/0x3020 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]\n __x64_sys_ioctl+0xbd/0x100\n do_syscall_64+0x5d/0xe0\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\n RIP: 0033:0x7f47e5e0952b\n\n- Crash, mostly due to above use-after-free\n\n[CAUSE]\nThe converted fs has the following data chunk layout:\n\n item 2 key (FIRST_CHUNK_TREE CHUNK_ITEM 2214658048) itemoff 16025 itemsize 80\n length 86016 owner 2 stripe_len 65536 type DATA|single\n\nFor above logical bytenr 2214744064, it\u0027s at the chunk end\n(2214658048 + 86016 = 2214744064).\n\nThis means btrfs_submit_bio() would split the bio, and trigger endio\nfunction for both of the two halves.\n\nHowever scrub_submit_initial_read() would only expect the endio function\nto be called once, not any more.\nThis means the first endio function would already free the bbio::bio,\nleaving the bvec freed, thus the 2nd endio call would lead to\nuse-after-free.\n\n[FIX]\n- Make sure scrub_read_endio() only updates bits in its range\n Since we may read less than 64K at the end of the chunk, we should not\n touch the bits beyond chunk boundary.\n\n- Make sure scrub_submit_initial_read() only to read the chunk range\n This is done by calculating the real number of sectors we need to\n read, and add sector-by-sector to the bio.\n\nThankfully the scrub read repair path won\u0027t need extra fixes:\n\n- scrub_stripe_submit_repair_read()\n With above fixes, we won\u0027t update error bit for range beyond chunk,\n thus scrub_stripe_submit_repair_read() should never submit any read\n beyond the chunk." } ] }, "generator": { "engine": "bippy-8df59b4913de" }, "problemtype": { "problemtype_data": [ { "description": [ { "lang": "eng", "value": "n/a" } ] } ] }, "references": { "reference_data": [ { "name": "https://git.kernel.org/stable/c/642b9c520ef2f104277ad1f902f8526edbe087fb", "refsource": "MISC", "url": "https://git.kernel.org/stable/c/642b9c520ef2f104277ad1f902f8526edbe087fb" }, { "name": "https://git.kernel.org/stable/c/34de0f04684ec00c093a0455648be055f0e8e24f", "refsource": "MISC", "url": "https://git.kernel.org/stable/c/34de0f04684ec00c093a0455648be055f0e8e24f" }, { "name": "https://git.kernel.org/stable/c/f546c4282673497a06ecb6190b50ae7f6c85b02f", "refsource": "MISC", "url": "https://git.kernel.org/stable/c/f546c4282673497a06ecb6190b50ae7f6c85b02f" } ] } }, "nvd.nist.gov": { "cve": { "descriptions": [ { "lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: scrub: avoid use-after-free when chunk length is not 64K aligned\n\n[BUG]\nThere is a bug report that, on a ext4-converted btrfs, scrub leads to\nvarious problems, including:\n\n- \"unable to find chunk map\" errors\n BTRFS info (device vdb): scrub: started on devid 1\n BTRFS critical (device vdb): unable to find chunk map for logical 2214744064 length 4096\n BTRFS critical (device vdb): unable to find chunk map for logical 2214744064 length 45056\n\n This would lead to unrepariable errors.\n\n- Use-after-free KASAN reports:\n ==================================================================\n BUG: KASAN: slab-use-after-free in __blk_rq_map_sg+0x18f/0x7c0\n Read of size 8 at addr ffff8881013c9040 by task btrfs/909\n CPU: 0 PID: 909 Comm: btrfs Not tainted 6.7.0-x64v3-dbg #11 c50636e9419a8354555555245df535e380563b2b\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 2023.11-2 12/24/2023\n Call Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x43/0x60\n print_report+0xcf/0x640\n kasan_report+0xa6/0xd0\n __blk_rq_map_sg+0x18f/0x7c0\n virtblk_prep_rq.isra.0+0x215/0x6a0 [virtio_blk 19a65eeee9ae6fcf02edfad39bb9ddee07dcdaff]\n virtio_queue_rqs+0xc4/0x310 [virtio_blk 19a65eeee9ae6fcf02edfad39bb9ddee07dcdaff]\n blk_mq_flush_plug_list.part.0+0x780/0x860\n __blk_flush_plug+0x1ba/0x220\n blk_finish_plug+0x3b/0x60\n submit_initial_group_read+0x10a/0x290 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]\n flush_scrub_stripes+0x38e/0x430 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]\n scrub_stripe+0x82a/0xae0 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]\n scrub_chunk+0x178/0x200 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]\n scrub_enumerate_chunks+0x4bc/0xa30 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]\n btrfs_scrub_dev+0x398/0x810 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]\n btrfs_ioctl+0x4b9/0x3020 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]\n __x64_sys_ioctl+0xbd/0x100\n do_syscall_64+0x5d/0xe0\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\n RIP: 0033:0x7f47e5e0952b\n\n- Crash, mostly due to above use-after-free\n\n[CAUSE]\nThe converted fs has the following data chunk layout:\n\n item 2 key (FIRST_CHUNK_TREE CHUNK_ITEM 2214658048) itemoff 16025 itemsize 80\n length 86016 owner 2 stripe_len 65536 type DATA|single\n\nFor above logical bytenr 2214744064, it\u0027s at the chunk end\n(2214658048 + 86016 = 2214744064).\n\nThis means btrfs_submit_bio() would split the bio, and trigger endio\nfunction for both of the two halves.\n\nHowever scrub_submit_initial_read() would only expect the endio function\nto be called once, not any more.\nThis means the first endio function would already free the bbio::bio,\nleaving the bvec freed, thus the 2nd endio call would lead to\nuse-after-free.\n\n[FIX]\n- Make sure scrub_read_endio() only updates bits in its range\n Since we may read less than 64K at the end of the chunk, we should not\n touch the bits beyond chunk boundary.\n\n- Make sure scrub_submit_initial_read() only to read the chunk range\n This is done by calculating the real number of sectors we need to\n read, and add sector-by-sector to the bio.\n\nThankfully the scrub read repair path won\u0027t need extra fixes:\n\n- scrub_stripe_submit_repair_read()\n With above fixes, we won\u0027t update error bit for range beyond chunk,\n thus scrub_stripe_submit_repair_read() should never submit any read\n beyond the chunk." }, { "lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: limpieza: evita el use-after-free cuando la longitud del fragmento no est\u00e1 alineada con 64 K [ERROR] Hay un informe de error que indica que, en un btrfs convertido a ext4, la limpieza conduce a varios problemas, que incluyen: - Errores \"no se puede encontrar el mapa de fragmentos\" Informaci\u00f3n BTRFS (dispositivo vdb): limpieza: iniciado en el devid 1 BTRFS cr\u00edtico (dispositivo vdb): no se puede encontrar el mapa de fragmentos para la longitud l\u00f3gica 2214744064 4096 BTRFS cr\u00edtico (dispositivo vdb): No se puede encontrar el mapa de fragmentos para la longitud l\u00f3gica 2214744064 45056. Esto provocar\u00eda errores irreparables. - Informes KASAN de uso gratuito: =========================================== ========================= ERROR: KASAN: slab-use-after-free en __blk_rq_map_sg+0x18f/0x7c0 Lectura de tama\u00f1o 8 en la direcci\u00f3n ffff8881013c9040 por tarea btrfs/909 CPU: 0 PID: 909 Comm: btrfs Not tainted 6.7.0-x64v3-dbg #11 c50636e9419a8354555555245df535e380563b2b Nombre de hardware: PC est\u00e1ndar QEMU (Q35 + ICH9, 2009), BIOS 2023.11-2 24/12/2023 Seguimiento de llamadas : dump_stack_lvl+0x43/0x60 print_report+0xcf/0x640 kasan_report+0xa6/0xd0 __blk_rq_map_sg+0x18f/0x7c0 virtblk_prep_rq.isra.0+0x215/0x6a0 [virtio_blk 19a65eeee9ae6fcf02ed fad39bb9ddee07dcdaff] virtio_queue_rqs+0xc4/0x310 [virtio_blk 19a65eeee9ae6fcf02edfad39bb9ddee07dcdaff] blk_mq_flush_plug_list.part. 0+0x780/0x860 __blk_flush_plug+0x1ba/0x220 blk_finish_plug+0x3b/0x60 submit_initial_group_read+0x10a/0x290 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] Flush_scrub_stripes+0x38 e/0x430 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] Scrub_stripe+0x82a/0xae0 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] Scrub_chunk+0x178/0x200 [btrfs e579 87a360cama82fe8756dcd3e0de5406ccfe965 ] Scrub_enumerate_chunks+0x4bc/0xa30 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] btrfs_scrub_dev+0x398/0x810 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] btr fs_ioctl+0x4b9/0x3020 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] __x64_sys_ioctl+0xbd/0x100 do_syscall_64+0x5d/0xe0 Entry_SYSCALL_64_after_hwframe+0x63/0x6b QEPD: 0033:0x7f47e5e0952b - Fallo , principalmente debido al use-after-free anterior [CAUSA] El fs convertido tiene el siguiente dise\u00f1o de fragmento de datos: clave del elemento 2 (FIRST_CHUNK_TREE CHUNK_ITEM 2214658048) itemoff 16025 tama\u00f1o del elemento 80 longitud 86016 propietario 2 stripe_len 65536 tipo DATOS|single Para el bytenr l\u00f3gico anterior 2214744064 , est\u00e1 al final del fragmento (2214658048 + 86016 = 2214744064). Esto significa que btrfs_submit_bio() dividir\u00eda la biograf\u00eda y activar\u00eda la funci\u00f3n endio para ambas mitades. Sin embargo, Scrub_submit_initial_read() solo esperar\u00eda que la funci\u00f3n endio se llamara una vez, ya no. Esto significa que la primera funci\u00f3n endio ya liberar\u00eda bbio::bio, dejando libre el bvec, por lo que la segunda llamada a endio conducir\u00eda a use-after-free. [FIX] - Aseg\u00farese de que Scrub_read_endio() solo actualice los bits en su rango. Dado que podemos leer menos de 64 K al final del fragmento, no debemos tocar los bits m\u00e1s all\u00e1 del l\u00edmite del fragmento. - Aseg\u00farese de que Scrub_submit_initial_read() solo lea el rango de fragmentos. Esto se hace calculando el n\u00famero real de sectores que necesitamos leer y agregando sector por sector a la biograf\u00eda. Afortunadamente, la ruta de reparaci\u00f3n de lectura de limpieza no necesitar\u00e1 correcciones adicionales: - Scrub_stripe_submit_repair_read() Con las correcciones anteriores, no actualizaremos el bit de error para el rango m\u00e1s all\u00e1 del fragmento, por lo tanto, Scrub_stripe_submit_repair_read() nunca deber\u00eda enviar ninguna lectura m\u00e1s all\u00e1 del fragmento." } ], "id": "CVE-2024-26616", "lastModified": "2024-03-12T12:40:13.500", "metrics": {}, "published": "2024-03-11T18:15:19.400", "references": [ { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/34de0f04684ec00c093a0455648be055f0e8e24f" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/642b9c520ef2f104277ad1f902f8526edbe087fb" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/f546c4282673497a06ecb6190b50ae7f6c85b02f" } ], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Awaiting Analysis" } } } }
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.