Skip to content

Security: superwilso/Cinder

Security

SECURITY.md

Security policy

Cinder replaces the Home application on a Sony NW-A50-series Walkman. It ships eight setuid-root helpers, an installer that triggers the player's own firmware updater, and a launcher that runs on the boot path. This device has no public DFU or EDL recovery path: a bad boot is recovered by the escape ladder described below, or by an eMMC restore, or not at all.

That is the context for everything here. Please read it before reporting, and before contributing anything that touches the boot path.

Reporting a vulnerability

Open a private advisory: https://github.com/superwilso/Cinder/security/advisories/new. Do not open a public issue for anything in the categories below.

Please include the firmware version, the Cinder channel (stable or dev), and — if the device still boots — the tail of /contents/cinderhome.log.

Expect a first response within a week. This is a hobby project maintained by one person; there is no SLA, and there is no bug bounty.

What is in scope

The parts where a defect can cost someone their device or their root:

  • The setuid helpers — all eight: cinder-power, cinder-msc, cinder-clock, cinder-fm, cinder-voltable, cinder-battery, cinder-gpunode, cinder-umount (the chmod 4755 lines in install_cinderhome.sh are the authoritative list). They run as root on behalf of an unprivileged UI. Argument handling, path handling and anything reachable from /contents (which is FAT, world-writable, and shared with any PC the player is plugged into) matter most.
  • The launcher and the escape ladderinstall_cinderhome.sh's launcher, the bad-boot counter, the auto-revert, the crash supervisor, the kill switch. A defect that disarms an escape is more serious than one that crashes the app, because the app crashing is what the escapes are for.
  • The installer — it writes NW_WM_FW.UPG to a device root and sends the player's vendor SCSI upgrade command (pass-through on Windows, SG_IO on Linux), which runs as administrator/root.
  • Anything that can make the device unbootable, whether or not an attacker is involved.

What is out of scope

  • The device is unlocked by design. Cinder is itself an unofficial modification; "an attacker with physical access and a USB cable can change the firmware" is the premise, not a finding.
  • Sony's own services and firmware. Cinder drives closed Sony binaries over IPC. Defects in those belong to Sony. Report them here only where Cinder can reasonably defend against them.
  • The unsigned installer. Known and documented (docs/SHORTCOMINGS.md D7). Code-signing certificates cost money this project does not have. The release publishes SHA256SUMS; verify the download against it.
  • Committed binary payload. cinder-home/dist/ holds prebuilt ARM binaries because building them needs a glibc-2.23 + libc++-3.9.0 cross toolchain. tools/release.sh rebuilds and compares them byte-for-byte before it will tag — but see D4/D7: that guard is currently opt-in.

Rules that exist because something went wrong

These are not style preferences. Each was written after a real incident, and a change that breaks one is a security-relevant change even if it looks cosmetic:

  1. Never write /proc/regmon/<chip>/value. Selecting a register through target is a read; writing value changes audio hardware under the running player, and the codec is the one part of this device with no software recovery path.
  2. Never write to BtTransmitterService's PCM socket without the type-1 handshake. PCM sent while the connection is still parsing frames is read as a type and a length, and a garbage length reaches operator new[] inside a core Sony service. That rebooted the device twice.
  3. Never guess vtable slot indices into Sony services. Recover them, or leave the feature off.
  4. An escape must depend on less than what it rescues. See docs/AUDIT_2026-07-26.md.

Verifying a download

sha256sum -c SHA256SUMS

SHA256SUMS is attached to each release. It proves the download matches what the release workflow produced. On its own it does not prove the workflow built this source tree.

Releases from v0.3.5 on also carry a GitHub build attestation for every published file. Checking it needs GitHub CLI 2.49 or later; older versions, including the 2.45 Ubuntu packages, do not have the command:

gh attestation verify cinder-installer-windows-x64.exe -R superwilso/Cinder

A pass means the file was produced by .github/workflows/release.yml in this repository, from the commit the tag points at — signed through Sigstore, so it cannot be forged by whoever uploads a file. What it does not cover (D7): the installer is still unsigned for SmartScreen, and the ARM payload inside it is committed rather than built on the runner, so for those bytes the attestation leans on tools/release.sh's rebuild-and-compare manifest (D4).

There aren't any published security advisories