x/net/html: html.Parse() panic caused by malformed data

[tr3ee]

What did you do?

package main

import (
	"strings"

	"golang.org/x/net/html"
)

func main() {
	r := strings.NewReader("<template><object>")
	html.Parse(r)
}

What did you expect to see?

No panic exit

What did you see instead?

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x0 pc=0x4905d6]

goroutine 1 [running]:
golang.org/x/net/html.(*parser).parseCurrentToken(0xc042052410)
        D:/GoWorkspace/src/golang.org/x/net/html/parse.go:2193 +0x86
golang.org/x/net/html.(*parser).parse(0xc042052410, 0xc0420a4000, 0xc042052340)
        D:/GoWorkspace/src/golang.org/x/net/html/parse.go:2219 +0x62
golang.org/x/net/html.Parse(0x4e0d80, 0xc0420024c0, 0xc0420681e0, 0xc042071f78, 0xc04204a058)
        D:/GoWorkspace/src/golang.org/x/net/html/parse.go:2236 +0xe2
main.main()
        D:/GoWorkspace/src/poc.go:11 +0x7a
exit status 2

Analysis

There are many reasons for panic, but the main reason is:
golang.org/x/net/html.inTemplateIM() does not handle some special TokenTypes,
meanwhile golang.org/x/net/html.(*parser)popUntil() does handle these special TokenTypes, thus causing panic.

Other test cases that cause the same problem:

<template><applet>
<template><marquee>

System details

go version go1.10.3 windows/amd64
GOARCH="amd64"
GOBIN=""
GOEXE=".exe"
GOHOSTARCH="amd64"
GOHOSTOS="windows"
GOOS="windows"
GOPATH="D:\GoWorkspace"
GORACE=""
GOROOT="C:\Go"
GOTMPDIR=""
GOTOOLDIR="C:\Go\pkg\tool\windows_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOROOT/bin/go version: go version go1.10.3 windows/amd64
GOROOT/bin/go tool compile -V: compile version go1.10.3
gdb --version: GNU gdb (GDB) 8.1

[tr3ee]

CVE-2018-17075 has been assigned to this.

[dmitshur]

I can't reproduce this with the current golang.org/x/net/html. Is this still an open issue? Perhaps it got resolved during changes for #23071, likely CL 123776.

[tr3ee]

@dmitshur
yes, It's fixed with commit aaf60122140d3fcf75376d319f0554393160eb50.

[dmitshur]

Great! We can close this issue then, if there's nothing more to do here.

[namusyaka]

Closing in favor of #23071