CVE-2022-48902

{"id": "CVE-2022-48902", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Primary", "source": "nvd@nist.gov", "cvssData": {"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"}, "impactScore": 3.6, "exploitabilityScore": 1.8}]}, "published": "2024-08-22T02:15:04.807", "references": [{"url": "https://git.kernel.org/stable/c/9efcc83b33b576302147634eca9bece8e3737e34", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/a50e1fcbc9b85fd4e95b89a75c0884cb032a3e06", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/e00077aa439f0e8f416699fa4e9600db6583db70", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Analyzed", "weaknesses": [{"type": "Primary", "source": "nvd@nist.gov", "description": [{"lang": "en", "value": "NVD-CWE-noinfo"}]}], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: do not WARN_ON() if we have PageError set\n\nWhenever we do any extent buffer operations we call\nassert_eb_page_uptodate() to complain loudly if we're operating on an\nnon-uptodate page. Our overnight tests caught this warning earlier this\nweek\n\n WARNING: CPU: 1 PID: 553508 at fs/btrfs/extent_io.c:6849 assert_eb_page_uptodate+0x3f/0x50\n CPU: 1 PID: 553508 Comm: kworker/u4:13 Tainted: G W 5.17.0-rc3+ #564\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014\n Workqueue: btrfs-cache btrfs_work_helper\n RIP: 0010:assert_eb_page_uptodate+0x3f/0x50\n RSP: 0018:ffffa961440a7c68 EFLAGS: 00010246\n RAX: 0017ffffc0002112 RBX: ffffe6e74453f9c0 RCX: 0000000000001000\n RDX: ffffe6e74467c887 RSI: ffffe6e74453f9c0 RDI: ffff8d4c5efc2fc0\n RBP: 0000000000000d56 R08: ffff8d4d4a224000 R09: 0000000000000000\n R10: 00015817fa9d1ef0 R11: 000000000000000c R12: 00000000000007b1\n R13: ffff8d4c5efc2fc0 R14: 0000000001500000 R15: 0000000001cb1000\n FS: 0000000000000000(0000) GS:ffff8d4dbbd00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007ff31d3448d8 CR3: 0000000118be8004 CR4: 0000000000370ee0\n Call Trace:\n\n extent_buffer_test_bit+0x3f/0x70\n free_space_test_bit+0xa6/0xc0\n load_free_space_tree+0x1f6/0x470\n caching_thread+0x454/0x630\n ? rcu_read_lock_sched_held+0x12/0x60\n ? rcu_read_lock_sched_held+0x12/0x60\n ? rcu_read_lock_sched_held+0x12/0x60\n ? lock_release+0x1f0/0x2d0\n btrfs_work_helper+0xf2/0x3e0\n ? lock_release+0x1f0/0x2d0\n ? finish_task_switch.isra.0+0xf9/0x3a0\n process_one_work+0x26d/0x580\n ? process_one_work+0x580/0x580\n worker_thread+0x55/0x3b0\n ? process_one_work+0x580/0x580\n kthread+0xf0/0x120\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x1f/0x30\n\nThis was partially fixed by c2e39305299f01 (\"btrfs: clear extent buffer\nuptodate when we fail to write it\"), however all that fix did was keep\nus from finding extent buffers after a failed writeout. It didn't keep\nus from continuing to use a buffer that we already had found.\n\nIn this case we're searching the commit root to cache the block group,\nso we can start committing the transaction and switch the commit root\nand then start writing. After the switch we can look up an extent\nbuffer that hasn't been written yet and start processing that block\ngroup. Then we fail to write that block out and clear Uptodate on the\npage, and then we start spewing these errors.\n\nNormally we're protected by the tree lock to a certain degree here. If\nwe read a block we have that block read locked, and we block the writer\nfrom locking the block before we submit it for the write. However this\nisn't necessarily fool proof because the read could happen before we do\nthe submit_bio and after we locked and unlocked the extent buffer.\n\nAlso in this particular case we have path->skip_locking set, so that\nwon't save us here. We'll simply get a block that was valid when we\nread it, but became invalid while we were using it.\n\nWhat we really want is to catch the case where we've \"read\" a block but\nit's not marked Uptodate. On read we ClearPageError(), so if we're\n!Uptodate and !Error we know we didn't do the right thing for reading\nthe page.\n\nFix this by checking !Uptodate && !Error, this way we will not complain\nif our buffer gets invalidated while we're using it, and we'll maintain\nthe spirit of the check which is to make sure we have a fully in-cache\nblock while we're messing with it."}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: no haga WARN_ON() si tenemos configurado PageError. Siempre que realizamos operaciones de b\u00fafer de extensi\u00f3n, llamamos a afirmar_eb_page_uptodate() para quejarnos en voz alta si estamos operando en una p\u00e1gina no actualizada. Nuestras pruebas nocturnas detectaron esta advertencia a principios de esta semana ADVERTENCIA: CPU: 1 PID: 553508 en fs/btrfs/extent_io.c:6849 afirmar_eb_page_uptodate+0x3f/0x50 CPU: 1 PID: 553508 Comm: kworker/u4:13 Tainted: GW 5.17. 0-rc3+ #564 Nombre de hardware: PC est\u00e1ndar QEMU (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 01/04/2014 Cola de trabajo: btrfs-cache btrfs_work_helper RIP: 0010:assert_eb_page_uptodate+0x3f/0x50 RSP: 0018 :ffffa961440a7c68 EFLAGS: 00010246 RAX: 0017ffffc0002112 RBX: ffffe6e74453f9c0 RCX: 00000000000001000 RDX: ffffe6e74467c887 RSI: ffffe6e74453f9c0 ffff8d4c5efc2fc0 RBP: 0000000000000d56 R08: ffff8d4d4a224000 R09: 0000000000000000 R10: 00015817fa9d1ef0 R11: 000000000000000c R12: 000000007b1 R13: ffff8d4c5efc2fc0 R14: 0000000001500000 R15: 0000000001cb1000 FS: 0000000000000000(0000) GS:ffff8d4dbbd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 448d8 CR3: 0000000118be8004 CR4: 0000000000370ee0 Seguimiento de llamadas: extend_buffer_test_bit+0x3f/0x70 free_space_test_bit+0xa6/0xc0 load_free_space_tree +0x1f6/0x470 caching_thread+0x454/0x630 ? rcu_read_lock_sched_held+0x12/0x60? rcu_read_lock_sched_held+0x12/0x60? rcu_read_lock_sched_held+0x12/0x60? lock_release+0x1f0/0x2d0 btrfs_work_helper+0xf2/0x3e0 ? lock_release+0x1f0/0x2d0? terminar_task_switch.isra.0+0xf9/0x3a0 proceso_one_work+0x26d/0x580 ? proceso_one_work+0x580/0x580 trabajador_thread+0x55/0x3b0? proceso_one_work+0x580/0x580 kthread+0xf0/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 Esto fue solucionado parcialmente por c2e39305299f01 (\"btrfs: borrar la actualizaci\u00f3n del b\u00fafer de extensi\u00f3n cuando no logramos escribirlo\"), sin embargo, todo lo que esa soluci\u00f3n hizo fue evitar que encontr\u00e1ramos b\u00faferes de extensi\u00f3n despu\u00e9s de una escritura fallida. Eso no nos impidi\u00f3 seguir usando un b\u00fafer que ya hab\u00edamos encontrado. En este caso, estamos buscando la ra\u00edz de confirmaci\u00f3n para almacenar en cach\u00e9 el grupo de bloques, de modo que podamos comenzar a confirmar la transacci\u00f3n, cambiar la ra\u00edz de confirmaci\u00f3n y luego comenzar a escribir. Despu\u00e9s del cambio, podemos buscar un b\u00fafer de extensi\u00f3n que a\u00fan no se ha escrito y comenzar a procesar ese grupo de bloques. Luego no escribimos ese bloqueo y borramos Actualizar en la p\u00e1gina, y luego comenzamos a arrojar estos errores. Normalmente aqu\u00ed estamos protegidos hasta cierto punto por el candado del \u00e1rbol. Si leemos un bloque, tenemos la lectura del bloque bloqueada y evitamos que el escritor bloquee el bloque antes de enviarlo para la escritura. Sin embargo, esto no es necesariamente infalible porque la lectura podr\u00eda ocurrir antes de submit_bio y despu\u00e9s de bloquear y desbloquear el b\u00fafer de extensi\u00f3n. Tambi\u00e9n en este caso particular tenemos configurado path->skip_locking, por lo que eso no nos salvar\u00e1 aqu\u00ed. Simplemente obtendremos un bloque que era v\u00e1lido cuando lo le\u00edmos, pero dej\u00f3 de ser v\u00e1lido mientras lo us\u00e1bamos. Lo que realmente queremos es detectar el caso en el que hemos \"le\u00eddo\" un bloque pero no est\u00e1 marcado como Actualizado. Al leer, usamos ClearPageError(), por lo que si estamos !Uptodate y !Error sabremos que no hicimos lo correcto al leer la p\u00e1gina. Solucione esto marcando !Uptodate && !Error, de esta manera no nos quejaremos si nuestro b\u00fafer se invalida mientras lo estamos usando, y mantendremos el esp\u00edritu de la verificaci\u00f3n, que es asegurarnos de que tengamos un cach\u00e9 completo. bloquear mientras estamos jugando con \u00e9l."}], "lastModified": "2024-09-12T14:01:44.523", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "A48510A0-1C49-4D24-BB6E-AC9B5F1C4DFD", "versionEndExcluding": "5.15.27"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "B871B667-EDC0-435D-909E-E918D8D90995", "versionEndExcluding": "5.16.13", "versionStartIncluding": "5.16"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:5.17:rc1:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "7BD5F8D9-54FA-4CB0-B4F0-CB0471FDDB2D"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:5.17:rc2:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "E6E34B23-78B4-4516-9BD8-61B33F4AC49A"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:5.17:rc3:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "C030FA3D-03F4-4FB9-9DBF-D08E5CAC51AA"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:5.17:rc4:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "B2D2677C-5389-4AE9-869D-0F881E80D923"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:5.17:rc5:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "EFA3917C-C322-4D92-912D-ECE45B2E7416"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:5.17:rc6:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "BED18363-5ABC-4639-8BBA-68E771E5BB3F"}], "operator": "OR"}]}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}