[Please keep 54252@debbugs.gnu.org in CC or To, such that other people
can respond as well, such that discussion is not lost even if the
original reviewers disappear, for transparancy reasons, etc.]

Jai Vetrivelan schreef op za 05-03-2022 om 18:32 [+0530]:
> Hello Maxime,
> 
> On 2022-03-05, 10:59 +0100, Maxime Devos <maximedevos@telenet.be> wrote:
> 
> > At least in the 'master' branch (and presumably also in v1.4), there
> > are a few bugs.  At line 789, the return value of 'malloc' is not
> > checked, potentially causing a null-pointer dereference (and hence, a
> > segfault) at line 790 (in lemonbar.c).
> 
> Do you mean something like this?
> 
> ┌────
> │ diff --git a/lemonbar.c b/lemonbar.c
> │ index 4da59ee..93fcb20 100644
> │ --- a/lemonbar.c
> │ +++ b/lemonbar.c
> │ @@ -785,8 +785,8 @@ font_load (const char *pattern)
> │ 
> │      // Copy over the width lut as it's part of font_info
> │      int lut_size = sizeof(xcb_charinfo_t) * xcb_query_font_char_infos_length(font_info);
> │ -    if (lut_size) {
> │ -        ret->width_lut = malloc(lut_size);
> │ +    ret->width_lut = malloc(lut_size);
> │ +    if (lut_size && ret->width_lut) {
> │          memcpy(ret->width_lut, xcb_query_font_char_infos(font_info), lut_size);
> │      }
> └────

That just ignores the allocation failure, even though possibly the code
will use ret->width_lut later, expecting it to be non-NULL (or maybe it
actually handles NULL, I don't know).  Probably the allocation failure
needs to be reported (printf + exit, or return NULL, or something
else).  The exact mechanism used in C for handling allocation failures
depends on the application.

> > Could this be fixed?
> 
> I am not familiar with the C programming language, so I might not be
> able to fix this.

Ideally, things would be fixed upstream (it's on GitHub so you could
try submitting a pull request).  For Guix though, I believe simply
reporting the potential issue upstream (at
<https://github.com/LemonBoy/bar/issues>) would be sufficient.

Greetings,
Maxime.