mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ondrej Kozina <okozina@redhat.com>
To: Ingo Blechschmidt <iblech@speicherleck.de>,
	Alasdair Kergon <agk@redhat.com>,
	Mike Snitzer <snitzer@kernel.org>,
	Mikulas Patocka <mpatocka@redhat.com>,
	Benjamin Marzinski <bmarzins@redhat.com>
Cc: dm-devel@lists.linux.dev, linux-kernel@vger.kernel.org,
	gmazyland@gmail.com
Subject: Re: [PATCH] dm: avoid leaking the caller's thread keyring via the table device file
Date: Tue, 23 Jun 2026 10:56:58 +0200	[thread overview]
Message-ID: <ea67ab0e-a039-460e-ab5b-a448995bbd31@redhat.com> (raw)
In-Reply-To: <ajKwRtP8izwRsMmv@quasitopos>

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 <okozina@redhat.com>


      reply	other threads:[~2026-06-23  8:57 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-17 14:33 Ingo Blechschmidt
2026-06-23  8:56 ` Ondrej Kozina [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ea67ab0e-a039-460e-ab5b-a448995bbd31@redhat.com \
    --to=okozina@redhat.com \
    --cc=agk@redhat.com \
    --cc=bmarzins@redhat.com \
    --cc=dm-devel@lists.linux.dev \
    --cc=gmazyland@gmail.com \
    --cc=iblech@speicherleck.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpatocka@redhat.com \
    --cc=snitzer@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome