{"resultsPerPage":1,"startIndex":0,"totalResults":1,"format":"NVD_CVE","version":"2.0","timestamp":"2026-05-11T08:40:16.793","vulnerabilities":[{"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->iop.inode\n  527                 ? min_t(uint64_t, INT_MAX,\n  528                         KEY_START(k) - bio->bi_iter.bi_sector)\n  529                 : INT_MAX;\n  530         int ret = s->d->cache_miss(b, s, bio, sectors);\n\nHere s->d->cache_miss() is the call backfunction pointer initialized as\ncached_dev_cache_miss(), the last parameter 'sectors' 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'sectors', 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->ops->is_extents && !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 'sectors'.\n\nInside cached_dev_cache_miss(), parameter 'sectors' is used to calculate\nthe size of data read from backing device for the cache missing. This\nsize is stored in s->insert_bio_sectors by the following lines of code,\n[code block 4]\n  909    s->insert_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->iop.replace_key by the following lines of code,\n[code block 5]\n  911   s->iop.replace_key = KEY(s->iop.inode,\n  912                    bio->bi_iter.bi_sector + s->insert_bio_sectors,\n  913                    s->insert_bio_sectors);\nThe oversized parameter 'sectors' 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->insert_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->insert_bio_sectors, PAGE_SECTORS),\n  928                 &dc->disk.bio_split);\nThe oversized parameter 'sectors' may trigger panic 2) by BUG() from the\nagove code block.\n\nNow let me explain how the panics happen with the oversized 'sectors'.\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 << 63) | ((__u64) (size) << 20) | (inode),     \\\n  74      .low = (offset)                                              \\\n  75 })\n\nHere 'size' is 16bits width embedded in 64bits member 'high' of struct\nbkey. But in code block 1, if \"KEY_START(k) - bio->bi_iter.bi_sector\" is\nvery probably to be larger than (1<<16) - 1, which makes the bkey size\ncalculation in code block 5 is overflowed. In one bug report the value\nof parameter 'sectors' is 131072 (= 1 << 17), the overflowed 'sectors'\nresults the overflowed s->insert_bio_sectors in code block 4, then makes\nsize field of s->iop.replace_key to be 0 in code block 5. Then the 0-\nsized s->iop.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, &s->op, &s->iop.replace_key);\n\nThen the 0-sized s->iop.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ño en la ruta del código faltante de la caché. En la ruta del código faltante de la caché del dispositivo almacenado en caché, si una ubicación adecuada del árbol B+ interno coincide con un rango de falta de caché, La función cached_dev_cache_miss() se llamará en cache_lookup_fn() en el siguiente bloque de código, [bloque de código 1] 526 unsigned int sectores = KEY_INODE(k) == s-&gt;iop.inode 527? min_t(uint64_t, INT_MAX, 528 KEY_START(k) - bio-&gt;bi_iter.bi_sector) 529: INT_MAX; 530 int ret = s-&gt;d-&gt;cache_miss(b, s, bio, sectors); Aquí s-&gt;d-&gt;cache_miss() es el puntero de función de devolución de llamada inicializado como cached_dev_cache_miss(), el último parámetro 'sectors' es una pista importante para calcular el tamaño de la solicitud de lectura al dispositivo de respaldo de los datos de caché faltantes. El cálculo actual en el bloque de código anterior puede generar un valor sobredimensionado de 'sectors', lo que en consecuencia puede desencadenar 2 posibles pánicos del kernel diferentes mediante BUG() o BUG_ON() como se enumera a continuación, 1) BUG_ON() dentro de bch_btree_insert_key(), [bloque de código 2 ] 886 BUG_ON(b-&gt;ops-&gt;is_extents &amp;&amp; !KEY_SIZE(k)); 2) BUG() dentro de biovec_slab(), [bloque de código 3] 51 predeterminado: 52 BUG(); 53 devuelve NULO; Todos los pánicos anteriores son originales de cached_dev_cache_miss() por el parámetro 'sectors' de gran tamaño. Dentro de cached_dev_cache_miss(), el parámetro 'sectors' se utiliza para calcular el tamaño de los datos leídos desde el dispositivo de respaldo para el caché que falta. Este tamaño se almacena en s-&gt;insert_bio_sectors mediante las siguientes líneas de código, [bloque de código 4] 909 s-&gt;insert_bio_sectors = min(sectors, bio_sectors(bio) + reada); Luego, la clave real que se inserta en el árbol B+ interno se genera y almacena en s-&gt;iop.replace_key mediante las siguientes líneas de código, [bloque de código 5] 911 s-&gt;iop.replace_key = KEY(s-&gt;iop.inode, 912 bio-&gt;bi_iter.bi_sector + s-&gt;insertar_bio_sectores, 913 s-&gt;insertar_bio_sectores); El parámetro 'sectors' de gran tamaño puede provocar pánico 1) mediante BUG_ON() del bloque de código anterior. Y el envío de biografía al dispositivo de respaldo para los datos faltantes se asigna con una sugerencia de s-&gt;insert_bio_sectors mediante las siguientes líneas de código, [bloque de código 6] 926 cache_bio = bio_alloc_bioset(GFP_NOWAIT, 927 DIV_ROUND_UP(s-&gt;insert_bio_sectors, PAGE_SECTORS), 928 &amp;dc-&gt;disk.bio_split); Los 'sectors' de parámetros de gran tamaño pueden provocar pánico 2) mediante BUG() desde el bloque de código anterior. Ahora permítanme explicar cómo se produce el pánico en los \"sectors\" sobredimensionados. En el bloque de código 5, replace_key se genera mediante la macro KEY(). De la definición de macro KEY(), [bloque de código 7] 71 #define KEY(inode, offset, size) \\ 72 ((struct bkey) { \\ 73 .high = (1ULL &lt;&lt; 63) | ((__u64) ( tamaño) &lt;&lt; 20) | (inodo), \\ 74 .low = (desplazamiento) \\ 75 }) Aquí 'tamaño' es un ancho de 16 bits incrustado en el miembro 'alto' de 64 bits de la estructura bkey. Pero en el bloque de código 1, si \"KEY_START(k) - bio-&gt;bi_iter.bi_sector\" es muy probable que sea mayor que (1&lt;&lt;16) - 1, lo que hace que el cálculo del tamaño de la clave b en el bloque de código 5 se desborde. En un informe de error, el valor del parámetro 'sectors' es 131072 (= 1 &lt;&lt; 17), los 'sectors' desbordados dan como resultado s-&gt;insert_bio_sectors desbordados en el bloque de código 4, luego convierte el campo de tamaño de s-&gt;iop.replace_key en sea 0 en el bloque de código 5. Luego, el tamaño 0 s-&gt;iop.replace_key se inserta en el árbol B+ interno como clave de verificación de falta de caché (una clave especial para detectar y evitar una ejecución entre la solicitud de escritura normal y la solicitud de lectura faltante de caché) como, [bloque de código 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"]}]}}]}