How to Recover a Samsung Galaxy S23+ From a Kernel Bootloop

TL;DR: A Samsung Galaxy S23+ kernel bootloop is usually recovered by force-restarting, disabling root modules when applicable, entering Recovery or Download Mode, then flashing the complete matching Samsung firmware with Odin. A factory reset alone cannot replace a broken kernel. Back up first where possible; a full restore normally erases your data.

By the PrivacyPortal team

Last updated July 2026

If an S23+ repeatedly restarts at the Samsung logo after a kernel, boot image or root change, stop attempting random flashes. Try module-safe mode only if the problem began after installing a Magisk, KernelSU or APatch module. Otherwise, restore the complete firmware package for the exact model and bootloader revision. Use the normal CSC file, not HOME_CSC, when performing the clean recovery described here. This wipes the phone but restores the kernel and related partitions together.

How to recover a Samsung Galaxy S23+ from a kernel bootloop

The safest recovery path depends on where the boot process fails. A true kernel failure normally restarts the phone before Android reaches the lock screen. A root-module failure often reaches the animated Samsung logo, becomes unusually warm or remains visible to Android Debug Bridge, commonly called ADB.

Before doing anything, disconnect unnecessary USB devices and record the exact model shown on the box, Download Mode screen or original purchase information. Galaxy S23+ variants include SM-S916B, SM-S916U, SM-S916U1 and others. Firmware from a similarly named variant is not interchangeable.

On 22 July 2026, the relevant community report concerned an SM-S916B that bootlooped with a latest CI kernel but booted after restoring the latest non-CI release; the kernel project and exact failing build were not identified.

That missing build information matters. It supports reverting to a previously working, device-specific release, but it does not prove that every continuous-integration build or every S23+ has the same defect.

Caption: A recovery decision tree separates module problems, kernel failures and damaged full-firmware installations.

Back up and understand what can be lost

If the phone still boots intermittently, copy photographs, authentication recovery codes, documents and app exports before flashing anything. Android file-based encryption means data usually cannot be recovered simply by extracting the storage from a phone that no longer boots.

Unlocking a Samsung bootloader wipes user data. Flashing the normal CSC package during recovery also performs a clean installation. The Android bootloader locking documentation confirms that the transition to an unlocked state should erase personal data.

Samsung modifications have consequences beyond the immediate wipe:

• Bootloader unlocking can permanently trip the Knox Warranty Void e-fuse.
• Samsung Knox-dependent features may remain unavailable after returning to stock.
• Manufacturer warranty treatment can differ from your UK statutory consumer rights.
• Over-the-air updates may fail or create another bootloop while modified partitions remain.
• Banking, workplace and media apps may apply Play Integrity or their own detection rules.
• Relocking while non-stock partitions remain can make recovery harder.

Never relock the bootloader merely to solve a bootloop. Relock only after every relevant partition is genuinely stock, the matching firmware boots successfully and you understand that another wipe will occur.

Choose the correct recovery method

What you observe	Likely cause	Best first action	Data impact
Bootloop started immediately after enabling a root module	Module or userspace conflict	Use Magisk safe mode or remove modules through ADB	Usually none if successful
Restart occurs before the Android boot animation	Incompatible kernel, boot or init_boot image	Restore the known-good image only when its provenance is certain; otherwise flash full firmware	Full recovery should be treated as a wipe
Recovery works but clearing cache changes nothing	Broken executable partition rather than cached data	Enter Download Mode and perform a full Odin restore	Wipe recommended
Odin reports FAIL or SW REV CHECK FAIL	Wrong model, blocked downgrade, cable problem or unsuitable package	Stop and verify the model, binary revision, archive and USB connection	No additional action until verified
Download Mode is inaccessible	Button timing, depleted battery or deeper hardware failure	Charge, retry with a known-good USB connection, then seek repair	Depends on the repair

Files and equipment required

Use a Windows computer, a reliable data cable and a direct motherboard USB port where possible. Charge the phone to at least 50%. Close Smart Switch, Kies and any other program that might claim the Samsung USB interface while Odin is running.

• The complete firmware for the exact model, sales code or CSC, and bootloader binary revision.
• All extracted firmware components: BL, AP, CP and CSC.
• Standard Odin3 v3.14.4, which is a widely used baseline for S23-generation firmware packages.
• A current Samsung USB driver if Windows does not identify the device correctly.
• Current Android SDK Platform Tools if attempting ADB module removal.
• The last kernel package that definitely booted, if its source and compatibility are known.

Use the relevant entries in the automatically appended Modules, apps & files to try section where available. Verify archive checksums when the publisher supplies them. Do not flash a file merely because its name contains S23, GKI, KernelSU or Android 16.

Samsung firmware packages encode a bootloader revision that cannot normally be downgraded. For example, a device already running binary revision 6 will reject revision 5 even if both packages are for SM-S916B. Odin commonly reports this as an SW REV CHECK failure.

Numbered recovery tutorial

1. Confirm the trigger. Write down the last change made: kernel ZIP, Odin AP file, Magisk module, KernelSU module, Kernel Patch Module or system update. Do not assume that the newest download was intended for your firmware revision.
2. Attempt one controlled force-restart. Hold Volume Down and the Side key together for roughly seven to ten seconds. Release them when the display goes black. Repeated forced restarts will not repair an incompatible kernel, so move to recovery if the loop returns.
3. Try module-safe mode only when a module is implicated. If Android reaches its boot animation, hold Volume Down continuously while it starts. Magisk can detect Android safe mode and disable modules. If previously authorised ADB becomes available, the Magisk command adb shell magisk --remove-modules can remove all modules. Neither method repairs a kernel that crashes before userspace starts.
4. Enter Samsung Recovery. Connect the phone by USB to a powered computer. From the powered-off state, hold Volume Up and the Side key until the recovery screen appears. Button timing can vary slightly by firmware. Use the volume keys to highlight Wipe cache partition and confirm with the Side key. Cache clearing does not erase normal user files, but it also does not replace a damaged kernel.
5. Enter Download Mode. Force the phone off, then hold Volume Up and Volume Down together while connecting the USB cable to the computer. At the warning screen, follow the displayed Volume Up instruction to continue. Read and photograph the product name, binary status and Knox information.
6. Validate the firmware package. Confirm that every file belongs to the exact displayed model. Check that the package is the same or a newer accepted bootloader revision. Extract the archive completely; do not feed a partially downloaded ZIP directly to Odin.
7. Load Odin. Start Odin3 v3.14.4 and wait for a coloured ID:COM field and an Added message. Load the BL file into BL, AP into AP, CP into CP and the regular CSC file into CSC. AP may take several minutes to parse. Do not substitute HOME_CSC for this clean recovery.
8. Check the options. Leave Auto Reboot and F. Reset Time enabled. Keep Re-Partition, Nand Erase and other advanced options disabled. Do not supply a PIT file unless a qualified device specialist has diagnosed a partition-table problem.
9. Flash without interruption. Select Start once, then leave the cable, computer and phone untouched. Odin should finish with PASS. If it reports FAIL, save the log and stop. Repeatedly retrying an incorrect package is not troubleshooting.
10. Allow the first boot to finish. A clean first boot can take substantially longer than normal. If the device returns directly to Recovery, perform the requested factory-data reset and reboot. The regular CSC flash should already have wiped user data, but Recovery may need to finalise the reset.
11. Verify the repair before modifying anything. Complete initial setup, restart once, check cameras, Wi-Fi, mobile service and storage, then compare the build number with the firmware installed. Leave root and custom kernels off until the stock phone completes several clean boots.

The official Magisk Samsung installation guidance warns against restoring boot, init_boot, recovery or vbmeta individually after certain Samsung modifications and directs users to a full Odin restore with a data wipe.

The warning is especially relevant when the exact previous patch set is unknown. Restoring only one image can leave verified-boot metadata, the kernel and related partitions out of sync. Consult the official Magisk instructions for Samsung devices before patching another AP package.

Caption: Odin should show the correct BL, AP, CP and CSC files before the recovery flash begins.

Root-manager differences that affect diagnosis

Magisk patches a boot-related image and provides modules plus Zygisk integration in userspace. KernelSU and forks such as KernelSU Next and SukiSU Ultra place root support in a compatible kernel. APatch also uses kernel patching and supports Kernel Patch Modules, or KPMs.

A Magisk-patched boot image is not a KernelSU kernel. Installing one to repair the other can preserve the failure or introduce a new one. The official KernelSU installation guide explains its device and kernel requirements.

General Generic Kernel Image compatibility is not enough. A kernel must still match the Samsung device, Android release, vendor modules, security patch level and expected boot-image layout. An AOSP-only kernel advertised for another manufacturer is not made safe by sharing Linux 5.15 or 6.1 ancestry.

KernelSU Next 1.0.7 build 12646 and SUSFS 1.5.7 appeared together in a documented Vantom AOSP-only kernel build; those version numbers are not evidence of Samsung Galaxy S23+ compatibility.

In practice, continuous-integration builds receive less device-specific testing than stable releases. Record the exact filename and checksum of every working kernel so that “return to the previous version” remains a reproducible recovery option.

Common mistakes that prolong the bootloop

• Factory-resetting first: a reset removes user data but does not install a working kernel.
• Flashing only boot.img from an arbitrary package: modern boot chains can involve boot, init_boot, vendor_boot, vbmeta and vendor dependencies.
• Using HOME_CSC during a damaged-system recovery: preserving data can also preserve an inconsistent state.
• Downgrading across the anti-rollback boundary: Odin will reject a lower bootloader binary.
• Mixing root systems: leaving Magisk modifications in place while installing a KernelSU kernel can create conflicts.
• Following instructions for another S23 model: S23, S23+ and S23 Ultra packages are not interchangeable.
• Assuming Android safe mode repairs the kernel: it can suppress apps or modules only after the kernel boots far enough.
• Relocking too early: a locked bootloader expects a valid stock boot chain and may refuse modified images.

After recovery: update, root or remain stock?

Remain on the recovered stock firmware until the phone survives several cold boots and a full charge cycle. If an official update is available, confirm that all partitions are stock before installing it. Modified Samsung devices often require a fresh full-firmware workflow rather than an ordinary incremental update.

If you decide to root again, begin with the PrivacyPortal guide to rooting an Android phone safely, then follow instructions written specifically for the S23+ variant and current firmware. Keep a copy of the complete matching stock package before making changes.

Root hiding is not the same as security. Kernel-level tools such as SUSFS can reduce some observable traces, but they also enlarge the trusted code base and can introduce compatibility failures. No module, kernel or root manager can guarantee that a particular bank, wallet, workplace or streaming app will accept the phone.

Caption: A successful Odin PASS should be followed by clean stock boots and hardware checks before root is reintroduced.

Frequently asked questions

Can a factory reset fix a Samsung Galaxy S23+ kernel bootloop?

A factory reset can fix corrupted user settings or data, but it cannot replace an incompatible or damaged kernel. If the bootloop began immediately after flashing a kernel or patched boot image, restore a known-compatible image or, more safely when the state is uncertain, flash the complete matching Samsung firmware.

Can I recover the phone without losing data?

Sometimes. A Magisk module problem may be resolved through safe mode or previously authorised ADB without a wipe. A genuine kernel or verified-boot failure commonly requires full firmware restoration. Because encrypted data may already be inaccessible, do not promise a no-wipe recovery and do not use HOME_CSC as a gamble when partitions are inconsistent.

Why does the stable kernel boot when the latest CI build does not?

A CI build may contain a new compiler, configuration, KernelSU integration or upstream patch that has not been tested against the S23+ firmware currently installed. Return to the exact known-good release and report the model, firmware build, kernel filename, checksum and available logs to the developer.

Does flashing stock firmware reset Knox?

No. Odin can restore stock software, but it cannot reverse a physically tripped Knox Warranty Void e-fuse. Some Samsung security features may therefore remain unavailable even though Android boots normally.

Will stock firmware make every banking app work again?

No result can be guaranteed. A clean, fully stock and properly locked device generally presents fewer modification signals, but apps can consider Knox state, Play Integrity, account risk, regional policy and their own detection systems. Never relock until the complete stock configuration has been verified.

What should I do if Odin cannot see the phone?

Try a direct USB port, a known-good data cable and the current Samsung USB driver. Close Smart Switch and other phone-management software, then re-enter Download Mode. If Windows never detects the device and the phone cannot enter Recovery or Download Mode after charging, professional hardware assessment is the safer next step.