Thank you @tr3ee for reporting this issue!

/cc @nigeltao @namusyaka

CVE-2018-17142 has been assigned to this.

@namusyaka (already @-mentioned) wrote the <template> parsing code, and is probably the best person to fix this.

@bradfitz may know if we need to do anything with the CVE identifier.

The CVE existing in a comment in this bug is sufficient (for searchability).

Not sure if this helps, as I don't know much about the HTML parsing spec, but I was looking into this being a new contributor and trying to learn the code base... it seems like the Insertion Mode struct attribute for parser is nil, causing a nil pointer dereference error.

I don't mind diving into it further to see about finding the root cause and fix it if @namusyaka wouldn't mind and isn't already working on it.

EDIT: As an alternative and/or temporary fix... @tr3ee what are your thoughts on using defer, panic, recover

https://blog.golang.org/defer-panic-and-recover

package main

import (
  "fmt"
  "strings"

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

func rescue() {
  r := recover()

  if r != nil {
    // Necessary logic to follow to recover from panic
  }
}

func main() {
  defer rescue()
  r := strings.NewReader("<math><template><mo><template>")
  html.Parse(r)
}

hello @NerdsvilleCEO ,
this type of fix is not recommended and can only be used as a temporary mitigation effect, which can have an impact on performance.

@nigeltao what do you think about doing a nil pointer check and returning an error from parseCurrentToken if p.im is nil? I know it doesn't fix it at the root of the issue but it's a start, are there any disadvantages to doing this?

The proper fix is to not set p.im to nil in the first place.

I can take a look at this tomorrow or in a few days

Change https://golang.org/cl/136875 mentions this issue: html: don't set im if <template> doesn't have HTML namespace