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

[tttex at mailbox.org]

Thanks for your reply and for looking into this, Karl.

Indeed it is the same underlying issue that Igor reported, namely that there is no check to ensure that scaling the font design size does not result in a font size of 2048 pt or larger (which can lead to crashes or unexpected font sizes).

This might be a case of 'you get what you asked for', similar to overflow when adding scaled values, it just did not strike me as such when reading the code of Part 30. In contrast to integer overflows where it is explicitly mentioned that those are not checked for ("The present implementation of TeX does not check for overflow when dimensions are added or subtracted." in module 104.), I could not find it stated that the result of scaling a font must be less than 2048 pt. The only statements that imply that this is a requirement are in module 571 where it says that we know z to be less than 2^{27} as well as in the error message for too large at-sizes in module 1259. For that reason, I had the impression that there was a check missing in the code.

>From David Fuchs reply, I take that there are pathological conditions (such as integer overflows) where a deliberate choice was made to not deal with them. I would love to learn more about how these trade-offs are/were made. I noticed for example that mitigations were made against ligature loops which I would have expected are a rather rare condition. Do you by any chance know any resources you could refer me to?

Should the "scaling overflow" be an issue that you consider having a check for, I would like to point out that apart from adding a check in read_font_info, one would also need to add a check when looking whether the font has already been loaded in module 1260 (ensuring that the last xn_over_d does not overflow).

Kind regards,
Tyge

> Karl Berry <karl at freefriends.org> hat am 22.01.2022 22:44 geschrieben:
> 
>  
> 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