Re: [PATCH 03/13] blk-crypto: reject fallback data unit sizes it can't handle

[Baokun Li <libaokun@linux.alibaba.com>]

On 2026/10/12 01:20, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] block: NULL pointer deref in blk_crypto_fallback_evict_key() on setup failure
[...]
> [Severity: High]
> Does this early return bypass blk_crypto_fallback_init() and leave
> blk_crypto_fallback_profile as NULL?
>
> If this is the first fallback usage, returning here means we haven't
> initialized the profile. If downstream callers (like dm-inlinecrypt) handle
> this -EOPNOTSUPP error by attempting to evict the partially initialized key,
> can it lead to a NULL pointer dereference?
>
> When target teardown calls blk_crypto_evict_key(), it will eventually call
> blk_crypto_fallback_evict_key(), which passes the uninitialized profile
> directly:
>
> block/blk-crypto-fallback.c:blk_crypto_fallback_evict_key() {
> 	return __blk_crypto_evict_key(blk_crypto_fallback_profile, key);
> }
>
> This unvalidated profile pointer is then dereferenced when checking the number
> of slots:
>
> block/blk-crypto-profile.c:__blk_crypto_evict_key() {
> 	...
> 	if (profile->num_slots == 0) {
> 	...
> }
>
> Could this cause a kernel panic if a user with device mapper access requests
> an unsupported data unit size?
>

The early return does leave blk_crypto_fallback_profile uninitialized,
but the NULL dereference that follows is a pre-existing issue, unrelated
to this series: the same eviction path is reachable on the base tree,
and the two flows below trigger a NULL dereference or a use-after-free:

  dm-inlinecrypt ctor            # first use of the fallback
   ├─ blk_crypto_init_key()      # succeeds, ctx->key.size != 0
   ├─ blk_crypto_start_using_key()
   │   ├─ return -EOPNOTSUPP     # uninit profile, will NULL deref
   │   └─ blk_crypto_fallback_start_using_key()
   │      └─ blk_crypto_fallback_init() fails
   │         └─ kfree(profile)   # not NULLed, will UAF
   ├─ goto bad
   └─ inlinecrypt_dtr()          # evicts whenever key.size is set
      └─ blk_crypto_evict_key()
         └─ blk_crypto_config_supported_natively() = false
            └─ blk_crypto_fallback_evict_key()
               └─ __blk_crypto_evict_key(blk_crypto_fallback_profile)
                  └─ profile->num_slots # BOOM!!!

If this series doesn't need a V2, I'll send the fix as a standalone
bugfix.  If a V2 is needed, I'll include it in the series before this
patch.


Thanks,
Baokun