* [BUG] liveupdate: incoming/outgoing session ioctls accepted in wrong phase can panic
@ 2026-05-24 14:44 Yifei Chu
2026-05-25 15:26 ` Pratyush Yadav
0 siblings, 1 reply; 3+ messages in thread
From: Yifei Chu @ 2026-05-24 14:44 UTC (permalink / raw)
To: Pasha Tatashin, Mike Rapoport, linux-kernel
Cc: Pratyush Yadav, Andrew Morton, Alexander Graf, linux-mm, kexec
[-- Attachment #1.1: Type: text/plain, Size: 2991 bytes --]
Hello,
Short version: I found that liveupdate session ioctls can be accepted on
the wrong kind of session. In my tests, that lets userspace drive memfd LUO
into KHO restore paths for current-kernel preserved memory, which hits
kho_restore_page() warnings and panics with panic_on_warn=1.
There are two closely related cases.
First, a newly created outgoing session accepts incoming-only operations:
LIVEUPDATE_SESSION_FINISH
LIVEUPDATE_SESSION_RETRIEVE_FD
After preserving a memfd, either ioctl dispatches into the incoming restore
path and reaches kho_restore_page().
Second, a retrieved incoming session accepts the outgoing-only operation:
LIVEUPDATE_SESSION_PRESERVE_FD
After a real KHO/kexec handoff, the PoC retrieves the incoming session,
preserves a new current-kernel memfd on it, and then calls FINISH. That
again treats current-kernel state as incoming KHO state.
Tested environment:
Linux version 7.0.9, x86_64 QEMU
gcc 12.3.0, GNU ld 2.38
CONFIG_LIVEUPDATE=y
CONFIG_LIVEUPDATE_MEMFD=y
CONFIG_KEXEC_HANDOVER=y
Boot args included: kho=on liveupdate=on panic_on_warn=1
Outgoing-session FINISH result:
session fd=4
preserved memfd token=0x6f757466696e6973
calling FINISH on outgoing session; this should be rejected
WARNING: kernel/liveupdate/kexec_handover.c:256 at
kho_restore_page+0x1e9/0x4a0
memfd_luo_finish+0x12c/0x370
luo_session_finish+0x35/0x130
Kernel panic - not syncing: kernel: panic_on_warn set …
Outgoing-session RETRIEVE_FD result:
calling RETRIEVE_FD on outgoing session; this should be rejected
WARNING: kernel/liveupdate/kexec_handover.c:256 at
kho_restore_page+0x1e9/0x4a0
memfd_luo_retrieve+0x224/0x9f0
luo_session_retrieve_fd+0x124/0x320
Kernel panic - not syncing: kernel: panic_on_warn set …
Incoming-session PRESERVE_FD result:
[stage2] retrieved incoming session fd=4
[stage2] preserving new fd on incoming session; this should be rejected
[stage2] late preserve succeeded token=0x696e636f6d653032
[stage2] finishing session should hit KHO restore WARN
WARNING: kernel/liveupdate/kexec_handover.c:256 at
kho_restore_page+0x11e/0x280
memfd_luo_finish+0x6d/0x190
luo_session_finish+0x31/0xa0
Kernel panic - not syncing: kernel: panic_on_warn set …
My read is that the ioctl paths need to enforce session phase/origin
consistently. A minimal direction would be:
PRESERVE_FD: require !session->retrieved
RETRIEVE_FD: require session->retrieved
FINISH: require session->retrieved
An explicit immutable incoming/outgoing origin bit might be clearer if the
state machine is expected to grow.
The attached tarball has two PoC directories, full QEMU serial logs, kernel
configs, and README files.
I reproduced the panics on the 7.0.9 QEMU build above. I also checked the
current liveupdate userspace API documentation and current mainline source
for related semantics/source shape, but I have not yet runtime-tested
current mainline.
Thanks,
Chuyifei
[-- Attachment #1.2: Type: text/html, Size: 3256 bytes --]
[-- Attachment #2: liveupdate_phase_origin_warn_panic.tar.gz --]
[-- Type: application/x-tar, Size: 113726 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [BUG] liveupdate: incoming/outgoing session ioctls accepted in wrong phase can panic
2026-05-24 14:44 [BUG] liveupdate: incoming/outgoing session ioctls accepted in wrong phase can panic Yifei Chu
@ 2026-05-25 15:26 ` Pratyush Yadav
0 siblings, 0 replies; 3+ messages in thread
From: Pratyush Yadav @ 2026-05-25 15:26 UTC (permalink / raw)
To: Yifei Chu
Cc: Pasha Tatashin, Mike Rapoport, linux-kernel, Pratyush Yadav,
Andrew Morton, Alexander Graf, linux-mm, kexec
On Sun, May 24 2026, Yifei Chu wrote:
> Hello,
>
> Short version: I found that liveupdate session ioctls can be accepted on the wrong kind of session. In my tests, that
> lets userspace drive memfd LUO into KHO restore paths for current-kernel preserved memory, which hits kho_restore_page()
> warnings and panics with panic_on_warn=1.
I already sent a fix for this:
https://lore.kernel.org/kexec/20260519122428.2378446-1-pratyush@kernel.org/
I need to do a refresh of this patch with some tests.
--
Regards,
Pratyush Yadav
^ permalink raw reply [flat|nested] 3+ messages in thread
* [BUG] liveupdate: incoming/outgoing session ioctls accepted in wrong phase can panic
@ 2026-05-24 17:31 Yifei Chu
0 siblings, 0 replies; 3+ messages in thread
From: Yifei Chu @ 2026-05-24 17:31 UTC (permalink / raw)
To: kexec
Hello,
Resending this to kexec@lists.infradead.org in plain text only. The
previous copy to this list was rejected because it was sent as HTML mail.
The original report was also sent to the liveupdate maintainers,
linux-kernel, linux-mm, and the related reviewers.
Short version: I found that liveupdate session ioctls can be accepted on
the wrong kind of session. In my tests, that lets userspace drive memfd LUO
into KHO restore paths for current-kernel preserved memory, which hits
kho_restore_page() warnings and panics with panic_on_warn=1.
There are two closely related cases.
First, a newly created outgoing session accepts incoming-only operations:
LIVEUPDATE_SESSION_FINISH
LIVEUPDATE_SESSION_RETRIEVE_FD
After preserving a memfd, either ioctl dispatches into the incoming restore
path and reaches kho_restore_page().
Second, a retrieved incoming session accepts the outgoing-only operation:
LIVEUPDATE_SESSION_PRESERVE_FD
After a real KHO/kexec handoff, the PoC retrieves the incoming session,
preserves a new current-kernel memfd on it, and then calls FINISH. That
again treats current-kernel state as incoming KHO state.
Tested environment:
Linux version 7.0.9, x86_64 QEMU
gcc 12.3.0, GNU ld 2.38
CONFIG_LIVEUPDATE=y
CONFIG_LIVEUPDATE_MEMFD=y
CONFIG_KEXEC_HANDOVER=y
Boot args included: kho=on liveupdate=on panic_on_warn=1
Outgoing-session FINISH result:
session fd=4
preserved memfd token=0x6f757466696e6973
calling FINISH on outgoing session; this should be rejected
WARNING: kernel/liveupdate/kexec_handover.c:256 at kho_restore_page+0x1e9/0x4a0
memfd_luo_finish+0x12c/0x370
luo_session_finish+0x35/0x130
Kernel panic - not syncing: kernel: panic_on_warn set ...
Outgoing-session RETRIEVE_FD result:
calling RETRIEVE_FD on outgoing session; this should be rejected
WARNING: kernel/liveupdate/kexec_handover.c:256 at kho_restore_page+0x1e9/0x4a0
memfd_luo_retrieve+0x224/0x9f0
luo_session_retrieve_fd+0x124/0x320
Kernel panic - not syncing: kernel: panic_on_warn set ...
Incoming-session PRESERVE_FD result:
[stage2] retrieved incoming session fd=4
[stage2] preserving new fd on incoming session; this should be rejected
[stage2] late preserve succeeded token=0x696e636f6d653032
[stage2] finishing session should hit KHO restore WARN
WARNING: kernel/liveupdate/kexec_handover.c:256 at kho_restore_page+0x11e/0x280
memfd_luo_finish+0x6d/0x190
luo_session_finish+0x31/0xa0
Kernel panic - not syncing: kernel: panic_on_warn set ...
My read is that the ioctl paths need to enforce session phase/origin
consistently. A minimal direction would be:
PRESERVE_FD: require !session->retrieved
RETRIEVE_FD: require session->retrieved
FINISH: require session->retrieved
An explicit immutable incoming/outgoing origin bit might be clearer if the
state machine is expected to grow.
The full report artifacts are available and were included with the original
mail sent to the other recipients:
liveupdate_phase_origin_warn_panic.tar.gz
It contains two PoC directories, full QEMU serial logs, kernel configs, and
README files. I can resend the artifacts in plain-text-friendly form if that
is preferred.
I reproduced the panics on the 7.0.9 QEMU build above. I also checked the
current liveupdate userspace API documentation and current mainline source for
related semantics/source shape, but I have not yet runtime-tested current
mainline.
Thanks,
Chuyifei
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-06-02 15:17 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-24 14:44 [BUG] liveupdate: incoming/outgoing session ioctls accepted in wrong phase can panic Yifei Chu
2026-05-25 15:26 ` Pratyush Yadav
-- strict thread matches above, loose matches on Subject: below --
2026-05-24 17:31 Yifei Chu
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.