v2.1.1

WaveFlow Server 2.1.1

Superseded by 2.1.2. The check this release added can be walked around by a WAV built for the purpose, and it refuses some large files that are sound. Upgrade to 2.1.2, which closes both. Security advisory: GHSA-6qhc-763f-95v3.

A security release. One audio file with a crafted tag could crash the server, and keep crashing it on every restart. Every release from 2.0.0 to 2.1.0 is affected, and so are the standalone archives that 2.1.0 introduced. Nothing else changes, so upgrade as soon as you can.

Security

• A file whose ID3v2 chapter frames nest no longer crashes the server. A chapter frame (CHAP or CTOC) can hold frames of its own, and the tag readers recursed once per nested level, without limit. A tag of a few kilobytes was enough to overflow the stack, which aborts the whole process and cannot be caught from inside it.

  The file could arrive in two ways. An account allowed to upload to a library could send it: the server put it in the library, then crashed reading it. Or it could be placed in a scanned folder, where the next scan read it. Either way the file stayed in the library, so the scan at start-up met it again and the server crashed on every restart, until someone found the file and removed it by hand.

  The server now measures how deep a tag's chapter frames nest before reading it, in every format, and in the ID3 tag a DSF or DFF file carries. One chapter frame inside another is not refused: the limit is three levels under the first, well short of the depth that overflows the stack, and nothing real nests them at all. Past that limit:

  • an upload of the file is refused with 422, and the file is taken back out of the library. Should the disk allow neither moving it back nor deleting it, the answer is 503 instead and the file stays, where a scan now refuses it rather than crashing on it;
  • a scan records an error for the file and goes on with the rest;
  • the server stays up, and starts normally.

  A real chapter layout, with a table of contents, titled chapters, links and pictures, is read as before. The check refuses rather than risks a crash, so a file that repeats the names CHAP or CTOC several times in a place a reader does not always read to its end can be refused too.

  What was demonstrated is a loss of availability: the process aborts on a stack overflow. No effect on what the server discloses or stores was observed. The fix is #426.

Known limit: a large file refused by mistake

The check gives up on a file, and refuses it, once it has read 64 MiB of it. Two shapes of file make it read that much although they hold no chapter frame at all:

• a WAV or an AIFF that carries a chunk of odd length ahead of its audio;
• a file that is neither, with the letters RIFF or FORM in its first 64 KiB, such as a FLAC that keeps the chunks of the WAV it was made from (flac --keep-foreign-metadata).

This was measured on files built for the purpose, not on files found in a library: at 70 MiB each of the three was refused, and at 10 MiB each passed.

For such a file the scan counts an error and the file does not appear in the library, or its upload is answered 422. The reason given speaks of nested chapter frames, though there are none. The file itself is never changed. A refused file is read again, and refused again, by every scan. A file that was already in the library before the upgrade is not: an ordinary scan does not open a track's file while it has not changed, so the track stays as it is. #428 tracks the fix.

If you cannot upgrade yet

• Turn uploads off on every library, or leave upload rights only with people you trust.
• If your server already crashes at every start, remove the file from the library folder. It is usually the audio file uploaded or added last.

Install

docker run -d --name waveflow \
  -p 4533:4533 \
  -v waveflow-data:/data \
  -v /path/to/music:/music:ro \
  ghcr.io/instazdll/waveflow-server:2.1.1

The image runs on linux/amd64 and linux/arm64, and is the same, digest for digest, on Docker Hub as instazdll/waveflow-server:2.1.1. latest now follows this release. The standalone archives for Windows, macOS and Linux are attached below, with SHA256SUMS over all of them.

Upgrading from 2.1.0

Pull 2.1.1 and start it on the same data volume. With an archive, use the new folder in place of the old one, carrying over what you changed in laptop.env: your data is kept apart from that folder. The database schema has not changed, so there is nothing to migrate, and 2.1.0 still opens the same data should you need to go back.

A server that crashed on such a file needs nothing more than the upgrade: 2.1.1 starts, its scan records an error for the file, and the file stays where it is until you remove it.

Coming from 2.0.1 or earlier, read the 2.1.0 notes first: that upgrade changes the schema and measures every lossless file again.

Full changelog: CHANGELOG.md · v2.1.0...v2.1.1

Download

The server for one computer, without Docker: extract the archive and start waveflow-server inside it. Each archive holds the server, its own FFmpeg and a README.txt to read first.

System	Archive
Windows (x86_64)	waveflow-server-2.1.1-windows-x86_64.zip
macOS (Apple silicon)	waveflow-server-2.1.1-macos-arm64.zip
macOS (Intel)	waveflow-server-2.1.1-macos-x86_64.zip
Linux (x86_64)	waveflow-server-2.1.1-linux-x86_64.tar.gz
Linux (arm64)	waveflow-server-2.1.1-linux-arm64.tar.gz

The Windows executables carry a self-signed certificate and the macOS ones an ad-hoc signature, which neither system trusts, so both warn on the first launch: README.txt says what to click past. SHA256SUMS holds the checksums of them all, and ffmpeg-8.1.3-sources.tar.gz the source of the FFmpeg they carry.

Container image

docker pull ghcr.io/instazdll/waveflow-server:2.1.1

The same image, digest for digest, is on Docker Hub:

docker pull instazdll/waveflow-server:2.1.1

Also published as latest in both, for linux/amd64 and linux/arm64 (a Raspberry Pi 4 or 5 on a 64-bit system).