CVE-2021-47275: Vulnerability in Linux Linux

Severity: highType: vulnerabilityCVE-2021-47275

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

AI Analysis

Technical Summary

CVE-2021-47275 is a vulnerability in the Linux kernel's bcache subsystem, which manages caching for block devices. The issue arises in the cache missing code path where an oversized read request can be generated due to improper calculation of the 'sectors' parameter. Specifically, when a cache miss occurs, the function cached_dev_cache_miss() is called with a 'sectors' value that is intended to represent the size of the read request to the backing device. However, the calculation of 'sectors' can overflow a 16-bit field used internally in a B+ tree key structure (bkey), leading to an incorrect size value of zero. This malformed key is then inserted into the internal B+ tree, triggering kernel panics via BUG_ON() or BUG() macros in two locations: inside bch_btree_insert_key() and biovec_slab(). These panics cause the kernel to crash, resulting in a denial of service (DoS). The root cause is the overflow of the 'sectors' parameter beyond the 16-bit limit embedded in the bkey structure, which is not properly validated before use. The vulnerability affects Linux kernel versions containing the vulnerable bcache implementation prior to the patch. Exploitation does not require user interaction but does require triggering specific cache miss conditions, which may be feasible by an attacker with local access or through crafted I/O operations. No known exploits are reported in the wild as of the publication date. The vulnerability can cause system instability and crashes, impacting availability of systems relying on bcache for storage performance optimization.

Potential Impact

For European organizations, this vulnerability poses a significant risk to systems running vulnerable Linux kernels with bcache enabled, particularly in environments where high availability and data integrity are critical, such as data centers, cloud providers, and enterprise servers. A successful exploitation leads to kernel panic and system crash, causing denial of service and potential disruption of business operations. This can affect critical infrastructure, financial services, telecommunications, and public sector systems that rely on Linux-based storage solutions. Additionally, recovery from kernel panics may require manual intervention, increasing downtime and operational costs. While the vulnerability does not directly lead to data corruption or privilege escalation, the induced instability can be exploited as part of a broader attack chain or cause cascading failures in distributed systems. The lack of a known exploit in the wild reduces immediate risk, but the technical details are public, enabling potential attackers to develop exploits. Organizations using bcache in production should prioritize patching to maintain system reliability and availability.

Mitigation Recommendations

1. Apply the official Linux kernel patches that address CVE-2021-47275 as soon as they become available from trusted sources or Linux distribution vendors. 2. If patching is delayed, consider disabling bcache on affected systems to eliminate exposure, especially in critical environments. 3. Monitor kernel logs and system stability for signs of unexpected panics or crashes related to bcache operations. 4. Implement strict access controls to limit local user permissions, reducing the risk of an attacker triggering the vulnerability. 5. Employ kernel live patching solutions where supported to minimize downtime during patch deployment. 6. Conduct thorough testing of storage subsystems after patching to ensure no regression or performance degradation. 7. Maintain up-to-date inventory of Linux kernel versions and configurations across infrastructure to identify vulnerable systems quickly. 8. Use security monitoring tools to detect anomalous I/O patterns that may indicate attempts to exploit this vulnerability. These steps go beyond generic advice by focusing on kernel patch management, operational controls specific to bcache, and proactive monitoring tailored to the vulnerability's characteristics.