Re: [PATCH] x86/pv: free the shared_info page switch_compat() replaces

[George Dunlap <gwd@xxxxxxxxxxxxxx>]

On Tue, Nov 10, 2026 at 2:05 PM Jan Beulich <jbeulich@xxxxxxxx> wrote:
> > I suppose you'll say, sure, but this is a non-hot path, and if we ever
> > *do* free with an outstanding refcount it's a security issue, so why
> > not be safe?  You have to draw the line on internal consistency checks
> > *somewhere*; I'd leave the check off, but I can add it if you really
> > want.
>
> But is this only an _internal_ consistency check? Can't a toolstack or
> DM map a domain's shared-info page (as soon as it exists)? IOW I didn't
> think of the check as a consistency one at all, but rather as a guard
> towards e.g. toolstack behavior changing.

Oh, I see.  Actually, Claude thinks that ATM libxc has a bug in this
respect on the restore path: It reads and stores the frame number for
the shared info page *before* the switch; then maps the stale frame
number when it fills in the restored data.  If the page is moved, then
on staging the refcount will be zero, get_page() will return an error
and the restore operation should fail.

So I'll add a leak-if-nonzero-refcount check to this patch, and add a
second patch making sure we don't retain a shared_info frame number
across a switch.

 -George