> For instance, if I do "./budget.pdf", I expect it to run the code from my pdf reader. In this case, an attack would require exploiting a vulnerability in the pdf reader. That is to say, budget.pdf is not untrusted code, but rather untrusted data.

You cannot simply do ./budget.pdf. If you don't have the executable bit set you'd get a permission denied error (since that file doesn't have permission to execute). And even if you did have the execution bit set, it would fail because there isn't an interpreter configured to execute a pdf (which is the point of binfmt_misc in this context).

The executable bit is what Linux / UNIX / et al use to set whether something is executable code or not. Not the file extension (like in Windows).

> However, in this case the unstrusted data can claim that it is code; in which case it would be executed as such.

Not without setting the executable bit first. (eg chmod +x budget.pdf)

> In contrast, when I do `evince budget.pdf`, the only way for budget.pdf to become code is to trick the pdf reader into thinking it is code.

Two points:

1/ PDFs technically are code though. They're Turing complete.

2/ running `evince budget.pdf` is exactly the same as running `./budget.pdf` where PDF's are mapped to evince via binfmt_misc. Just as running `./my-script.sh` is literally the same as running `/bin/sh ./my-script.sh` (where the shebang is /bin/sh). So your example and counter-example are actually the same process getting called by the kernel.

It's the same thing with binaries that don't have a shebang, such as ELFs. There is a magic header (which the article mentions so I wont reiterate that) and if the binary is identified as an ELF binary so the kernel runs it by calling the ld loader, eg:

   /lib64/ld-linux-x86-64.so.2 /bin/sleep 10

(you can actually run this yourself from Bash too)