Fix input/output filtering to ASCII
authorMarkus Armbruster <armbru@pond.sub.org>
Sat, 2 Jul 2011 07:09:27 +0000 (09:09 +0200)
committerMarkus Armbruster <armbru@pond.sub.org>
Sat, 9 Jul 2011 13:14:00 +0000 (15:14 +0200)
copy_utf8_to_ascii_no_funny() eats the character following a replaced
non-ASCII character.  Buffer overrun possible when the terminating
zero gets eaten.  Broken in commit b5ff7e3b, v4.2.21.

Affected commands:

* players column "last command" in ASCII sessions: struct player
  member combuf is UTF-8, uprnf() filters to ASCII.

* read in ASCII sessions: telegram chunks are UTF-8, uprnf() filters
  to ASCII.

* flash and wall with message argument in ASCII sessions: argument is
  used raw, i.e. UTF-8, pr_flash() filters to ASCII.  Safe as long as
  we have input filtering sanitizing the raw argument.  command() does
  that, but execute() doesn't (bug, to be fixed in a later commit).

* execute prompting for its argument in UTF-8 sessions: prmptrd()
  receives user text, and filters to ASCII.

Unaffected:

* dispatch() argument redir is UTF-8, uprnf() can filter to ASCII.
  Safe as long as we have input filtering sanitizing the raw argument.
  command() does that.  execute() doesn't, but rejects redirections
  before calling dispatch().

* getele() buffer is UTF-8, uprnf() can filter to ASCII.  Safe,
  because its contents comes from uprmptrd(), which filters input.

src/lib/subs/pr.c

index 5cf6833d7e11d76b54b74f5dc2ff5af9a09c9f02..bde5918cb08bf6fb0eb848728cc992cba21d95d4 100644 (file)
@@ -563,7 +563,8 @@ copy_utf8_to_ascii_no_funny(char *dst, char *src)
            ;                   /* ignore funny control */
        else if (ch > 0x7f) {
            *p++ = '?';         /* replace non-ASCII */
-           while ((*src++ & 0xc0) == 0x80) ;
+           while ((*src & 0xc0) == 0x80)
+               src++;
        } else
            *p++ = ch;
     }