Hi,
On 17/06/2026 16:33, Ingo Blechschmidt wrote:
The refactoring in commit a28d893eb327 ("md: port block device access to file")
accidentally causes the caller's thread keyring to be kept alive long
beyond the caller's lifetime.
For the record for anyone tracking the issue interdependently.
I have tested the patch and can ack it fixes the issue for block devices
opened in DM table constructors. But that's not, unfortunately, the root
cause of the issue. The keys put in caller's thread keyring can be
pinned via many kernel APIs taking their own reference on current_cred()
when a process calls into them. That's something I missed when I added
the feature in libcryptsetup.
For example: while I was testing the patch I got hit by the issue again
when I had test LUKS2 image in a file. The cryptsetup creates loop
device in before it opens dm-crypt mapping over it. And voila the thread
keyring got pinned again, via loop device.
So to fix it properly, I have opened MR also on the cryptsetup to
manually release the keyring while releasing a crypt device context:
https://gitlab.com/cryptsetup/cryptsetup/-/merge_requests/937
Tested-by: Ondrej Kozina <[email protected]>
