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\u0027re 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\u0027t keep\nus from continuing to use a buffer that we already had found.\n\nIn this case we\u0027re 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\u0027t 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\u0027re 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\u0027t 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-\u003eskip_locking set, so that\nwon\u0027t save us here.  We\u0027ll 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\u0027ve \"read\" a block but\nit\u0027s not marked Uptodate.  On read we ClearPageError(), so if we\u0027re\n!Uptodate and !Error we know we didn\u0027t do the right thing for reading\nthe page.\n\nFix this by checking !Uptodate \u0026\u0026 !Error, this way we will not complain\nif our buffer gets invalidated while we\u0027re using it, and we\u0027ll maintain\nthe spirit of the check which is to make sure we have a fully in-cache\nblock while we\u0027re 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\u0027re 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\u0027t keep\\nus from continuing to use a buffer that we already had found.\\n\\nIn this case we\u0027re 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\u0027t 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\u0027re 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\u0027t 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-\u003eskip_locking set, so that\\nwon\u0027t save us here.  We\u0027ll 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\u0027ve \\\"read\\\" a block but\\nit\u0027s not marked Uptodate.  On read we ClearPageError(), so if we\u0027re\\n!Uptodate and !Error we know we didn\u0027t do the right thing for reading\\nthe page.\\n\\nFix this by checking !Uptodate \u0026\u0026 !Error, this way we will not complain\\nif our buffer gets invalidated while we\u0027re using it, and we\u0027ll maintain\\nthe spirit of the check which is to make sure we have a fully in-cache\\nblock while we\u0027re 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-\u0026gt;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 \u0026amp;\u0026amp; !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.\"}],\"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\u0027re 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\u0027t keep\\nus from continuing to use a buffer that we already had found.\\n\\nIn this case we\u0027re 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\u0027t 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\u0027re 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\u0027t 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-\u003eskip_locking set, so that\\nwon\u0027t save us here.  We\u0027ll 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\u0027ve \\\"read\\\" a block but\\nit\u0027s not marked Uptodate.  On read we ClearPageError(), so if we\u0027re\\n!Uptodate and !Error we know we didn\u0027t do the right thing for reading\\nthe page.\\n\\nFix this by checking !Uptodate \u0026\u0026 !Error, this way we will not complain\\nif our buffer gets invalidated while we\u0027re using it, and we\u0027ll maintain\\nthe spirit of the check which is to make sure we have a fully in-cache\\nblock while we\u0027re 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.




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.