CVE-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 cacheddevcachemiss() will be called in cachelookupfn() in the following code block, [code block 1] 526 unsigned int sectors = KEYINODE(k) == s->iop.inode 527 ? mint(uint64t, INTMAX, 528 KEYSTART(k) - bio->biiter.bisector) 529 : INTMAX; 530 int ret = s->d->cachemiss(b, s, bio, sectors);

Here s->d->cachemiss() is the call backfunction pointer initialized as cacheddevcachemiss(), 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) BUGON() inside bchbtreeinsertkey(), [code block 2] 886 BUGON(b->ops->isextents && !KEYSIZE(k)); 2) BUG() inside biovecslab(), [code block 3] 51 default: 52 BUG(); 53 return NULL;

All the above panics are original from cacheddevcache_miss() by the oversized parameter 'sectors'.

Inside cacheddevcachemiss(), parameter 'sectors' is used to calculate the size of data read from backing device for the cache missing. This size is stored in s->insertbiosectors by the following lines of code, [code block 4] 909 s->insertbiosectors = min(sectors, biosectors(bio) + reada);

Then the actual key inserting to the internal B+ tree is generated and stored in s->iop.replacekey by the following lines of code, [code block 5] 911 s->iop.replacekey = KEY(s->iop.inode, 912 bio->biiter.bisector + s->insertbiosectors, 913 s->insertbiosectors); 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->insertbiosectors by the following lines of code, [code block 6] 926 cachebio = bioallocbioset(GFPNOWAIT, 927 DIVROUNDUP(s->insertbiosectors, PAGESECTORS), 928 &dc->disk.biosplit); 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, replacekey 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 "KEYSTART(k) - bio->biiter.bisector" 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->insertbiosectors in code block 4, then makes size field of s->iop.replacekey to be 0 in code block 5. Then the 0- sized s->iop.replacekey 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 = bchbtreeinsertcheckkey(b, &s->op, &s->iop.replacekey);

Then the 0-sized s->iop.replacekey as 3rd parameter triggers the bkey size check BUGON() in code block 2, and causes the kernel panic 1).

Another ke ---truncated---