bin/59453: sed 's/^/\x23def/' output '=ef' instead of '#def'

[bad%bsd.de@localhost]

>Number:         59453
>Category:       bin
>Synopsis:       sed 's/^/\x23def/' output '=ef' instead of '#def'
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jun 01 19:05:00 +0000 2025
>Originator:     Christoph Badura
>Release:        10.0
>Organization:
The Loops Are Hard, Let's Go Shopping Foundation
>Environment:
NetBSD morden.netbsd.org 10.0_STABLE NetBSD 10.0_STABLE (NBFTP) #0: Tue May 28 07:18:01 UTC 2024  spz%franklin.NetBSD.org@localhost:/home/netbsd/10/amd64/obj/sys/arch/amd64/compile/NBFTP amd64
>Description:
when processing a 's' command sed(1) does the following:

compile_subst(...): https://nxr.netbsd.org/xref/src/usr.bin/sed/compile.c#340
unescape(...): https://nxr.netbsd.org/xref/src/usr.bin/sed/compile.c#672
ston(&p, sp, 16): https://nxr.netbsd.org/xref/src/usr.bin/sed/compile.c#529
after swalling "\x23" it decides to swallow another digit in
https://nxr.netbsd.org/xref/src/usr.bin/sed/compile.c#504
because at that point r=35 which is less then 255.
after swalling 'd' r=573, the loop terminates and on line 588 that gets truncated to 61 ('=').

Obviously ston() shouldn't p++ if r has become to large.
This was introduce in r1.47 https://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/sed/compile.c.diff?r1=1.47;r2=1.47.16.1

Of course, this would have been discovered early if a test case had been added.

Discovered by leot@.


>How-To-Repeat:
echo | sed 's/^/\x23duh'

>Fix:
Once more with test case, please.
Needs pullup to -10. -9 is fine.