cve-2022-48902
Vulnerability from cvelistv5
Published
2024-08-22 01:30
Modified
2024-12-19 08:10
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: btrfs: do not WARN_ON() if we have PageError set Whenever we do any extent buffer operations we call assert_eb_page_uptodate() to complain loudly if we're operating on an non-uptodate page. Our overnight tests caught this warning earlier this week WARNING: CPU: 1 PID: 553508 at fs/btrfs/extent_io.c:6849 assert_eb_page_uptodate+0x3f/0x50 CPU: 1 PID: 553508 Comm: kworker/u4:13 Tainted: G W 5.17.0-rc3+ #564 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 Workqueue: btrfs-cache btrfs_work_helper RIP: 0010:assert_eb_page_uptodate+0x3f/0x50 RSP: 0018:ffffa961440a7c68 EFLAGS: 00010246 RAX: 0017ffffc0002112 RBX: ffffe6e74453f9c0 RCX: 0000000000001000 RDX: ffffe6e74467c887 RSI: ffffe6e74453f9c0 RDI: ffff8d4c5efc2fc0 RBP: 0000000000000d56 R08: ffff8d4d4a224000 R09: 0000000000000000 R10: 00015817fa9d1ef0 R11: 000000000000000c R12: 00000000000007b1 R13: ffff8d4c5efc2fc0 R14: 0000000001500000 R15: 0000000001cb1000 FS: 0000000000000000(0000) GS:ffff8d4dbbd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff31d3448d8 CR3: 0000000118be8004 CR4: 0000000000370ee0 Call Trace: extent_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 ? finish_task_switch.isra.0+0xf9/0x3a0 process_one_work+0x26d/0x580 ? process_one_work+0x580/0x580 worker_thread+0x55/0x3b0 ? process_one_work+0x580/0x580 kthread+0xf0/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 This was partially fixed by c2e39305299f01 ("btrfs: clear extent buffer uptodate when we fail to write it"), however all that fix did was keep us from finding extent buffers after a failed writeout. It didn't keep us from continuing to use a buffer that we already had found. In this case we're searching the commit root to cache the block group, so we can start committing the transaction and switch the commit root and then start writing. After the switch we can look up an extent buffer that hasn't been written yet and start processing that block group. Then we fail to write that block out and clear Uptodate on the page, and then we start spewing these errors. Normally we're protected by the tree lock to a certain degree here. If we read a block we have that block read locked, and we block the writer from locking the block before we submit it for the write. However this isn't necessarily fool proof because the read could happen before we do the submit_bio and after we locked and unlocked the extent buffer. Also in this particular case we have path->skip_locking set, so that won't save us here. We'll simply get a block that was valid when we read it, but became invalid while we were using it. What we really want is to catch the case where we've "read" a block but it's not marked Uptodate. On read we ClearPageError(), so if we're !Uptodate and !Error we know we didn't do the right thing for reading the page. Fix this by checking !Uptodate && !Error, this way we will not complain if our buffer gets invalidated while we're using it, and we'll maintain the spirit of the check which is to make sure we have a fully in-cache block while we're messing with it.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/9efcc83b33b576302147634eca9bece8e3737e34Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/a50e1fcbc9b85fd4e95b89a75c0884cb032a3e06Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/e00077aa439f0e8f416699fa4e9600db6583db70Patch
Impacted products
Vendor Product Version
Linux Linux Version: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
Version: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
Version: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
 Create a notification for this product.
   Linux Linux Create a notification for this product.
Show details on NVD website

To clipboard 

{
   containers: {
      adp: [
         {
            metrics: [
               {
                  other: {
                     content: {
                        id: "CVE-2022-48902",
                        options: [
                           {
                              Exploitation: "none",
                           },
                           {
                              Automatable: "no",
                           },
                           {
                              "Technical Impact": "partial",
                           },
                        ],
                        role: "CISA Coordinator",
                        timestamp: "2024-09-10T15:34:30.401712Z",
                        version: "2.0.3",
                     },
                     type: "ssvc",
                  },
               },
            ],
            providerMetadata: {
               dateUpdated: "2024-09-12T17:33:02.674Z",
               orgId: "134c704f-9b21-4f2e-91b3-4a467353bcc0",
               shortName: "CISA-ADP",
            },
            title: "CISA ADP Vulnrichment",
         },
      ],
      cna: {
         affected: [
            {
               defaultStatus: "unaffected",
               product: "Linux",
               programFiles: [
                  "fs/btrfs/extent_io.c",
               ],
               repo: "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
               vendor: "Linux",
               versions: [
                  {
                     lessThan: "e00077aa439f0e8f416699fa4e9600db6583db70",
                     status: "affected",
                     version: "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
                     versionType: "git",
                  },
                  {
                     lessThan: "9efcc83b33b576302147634eca9bece8e3737e34",
                     status: "affected",
                     version: "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
                     versionType: "git",
                  },
                  {
                     lessThan: "a50e1fcbc9b85fd4e95b89a75c0884cb032a3e06",
                     status: "affected",
                     version: "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
                     versionType: "git",
                  },
               ],
            },
            {
               defaultStatus: "affected",
               product: "Linux",
               programFiles: [
                  "fs/btrfs/extent_io.c",
               ],
               repo: "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
               vendor: "Linux",
               versions: [
                  {
                     lessThanOrEqual: "5.15.*",
                     status: "unaffected",
                     version: "5.15.27",
                     versionType: "semver",
                  },
                  {
                     lessThanOrEqual: "5.16.*",
                     status: "unaffected",
                     version: "5.16.13",
                     versionType: "semver",
                  },
                  {
                     lessThanOrEqual: "*",
                     status: "unaffected",
                     version: "5.17",
                     versionType: "original_commit_for_fix",
                  },
               ],
            },
         ],
         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.",
            },
         ],
         providerMetadata: {
            dateUpdated: "2024-12-19T08:10:10.098Z",
            orgId: "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            shortName: "Linux",
         },
         references: [
            {
               url: "https://git.kernel.org/stable/c/e00077aa439f0e8f416699fa4e9600db6583db70",
            },
            {
               url: "https://git.kernel.org/stable/c/9efcc83b33b576302147634eca9bece8e3737e34",
            },
            {
               url: "https://git.kernel.org/stable/c/a50e1fcbc9b85fd4e95b89a75c0884cb032a3e06",
            },
         ],
         title: "btrfs: do not WARN_ON() if we have PageError set",
         x_generator: {
            engine: "bippy-5f407fcff5a0",
         },
      },
   },
   cveMetadata: {
      assignerOrgId: "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      assignerShortName: "Linux",
      cveId: "CVE-2022-48902",
      datePublished: "2024-08-22T01:30:18.531Z",
      dateReserved: "2024-08-21T06:06:23.291Z",
      dateUpdated: "2024-12-19T08:10:10.098Z",
      state: "PUBLISHED",
   },
   dataType: "CVE_RECORD",
   dataVersion: "5.1",
   "vulnerability-lookup:meta": {
      nvd: "{\"cve\":{\"id\":\"CVE-2022-48902\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-08-22T02:15:04.807\",\"lastModified\":\"2024-09-12T14:01:44.523\",\"vulnStatus\":\"Analyzed\",\"cveTags\":[],\"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úfer de extensión, llamamos a afirmar_eb_page_uptodate() para quejarnos en voz alta si estamos operando en una página 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ándar 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ón del búfer de extensión cuando no logramos escribirlo\\\"), sin embargo, todo lo que esa solución hizo fue evitar que encontráramos búferes de extensión después de una escritura fallida. Eso no nos impidió seguir usando un búfer que ya habíamos encontrado. En este caso, estamos buscando la raíz de confirmación para almacenar en caché el grupo de bloques, de modo que podamos comenzar a confirmar la transacción, cambiar la raíz de confirmación y luego comenzar a escribir. Después del cambio, podemos buscar un búfer de extensión que aún no se ha escrito y comenzar a procesar ese grupo de bloques. Luego no escribimos ese bloqueo y borramos Actualizar en la página, y luego comenzamos a arrojar estos errores. Normalmente aquí estamos protegidos hasta cierto punto por el candado del árbol. 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ía ocurrir antes de submit_bio y después de bloquear y desbloquear el búfer de extensión. También en este caso particular tenemos configurado path->skip_locking, por lo que eso no nos salvará aquí. Simplemente obtendremos un bloque que era válido cuando lo leímos, pero dejó de ser válido mientras lo usábamos. Lo que realmente queremos es detectar el caso en el que hemos \\\"leído\\\" un bloque pero no está 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ágina. Solucione esto marcando !Uptodate && !Error, de esta manera no nos quejaremos si nuestro búfer se invalida mientras lo estamos usando, y mantendremos el espíritu de la verificación, que es asegurarnos de que tengamos un caché completo. bloquear mientras estamos jugando con él.\"}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":5.5,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":3.6}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"NVD-CWE-noinfo\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionEndExcluding\":\"5.15.27\",\"matchCriteriaId\":\"A48510A0-1C49-4D24-BB6E-AC9B5F1C4DFD\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.16\",\"versionEndExcluding\":\"5.16.13\",\"matchCriteriaId\":\"B871B667-EDC0-435D-909E-E918D8D90995\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:5.17:rc1:*:*:*:*:*:*\",\"matchCriteriaId\":\"7BD5F8D9-54FA-4CB0-B4F0-CB0471FDDB2D\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:5.17:rc2:*:*:*:*:*:*\",\"matchCriteriaId\":\"E6E34B23-78B4-4516-9BD8-61B33F4AC49A\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:5.17:rc3:*:*:*:*:*:*\",\"matchCriteriaId\":\"C030FA3D-03F4-4FB9-9DBF-D08E5CAC51AA\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:5.17:rc4:*:*:*:*:*:*\",\"matchCriteriaId\":\"B2D2677C-5389-4AE9-869D-0F881E80D923\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:5.17:rc5:*:*:*:*:*:*\",\"matchCriteriaId\":\"EFA3917C-C322-4D92-912D-ECE45B2E7416\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:5.17:rc6:*:*:*:*:*:*\",\"matchCriteriaId\":\"BED18363-5ABC-4639-8BBA-68E771E5BB3F\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/9efcc83b33b576302147634eca9bece8e3737e34\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/a50e1fcbc9b85fd4e95b89a75c0884cb032a3e06\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/e00077aa439f0e8f416699fa4e9600db6583db70\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]}]}}",
      vulnrichment: {
         containers: "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2022-48902\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2024-09-10T15:34:30.401712Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2024-09-11T12:42:12.921Z\"}}], \"cna\": {\"title\": \"btrfs: do not WARN_ON() if we have PageError set\", \"affected\": [{\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"1da177e4c3f4\", \"lessThan\": \"e00077aa439f\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"1da177e4c3f4\", \"lessThan\": \"9efcc83b33b5\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"1da177e4c3f4\", \"lessThan\": \"a50e1fcbc9b8\", \"versionType\": \"git\"}], \"programFiles\": [\"fs/btrfs/extent_io.c\"], \"defaultStatus\": \"unaffected\"}, {\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"unaffected\", \"version\": \"5.15.27\", \"versionType\": \"custom\", \"lessThanOrEqual\": \"5.15.*\"}, {\"status\": \"unaffected\", \"version\": \"5.16.13\", \"versionType\": \"custom\", \"lessThanOrEqual\": \"5.16.*\"}, {\"status\": \"unaffected\", \"version\": \"5.17\", \"versionType\": \"original_commit_for_fix\", \"lessThanOrEqual\": \"*\"}], \"programFiles\": [\"fs/btrfs/extent_io.c\"], \"defaultStatus\": \"affected\"}], \"references\": [{\"url\": \"https://git.kernel.org/stable/c/e00077aa439f0e8f416699fa4e9600db6583db70\"}, {\"url\": \"https://git.kernel.org/stable/c/9efcc83b33b576302147634eca9bece8e3737e34\"}, {\"url\": \"https://git.kernel.org/stable/c/a50e1fcbc9b85fd4e95b89a75c0884cb032a3e06\"}], \"x_generator\": {\"engine\": \"bippy-c9c4e1df01b2\"}, \"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.\"}], \"providerMetadata\": {\"orgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"shortName\": \"Linux\", \"dateUpdated\": \"2024-08-22T03:30:25.239Z\"}}}",
         cveMetadata: "{\"cveId\": \"CVE-2022-48902\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2024-09-12T17:33:02.674Z\", \"dateReserved\": \"2024-08-21T06:06:23.291Z\", \"assignerOrgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"datePublished\": \"2024-08-22T01:30:18.531Z\", \"assignerShortName\": \"Linux\"}",
         dataType: "CVE_RECORD",
         dataVersion: "5.1",
      },
   },
}


Log in or create an account to share your comment.

Security Advisory comment format.

This schema specifies the format of a comment related to a security advisory.

UUIDv4 of the comment
UUIDv4 of the Vulnerability-Lookup instance
When the comment was created originally
When the comment was last updated
Title of the comment
Description of the comment
The identifier of the vulnerability (CVE ID, GHSA-ID, PYSEC ID, etc.).



Tags
Taxonomy of the tags.




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.