CVE-2021-47275 (GCVE-0-2021-47275)
Vulnerability from cvelistv5
Published
2024-05-21 14:20
Modified
2025-07-11 17:18
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: bcache: avoid oversized read request in cache missing code path In the cache missing code path of cached device, if a proper location from the internal B+ tree is matched for a cache miss range, function cached_dev_cache_miss() will be called in cache_lookup_fn() in the following code block, [code block 1] 526 unsigned int sectors = KEY_INODE(k) == s->iop.inode 527 ? min_t(uint64_t, INT_MAX, 528 KEY_START(k) - bio->bi_iter.bi_sector) 529 : INT_MAX; 530 int ret = s->d->cache_miss(b, s, bio, sectors); Here s->d->cache_miss() is the call backfunction pointer initialized as cached_dev_cache_miss(), the last parameter 'sectors' is an important hint to calculate the size of read request to backing device of the missing cache data. Current calculation in above code block may generate oversized value of 'sectors', which consequently may trigger 2 different potential kernel panics by BUG() or BUG_ON() as listed below, 1) BUG_ON() inside bch_btree_insert_key(), [code block 2] 886 BUG_ON(b->ops->is_extents && !KEY_SIZE(k)); 2) BUG() inside biovec_slab(), [code block 3] 51 default: 52 BUG(); 53 return NULL; All the above panics are original from cached_dev_cache_miss() by the oversized parameter 'sectors'. Inside cached_dev_cache_miss(), parameter 'sectors' is used to calculate the size of data read from backing device for the cache missing. This size is stored in s->insert_bio_sectors by the following lines of code, [code block 4] 909 s->insert_bio_sectors = min(sectors, bio_sectors(bio) + reada); Then the actual key inserting to the internal B+ tree is generated and stored in s->iop.replace_key by the following lines of code, [code block 5] 911 s->iop.replace_key = KEY(s->iop.inode, 912 bio->bi_iter.bi_sector + s->insert_bio_sectors, 913 s->insert_bio_sectors); The oversized parameter 'sectors' may trigger panic 1) by BUG_ON() from the above code block. And the bio sending to backing device for the missing data is allocated with hint from s->insert_bio_sectors by the following lines of code, [code block 6] 926 cache_bio = bio_alloc_bioset(GFP_NOWAIT, 927 DIV_ROUND_UP(s->insert_bio_sectors, PAGE_SECTORS), 928 &dc->disk.bio_split); The oversized parameter 'sectors' may trigger panic 2) by BUG() from the agove code block. Now let me explain how the panics happen with the oversized 'sectors'. In code block 5, replace_key is generated by macro KEY(). From the definition of macro KEY(), [code block 7] 71 #define KEY(inode, offset, size) \ 72 ((struct bkey) { \ 73 .high = (1ULL << 63) | ((__u64) (size) << 20) | (inode), \ 74 .low = (offset) \ 75 }) Here 'size' is 16bits width embedded in 64bits member 'high' of struct bkey. But in code block 1, if "KEY_START(k) - bio->bi_iter.bi_sector" is very probably to be larger than (1<<16) - 1, which makes the bkey size calculation in code block 5 is overflowed. In one bug report the value of parameter 'sectors' is 131072 (= 1 << 17), the overflowed 'sectors' results the overflowed s->insert_bio_sectors in code block 4, then makes size field of s->iop.replace_key to be 0 in code block 5. Then the 0- sized s->iop.replace_key is inserted into the internal B+ tree as cache missing check key (a special key to detect and avoid a racing between normal write request and cache missing read request) as, [code block 8] 915 ret = bch_btree_insert_check_key(b, &s->op, &s->iop.replace_key); Then the 0-sized s->iop.replace_key as 3rd parameter triggers the bkey size check BUG_ON() in code block 2, and causes the kernel panic 1). Another ke ---truncated---
References
Impacted products
Vendor Product Version
Linux Linux Version: cafe563591446cf80bfbc2fe3bc72a2e36cf1060
Version: cafe563591446cf80bfbc2fe3bc72a2e36cf1060
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2021-47275",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-05-21T18:49:16.517922Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-06-04T17:14:13.941Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      },
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-04T05:32:07.987Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/555002a840ab88468e252b0eedf0b05e2ce7099c"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/41fe8d088e96472f63164e213de44ec77be69478"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/md/bcache/request.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "555002a840ab88468e252b0eedf0b05e2ce7099c",
              "status": "affected",
              "version": "cafe563591446cf80bfbc2fe3bc72a2e36cf1060",
              "versionType": "git"
            },
            {
              "lessThan": "41fe8d088e96472f63164e213de44ec77be69478",
              "status": "affected",
              "version": "cafe563591446cf80bfbc2fe3bc72a2e36cf1060",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/md/bcache/request.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "3.10"
            },
            {
              "lessThan": "3.10",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.12.*",
              "status": "unaffected",
              "version": "5.12.11",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "5.13",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.12.11",
                  "versionStartIncluding": "3.10",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.13",
                  "versionStartIncluding": "3.10",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbcache: avoid oversized read request in cache missing code path\n\nIn the cache missing code path of cached device, if a proper location\nfrom the internal B+ tree is matched for a cache miss range, function\ncached_dev_cache_miss() will be called in cache_lookup_fn() in the\nfollowing code block,\n[code block 1]\n  526         unsigned int sectors = KEY_INODE(k) == s-\u003eiop.inode\n  527                 ? min_t(uint64_t, INT_MAX,\n  528                         KEY_START(k) - bio-\u003ebi_iter.bi_sector)\n  529                 : INT_MAX;\n  530         int ret = s-\u003ed-\u003ecache_miss(b, s, bio, sectors);\n\nHere s-\u003ed-\u003ecache_miss() is the call backfunction pointer initialized as\ncached_dev_cache_miss(), the last parameter \u0027sectors\u0027 is an important\nhint to calculate the size of read request to backing device of the\nmissing cache data.\n\nCurrent calculation in above code block may generate oversized value of\n\u0027sectors\u0027, which consequently may trigger 2 different potential kernel\npanics by BUG() or BUG_ON() as listed below,\n\n1) BUG_ON() inside bch_btree_insert_key(),\n[code block 2]\n   886         BUG_ON(b-\u003eops-\u003eis_extents \u0026\u0026 !KEY_SIZE(k));\n2) BUG() inside biovec_slab(),\n[code block 3]\n   51         default:\n   52                 BUG();\n   53                 return NULL;\n\nAll the above panics are original from cached_dev_cache_miss() by the\noversized parameter \u0027sectors\u0027.\n\nInside cached_dev_cache_miss(), parameter \u0027sectors\u0027 is used to calculate\nthe size of data read from backing device for the cache missing. This\nsize is stored in s-\u003einsert_bio_sectors by the following lines of code,\n[code block 4]\n  909    s-\u003einsert_bio_sectors = min(sectors, bio_sectors(bio) + reada);\n\nThen the actual key inserting to the internal B+ tree is generated and\nstored in s-\u003eiop.replace_key by the following lines of code,\n[code block 5]\n  911   s-\u003eiop.replace_key = KEY(s-\u003eiop.inode,\n  912                    bio-\u003ebi_iter.bi_sector + s-\u003einsert_bio_sectors,\n  913                    s-\u003einsert_bio_sectors);\nThe oversized parameter \u0027sectors\u0027 may trigger panic 1) by BUG_ON() from\nthe above code block.\n\nAnd the bio sending to backing device for the missing data is allocated\nwith hint from s-\u003einsert_bio_sectors by the following lines of code,\n[code block 6]\n  926    cache_bio = bio_alloc_bioset(GFP_NOWAIT,\n  927                 DIV_ROUND_UP(s-\u003einsert_bio_sectors, PAGE_SECTORS),\n  928                 \u0026dc-\u003edisk.bio_split);\nThe oversized parameter \u0027sectors\u0027 may trigger panic 2) by BUG() from the\nagove code block.\n\nNow let me explain how the panics happen with the oversized \u0027sectors\u0027.\nIn code block 5, replace_key is generated by macro KEY(). From the\ndefinition of macro KEY(),\n[code block 7]\n  71 #define KEY(inode, offset, size)                                  \\\n  72 ((struct bkey) {                                                  \\\n  73      .high = (1ULL \u003c\u003c 63) | ((__u64) (size) \u003c\u003c 20) | (inode),     \\\n  74      .low = (offset)                                              \\\n  75 })\n\nHere \u0027size\u0027 is 16bits width embedded in 64bits member \u0027high\u0027 of struct\nbkey. But in code block 1, if \"KEY_START(k) - bio-\u003ebi_iter.bi_sector\" is\nvery probably to be larger than (1\u003c\u003c16) - 1, which makes the bkey size\ncalculation in code block 5 is overflowed. In one bug report the value\nof parameter \u0027sectors\u0027 is 131072 (= 1 \u003c\u003c 17), the overflowed \u0027sectors\u0027\nresults the overflowed s-\u003einsert_bio_sectors in code block 4, then makes\nsize field of s-\u003eiop.replace_key to be 0 in code block 5. Then the 0-\nsized s-\u003eiop.replace_key is inserted into the internal B+ tree as cache\nmissing check key (a special key to detect and avoid a racing between\nnormal write request and cache missing read request) as,\n[code block 8]\n  915   ret = bch_btree_insert_check_key(b, \u0026s-\u003eop, \u0026s-\u003eiop.replace_key);\n\nThen the 0-sized s-\u003eiop.replace_key as 3rd parameter triggers the bkey\nsize check BUG_ON() in code block 2, and causes the kernel panic 1).\n\nAnother ke\n---truncated---"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-07-11T17:18:59.576Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/555002a840ab88468e252b0eedf0b05e2ce7099c"
        },
        {
          "url": "https://git.kernel.org/stable/c/41fe8d088e96472f63164e213de44ec77be69478"
        }
      ],
      "title": "bcache: avoid oversized read request in cache missing code path",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2021-47275",
    "datePublished": "2024-05-21T14:20:03.357Z",
    "dateReserved": "2024-05-21T13:27:52.128Z",
    "dateUpdated": "2025-07-11T17:18:59.576Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2021-47275\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-05-21T15:15:15.903\",\"lastModified\":\"2025-04-30T14:49:09.583\",\"vulnStatus\":\"Analyzed\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nbcache: avoid oversized read request in cache missing code path\\n\\nIn the cache missing code path of cached device, if a proper location\\nfrom the internal B+ tree is matched for a cache miss range, function\\ncached_dev_cache_miss() will be called in cache_lookup_fn() in the\\nfollowing code block,\\n[code block 1]\\n  526         unsigned int sectors = KEY_INODE(k) == s-\u003eiop.inode\\n  527                 ? min_t(uint64_t, INT_MAX,\\n  528                         KEY_START(k) - bio-\u003ebi_iter.bi_sector)\\n  529                 : INT_MAX;\\n  530         int ret = s-\u003ed-\u003ecache_miss(b, s, bio, sectors);\\n\\nHere s-\u003ed-\u003ecache_miss() is the call backfunction pointer initialized as\\ncached_dev_cache_miss(), the last parameter \u0027sectors\u0027 is an important\\nhint to calculate the size of read request to backing device of the\\nmissing cache data.\\n\\nCurrent calculation in above code block may generate oversized value of\\n\u0027sectors\u0027, which consequently may trigger 2 different potential kernel\\npanics by BUG() or BUG_ON() as listed below,\\n\\n1) BUG_ON() inside bch_btree_insert_key(),\\n[code block 2]\\n   886         BUG_ON(b-\u003eops-\u003eis_extents \u0026\u0026 !KEY_SIZE(k));\\n2) BUG() inside biovec_slab(),\\n[code block 3]\\n   51         default:\\n   52                 BUG();\\n   53                 return NULL;\\n\\nAll the above panics are original from cached_dev_cache_miss() by the\\noversized parameter \u0027sectors\u0027.\\n\\nInside cached_dev_cache_miss(), parameter \u0027sectors\u0027 is used to calculate\\nthe size of data read from backing device for the cache missing. This\\nsize is stored in s-\u003einsert_bio_sectors by the following lines of code,\\n[code block 4]\\n  909    s-\u003einsert_bio_sectors = min(sectors, bio_sectors(bio) + reada);\\n\\nThen the actual key inserting to the internal B+ tree is generated and\\nstored in s-\u003eiop.replace_key by the following lines of code,\\n[code block 5]\\n  911   s-\u003eiop.replace_key = KEY(s-\u003eiop.inode,\\n  912                    bio-\u003ebi_iter.bi_sector + s-\u003einsert_bio_sectors,\\n  913                    s-\u003einsert_bio_sectors);\\nThe oversized parameter \u0027sectors\u0027 may trigger panic 1) by BUG_ON() from\\nthe above code block.\\n\\nAnd the bio sending to backing device for the missing data is allocated\\nwith hint from s-\u003einsert_bio_sectors by the following lines of code,\\n[code block 6]\\n  926    cache_bio = bio_alloc_bioset(GFP_NOWAIT,\\n  927                 DIV_ROUND_UP(s-\u003einsert_bio_sectors, PAGE_SECTORS),\\n  928                 \u0026dc-\u003edisk.bio_split);\\nThe oversized parameter \u0027sectors\u0027 may trigger panic 2) by BUG() from the\\nagove code block.\\n\\nNow let me explain how the panics happen with the oversized \u0027sectors\u0027.\\nIn code block 5, replace_key is generated by macro KEY(). From the\\ndefinition of macro KEY(),\\n[code block 7]\\n  71 #define KEY(inode, offset, size)                                  \\\\\\n  72 ((struct bkey) {                                                  \\\\\\n  73      .high = (1ULL \u003c\u003c 63) | ((__u64) (size) \u003c\u003c 20) | (inode),     \\\\\\n  74      .low = (offset)                                              \\\\\\n  75 })\\n\\nHere \u0027size\u0027 is 16bits width embedded in 64bits member \u0027high\u0027 of struct\\nbkey. But in code block 1, if \\\"KEY_START(k) - bio-\u003ebi_iter.bi_sector\\\" is\\nvery probably to be larger than (1\u003c\u003c16) - 1, which makes the bkey size\\ncalculation in code block 5 is overflowed. In one bug report the value\\nof parameter \u0027sectors\u0027 is 131072 (= 1 \u003c\u003c 17), the overflowed \u0027sectors\u0027\\nresults the overflowed s-\u003einsert_bio_sectors in code block 4, then makes\\nsize field of s-\u003eiop.replace_key to be 0 in code block 5. Then the 0-\\nsized s-\u003eiop.replace_key is inserted into the internal B+ tree as cache\\nmissing check key (a special key to detect and avoid a racing between\\nnormal write request and cache missing read request) as,\\n[code block 8]\\n  915   ret = bch_btree_insert_check_key(b, \u0026s-\u003eop, \u0026s-\u003eiop.replace_key);\\n\\nThen the 0-sized s-\u003eiop.replace_key as 3rd parameter triggers the bkey\\nsize check BUG_ON() in code block 2, and causes the kernel panic 1).\\n\\nAnother ke\\n---truncated---\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bcache: evita solicitudes de lectura de gran tama\u00f1o en la ruta del c\u00f3digo faltante de la cach\u00e9. En la ruta del c\u00f3digo faltante de la cach\u00e9 del dispositivo almacenado en cach\u00e9, si una ubicaci\u00f3n adecuada del \u00e1rbol B+ interno coincide con un rango de falta de cach\u00e9, La funci\u00f3n cached_dev_cache_miss() se llamar\u00e1 en cache_lookup_fn() en el siguiente bloque de c\u00f3digo, [bloque de c\u00f3digo 1] 526 unsigned int sectores = KEY_INODE(k) == s-\u0026gt;iop.inode 527? min_t(uint64_t, INT_MAX, 528 KEY_START(k) - bio-\u0026gt;bi_iter.bi_sector) 529: INT_MAX; 530 int ret = s-\u0026gt;d-\u0026gt;cache_miss(b, s, bio, sectors); Aqu\u00ed s-\u0026gt;d-\u0026gt;cache_miss() es el puntero de funci\u00f3n de devoluci\u00f3n de llamada inicializado como cached_dev_cache_miss(), el \u00faltimo par\u00e1metro \u0027sectors\u0027 es una pista importante para calcular el tama\u00f1o de la solicitud de lectura al dispositivo de respaldo de los datos de cach\u00e9 faltantes. El c\u00e1lculo actual en el bloque de c\u00f3digo anterior puede generar un valor sobredimensionado de \u0027sectors\u0027, lo que en consecuencia puede desencadenar 2 posibles p\u00e1nicos del kernel diferentes mediante BUG() o BUG_ON() como se enumera a continuaci\u00f3n, 1) BUG_ON() dentro de bch_btree_insert_key(), [bloque de c\u00f3digo 2 ] 886 BUG_ON(b-\u0026gt;ops-\u0026gt;is_extents \u0026amp;\u0026amp; !KEY_SIZE(k)); 2) BUG() dentro de biovec_slab(), [bloque de c\u00f3digo 3] 51 predeterminado: 52 BUG(); 53 devuelve NULO; Todos los p\u00e1nicos anteriores son originales de cached_dev_cache_miss() por el par\u00e1metro \u0027sectors\u0027 de gran tama\u00f1o. Dentro de cached_dev_cache_miss(), el par\u00e1metro \u0027sectors\u0027 se utiliza para calcular el tama\u00f1o de los datos le\u00eddos desde el dispositivo de respaldo para el cach\u00e9 que falta. Este tama\u00f1o se almacena en s-\u0026gt;insert_bio_sectors mediante las siguientes l\u00edneas de c\u00f3digo, [bloque de c\u00f3digo 4] 909 s-\u0026gt;insert_bio_sectors = min(sectors, bio_sectors(bio) + reada); Luego, la clave real que se inserta en el \u00e1rbol B+ interno se genera y almacena en s-\u0026gt;iop.replace_key mediante las siguientes l\u00edneas de c\u00f3digo, [bloque de c\u00f3digo 5] 911 s-\u0026gt;iop.replace_key = KEY(s-\u0026gt;iop.inode, 912 bio-\u0026gt;bi_iter.bi_sector + s-\u0026gt;insertar_bio_sectores, 913 s-\u0026gt;insertar_bio_sectores); El par\u00e1metro \u0027sectors\u0027 de gran tama\u00f1o puede provocar p\u00e1nico 1) mediante BUG_ON() del bloque de c\u00f3digo anterior. Y el env\u00edo de biograf\u00eda al dispositivo de respaldo para los datos faltantes se asigna con una sugerencia de s-\u0026gt;insert_bio_sectors mediante las siguientes l\u00edneas de c\u00f3digo, [bloque de c\u00f3digo 6] 926 cache_bio = bio_alloc_bioset(GFP_NOWAIT, 927 DIV_ROUND_UP(s-\u0026gt;insert_bio_sectors, PAGE_SECTORS), 928 \u0026amp;dc-\u0026gt;disk.bio_split); Los \u0027sectors\u0027 de par\u00e1metros de gran tama\u00f1o pueden provocar p\u00e1nico 2) mediante BUG() desde el bloque de c\u00f3digo anterior. Ahora perm\u00edtanme explicar c\u00f3mo se produce el p\u00e1nico en los \\\"sectors\\\" sobredimensionados. En el bloque de c\u00f3digo 5, replace_key se genera mediante la macro KEY(). De la definici\u00f3n de macro KEY(), [bloque de c\u00f3digo 7] 71 #define KEY(inode, offset, size) \\\\ 72 ((struct bkey) { \\\\ 73 .high = (1ULL \u0026lt;\u0026lt; 63) | ((__u64) ( tama\u00f1o) \u0026lt;\u0026lt; 20) | (inodo), \\\\ 74 .low = (desplazamiento) \\\\ 75 }) Aqu\u00ed \u0027tama\u00f1o\u0027 es un ancho de 16 bits incrustado en el miembro \u0027alto\u0027 de 64 bits de la estructura bkey. Pero en el bloque de c\u00f3digo 1, si \\\"KEY_START(k) - bio-\u0026gt;bi_iter.bi_sector\\\" es muy probable que sea mayor que (1\u0026lt;\u0026lt;16) - 1, lo que hace que el c\u00e1lculo del tama\u00f1o de la clave b en el bloque de c\u00f3digo 5 se desborde. En un informe de error, el valor del par\u00e1metro \u0027sectors\u0027 es 131072 (= 1 \u0026lt;\u0026lt; 17), los \u0027sectors\u0027 desbordados dan como resultado s-\u0026gt;insert_bio_sectors desbordados en el bloque de c\u00f3digo 4, luego convierte el campo de tama\u00f1o de s-\u0026gt;iop.replace_key en sea 0 en el bloque de c\u00f3digo 5. Luego, el tama\u00f1o 0 s-\u0026gt;iop.replace_key se inserta en el \u00e1rbol B+ interno como clave de verificaci\u00f3n de falta de cach\u00e9 (una clave especial para detectar y evitar una ejecuci\u00f3n entre la solicitud de escritura normal y la solicitud de lectura faltante de cach\u00e9) como, [bloque de c\u00f3digo 8] 915 ret = ---truncado---\"}],\"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.12.11\",\"matchCriteriaId\":\"FB3C9604-BFC9-4C0B-BA5C-974549F97FF6\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:5.13:rc1:*:*:*:*:*:*\",\"matchCriteriaId\":\"0CBAD0FC-C281-4666-AB2F-F8E6E1165DF7\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:5.13:rc2:*:*:*:*:*:*\",\"matchCriteriaId\":\"96AC23B2-D46A-49D9-8203-8E1BEDCA8532\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:5.13:rc3:*:*:*:*:*:*\",\"matchCriteriaId\":\"DA610E30-717C-4700-9F77-A3C9244F3BFD\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:5.13:rc4:*:*:*:*:*:*\",\"matchCriteriaId\":\"1ECD33F5-85BE-430B-8F86-8D7BD560311D\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:5.13:rc5:*:*:*:*:*:*\",\"matchCriteriaId\":\"CF351855-2437-4CF5-AD7C-BDFA51F27683\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/41fe8d088e96472f63164e213de44ec77be69478\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/555002a840ab88468e252b0eedf0b05e2ce7099c\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/41fe8d088e96472f63164e213de44ec77be69478\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/555002a840ab88468e252b0eedf0b05e2ce7099c\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]}]}}",
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CVE Program Container\", \"references\": [{\"url\": \"https://git.kernel.org/stable/c/555002a840ab88468e252b0eedf0b05e2ce7099c\", \"tags\": [\"x_transferred\"]}, {\"url\": \"https://git.kernel.org/stable/c/41fe8d088e96472f63164e213de44ec77be69478\", \"tags\": [\"x_transferred\"]}], \"providerMetadata\": {\"orgId\": \"af854a3a-2127-422b-91ae-364da2661108\", \"shortName\": \"CVE\", \"dateUpdated\": \"2024-08-04T05:32:07.987Z\"}}, {\"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2021-47275\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2024-05-21T18:49:16.517922Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2024-05-23T19:01:25.497Z\"}, \"title\": \"CISA ADP Vulnrichment\"}], \"cna\": {\"title\": \"bcache: avoid oversized read request in cache missing code path\", \"affected\": [{\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"cafe563591446cf80bfbc2fe3bc72a2e36cf1060\", \"lessThan\": \"555002a840ab88468e252b0eedf0b05e2ce7099c\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"cafe563591446cf80bfbc2fe3bc72a2e36cf1060\", \"lessThan\": \"41fe8d088e96472f63164e213de44ec77be69478\", \"versionType\": \"git\"}], \"programFiles\": [\"drivers/md/bcache/request.c\"], \"defaultStatus\": \"unaffected\"}, {\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"3.10\"}, {\"status\": \"unaffected\", \"version\": \"0\", \"lessThan\": \"3.10\", \"versionType\": \"semver\"}, {\"status\": \"unaffected\", \"version\": \"5.12.11\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"5.12.*\"}, {\"status\": \"unaffected\", \"version\": \"5.13\", \"versionType\": \"original_commit_for_fix\", \"lessThanOrEqual\": \"*\"}], \"programFiles\": [\"drivers/md/bcache/request.c\"], \"defaultStatus\": \"affected\"}], \"references\": [{\"url\": \"https://git.kernel.org/stable/c/555002a840ab88468e252b0eedf0b05e2ce7099c\"}, {\"url\": \"https://git.kernel.org/stable/c/41fe8d088e96472f63164e213de44ec77be69478\"}], \"x_generator\": {\"engine\": \"bippy-1.2.0\"}, \"descriptions\": [{\"lang\": \"en\", \"value\": \"In the Linux kernel, the following vulnerability has been resolved:\\n\\nbcache: avoid oversized read request in cache missing code path\\n\\nIn the cache missing code path of cached device, if a proper location\\nfrom the internal B+ tree is matched for a cache miss range, function\\ncached_dev_cache_miss() will be called in cache_lookup_fn() in the\\nfollowing code block,\\n[code block 1]\\n  526         unsigned int sectors = KEY_INODE(k) == s-\u003eiop.inode\\n  527                 ? min_t(uint64_t, INT_MAX,\\n  528                         KEY_START(k) - bio-\u003ebi_iter.bi_sector)\\n  529                 : INT_MAX;\\n  530         int ret = s-\u003ed-\u003ecache_miss(b, s, bio, sectors);\\n\\nHere s-\u003ed-\u003ecache_miss() is the call backfunction pointer initialized as\\ncached_dev_cache_miss(), the last parameter \u0027sectors\u0027 is an important\\nhint to calculate the size of read request to backing device of the\\nmissing cache data.\\n\\nCurrent calculation in above code block may generate oversized value of\\n\u0027sectors\u0027, which consequently may trigger 2 different potential kernel\\npanics by BUG() or BUG_ON() as listed below,\\n\\n1) BUG_ON() inside bch_btree_insert_key(),\\n[code block 2]\\n   886         BUG_ON(b-\u003eops-\u003eis_extents \u0026\u0026 !KEY_SIZE(k));\\n2) BUG() inside biovec_slab(),\\n[code block 3]\\n   51         default:\\n   52                 BUG();\\n   53                 return NULL;\\n\\nAll the above panics are original from cached_dev_cache_miss() by the\\noversized parameter \u0027sectors\u0027.\\n\\nInside cached_dev_cache_miss(), parameter \u0027sectors\u0027 is used to calculate\\nthe size of data read from backing device for the cache missing. This\\nsize is stored in s-\u003einsert_bio_sectors by the following lines of code,\\n[code block 4]\\n  909    s-\u003einsert_bio_sectors = min(sectors, bio_sectors(bio) + reada);\\n\\nThen the actual key inserting to the internal B+ tree is generated and\\nstored in s-\u003eiop.replace_key by the following lines of code,\\n[code block 5]\\n  911   s-\u003eiop.replace_key = KEY(s-\u003eiop.inode,\\n  912                    bio-\u003ebi_iter.bi_sector + s-\u003einsert_bio_sectors,\\n  913                    s-\u003einsert_bio_sectors);\\nThe oversized parameter \u0027sectors\u0027 may trigger panic 1) by BUG_ON() from\\nthe above code block.\\n\\nAnd the bio sending to backing device for the missing data is allocated\\nwith hint from s-\u003einsert_bio_sectors by the following lines of code,\\n[code block 6]\\n  926    cache_bio = bio_alloc_bioset(GFP_NOWAIT,\\n  927                 DIV_ROUND_UP(s-\u003einsert_bio_sectors, PAGE_SECTORS),\\n  928                 \u0026dc-\u003edisk.bio_split);\\nThe oversized parameter \u0027sectors\u0027 may trigger panic 2) by BUG() from the\\nagove code block.\\n\\nNow let me explain how the panics happen with the oversized \u0027sectors\u0027.\\nIn code block 5, replace_key is generated by macro KEY(). From the\\ndefinition of macro KEY(),\\n[code block 7]\\n  71 #define KEY(inode, offset, size)                                  \\\\\\n  72 ((struct bkey) {                                                  \\\\\\n  73      .high = (1ULL \u003c\u003c 63) | ((__u64) (size) \u003c\u003c 20) | (inode),     \\\\\\n  74      .low = (offset)                                              \\\\\\n  75 })\\n\\nHere \u0027size\u0027 is 16bits width embedded in 64bits member \u0027high\u0027 of struct\\nbkey. But in code block 1, if \\\"KEY_START(k) - bio-\u003ebi_iter.bi_sector\\\" is\\nvery probably to be larger than (1\u003c\u003c16) - 1, which makes the bkey size\\ncalculation in code block 5 is overflowed. In one bug report the value\\nof parameter \u0027sectors\u0027 is 131072 (= 1 \u003c\u003c 17), the overflowed \u0027sectors\u0027\\nresults the overflowed s-\u003einsert_bio_sectors in code block 4, then makes\\nsize field of s-\u003eiop.replace_key to be 0 in code block 5. Then the 0-\\nsized s-\u003eiop.replace_key is inserted into the internal B+ tree as cache\\nmissing check key (a special key to detect and avoid a racing between\\nnormal write request and cache missing read request) as,\\n[code block 8]\\n  915   ret = bch_btree_insert_check_key(b, \u0026s-\u003eop, \u0026s-\u003eiop.replace_key);\\n\\nThen the 0-sized s-\u003eiop.replace_key as 3rd parameter triggers the bkey\\nsize check BUG_ON() in code block 2, and causes the kernel panic 1).\\n\\nAnother ke\\n---truncated---\"}], \"cpeApplicability\": [{\"nodes\": [{\"negate\": false, \"cpeMatch\": [{\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"5.12.11\", \"versionStartIncluding\": \"3.10\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"5.13\", \"versionStartIncluding\": \"3.10\"}], \"operator\": \"OR\"}]}], \"providerMetadata\": {\"orgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"shortName\": \"Linux\", \"dateUpdated\": \"2025-07-11T17:18:59.576Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2021-47275\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2025-07-11T17:18:59.576Z\", \"dateReserved\": \"2024-05-21T13:27:52.128Z\", \"assignerOrgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"datePublished\": \"2024-05-21T14:20:03.357Z\", \"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.