Linux Kernel up to 5.12.10 cached_dev_cache_miss buffer over-read

Summaryinfo

A vulnerability described as critical has been identified in Linux Kernel up to 5.12.10. This affects the function cached_dev_cache_miss. The manipulation results in buffer over-read. This vulnerability is identified as CVE-2021-47275. There is not any exploit available. Upgrading the affected component is recommended.

Detailsinfo

A vulnerability, which was classified as critical, was found in Linux Kernel up to 5.12.10. Affected is the function cached_dev_cache_miss. The manipulation with an unknown input leads to a buffer over-read vulnerability. CWE is classifying the issue as CWE-126. The product reads from a buffer using buffer access mechanisms such as indexes or pointers that reference memory locations after the targeted buffer. This is going to have an impact on confidentiality, integrity, and availability. CVE summarizes:

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---

The advisory is available at git.kernel.org. This vulnerability is traded as CVE-2021-47275 since 05/21/2024. Technical details are known, but there is no available exploit.

Upgrading to version 5.12.11 eliminates this vulnerability. Applying the patch 555002a840ab/41fe8d088e96 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 5.12.0
• 5.12.1
• 5.12.2
• 5.12.3
• 5.12.4
• 5.12.5
• 5.12.6
• 5.12.7
• 5.12.8
• 5.12.9
• 5.12.10

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔍
• 🔍
• 🔍

CPE 2.2info

• 🔍
• 🔍
• 🔍

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Discussion