For the e1000 bug - I have not read the code in question, and I am not an expert at this layer (I am mostly interested in IPv6 further up the stack) but the logical bug described makes sense. It is a mistake which someone might make if they did not understand what the hardware does with Jumbograms and thus that they're expected to throw all the little pieces away in this scenario. So unless someone who understands the e1000 hardware says they've checked this out and it's bullshit, I'd be inclined to assume it's genuine.
Fixing the symptom and not the bug remains disappointingly common in the Linux kernel (and to be fair, elsewhere in software development too).
However, keep in mind that this talk insisted on repeatedly assuming that they (a hypothetical grey or black hatted individual) were doing all this because other options had failed for them. In practice on most networks those methods will work - this is a hole in a perimeter fence, but in most cases the gates are not guarded and so they don't even need a hole. So don't rush out to patch your fence unless you're one of those rare network administrators who genuinely knows the front gate is secure (in this case, that individual hardware ports are locked to specific MAC source addresses).
The 8169 bug appears to be (at least partly) hardware related. It would be interesting to see whether this is guarded against in drivers from anyone else, including the Windows drivers from the hardware vendor. The size underflow shown in passing is embarrassing, but if the hardware ought to never give zero size, it is understandable that the driver programmer doesn't check for that.