CVE-2026-31445

In the Linux kernel, the following vulnerability has been resolved:

mm/damon/core: avoid use of half-online-committed context

One major usage of damoncall() is online DAMON parameters update. It is done by calling damoncommitctx() inside the damoncall() callback function. damoncommitctx() can fail for two reasons: 1) invalid parameters and 2) internal memory allocation failures. In case of failures, the damonctx that attempted to be updated (commit destination) can be partially updated (or, corrupted from a perspective), and therefore shouldn't be used anymore. The function only ensures the damonctx object can safely deallocated using damondestroyctx().

The API callers are, however, calling damoncommitctx() only after asserting the parameters are valid, to avoid damoncommitctx() fails due to invalid input parameters. But it can still theoretically fail if the internal memory allocation fails. In the case, DAMON may run with the partially updated damonctx. This can result in unexpected behaviors including even NULL pointer dereference in case of damoscommit_dests() failure [1]. Such allocation failure is arguably too small to fail, so the real world impact would be rare. But, given the bad consequence, this needs to be fixed.

Avoid such partially-committed (maybe-corrupted) damonctx use by saving the damoncommitctx() failure on the damonctx object. For this, introduce damonctx->maybecorrupted field. damoncommitctx() sets it when it is failed. kdamondcall() checks if the field is set after each damoncallcontrol->fn() is executed. If it is set, ignore remaining callback requests and return. All kdamondcall() callers including kdamondfn() also check the maybecorrupted field right after kdamondcall() invocations. If the field is set, break the kdamondfn() main loop so that DAMON sill doesn't use the context that might be corrupted.

[sj@kernel.org: let kdamondcall() with cancel regardless of maybecorrupted]