[tex-k] Potential bugs in TFM loading in TeX

[Karl Berry]

    Subject: [tex-k] Potential bugs in TFM loading in TeX

Thanks for the reports. We think it is the same underlying cause as what
Igor reported in https://tug.org/pipermail/tex-k/2021-June/003604.html
but I'll check further when I can.

If anyone else is interested in implementing overflow checks, David
Fuchs wrote the following about the earlier report. --thanks, karl.

From: David Fuchs

[...]

Yes, since beta is zero, I also get a divide-by-zero on

  sw:=(((((d*z)div@'400)+(c*z))div@'400)+(b*z))div beta;

But the actual problem is way earlier, since beta shouldn't even be able
to be zero to begin with:

@!alpha:integer;@!beta:1..16;

Looking down in <Replace |z|...> it seems that alpha got all the way to
512, so when it does

beta:=256 div alpha;

the assignment to beta is out of the expected range and read_font_info
fails here if range-checking is on.

So, new_font does <Scan the font size specification> which was supposed
to have checked for too-big magnification.  It gets it right for
"at-size", but there's no way it can see if the "scaled" value is too
big, since it depends on the design-size found in the tfm, which it
hasn't read yet.  So, that check would have to happen later, when it
calls read_font_info, and learns the design-size.  Perhaps in <Read the
{\.{TFM}} header> can check that z isn't too big just before it does
font_size[f]:=z;

That all said, I'm thinking this is not an oversight, but as you
suggest, a case of "don't do that; you get what you deserve" like the
integer-overflow cases.  -drf