On Sat, May 04, 2024 at 07:28:01PM +0200, Patrice Dumas wrote: > Hello, > > With texi2any, customization variables can be set in Perl and used in C. > Customization variable strings undef in Perl become NULL char * pointers in > C, which is a natural and convenient representation. Some > customization strings are tested in C code to make sure that they are > not NULL. > > There is another possibility, some customization variables > are reset before the conversion to strings if they are undef. In that > case it is assumed in C that they are never NULL. However, it is > possible to set the variables to undef again, in user-defined > Perl customization code called from C during conversion. It would be > unlikely for that to happen by chance, but could happen on purpose. > In that case, there would be a segfault, described by valgrind as > > Invalid read of size 1 > Access not within mapped region at address 0x0 > > My guess is that it is not a problem in term of security, but I may be > wrong. > > Is it an issue to leave the possibility of incorrect memory access?
In my opinion it is an issue as it should not be possible to cause a segfault purely with Perl code. If there is a segfault this points towards a bug in XS/C code. If the user provides customization code that is purely in Perl it would be very surprising for this to cause a segfault. The customization API should be more robust than this. Without knowing much about the customization API I don't know the best way to protect against this kind of situation but some possibilities are to check for null pointers when accessing cutomization variable values in C, or to disable setting customization variables after this step: "some customization variables are reset before the conversion to strings if they are undef". If user code attempts to do this the program could exit with an error.
