Hi Kevin, On 2026-06-30T13:05:27+0800, Kevin J. McCarthy wrote: > I don't think any of these are high priority, except perhaps for !198. I'd > appreciate anyone willing to take a look at these and add their feedback.
Hmmm, !198 is interesting, not only for the bug it reports, but as a
reminder that there's another bug: overflow in the multiplication in
realloc(3) calls.
The solution to overflow in realloc(3) calls must be solved by calling
reallocarray(3). I already solved this problem in neomutt(1) a few
years ago.
neomutt.git 404938be1053 (2024-11-14; "Use mutt_mem_reallocarray()")
reallocarray(3) is in POSIX.1-2024, and is relatively portable:
glibc 2.26, OpenBSD 5.6, FreeBSD 11.0
However, it is missing at least in a current system: MacOS. The good
news is that it's trivial to implement if it's missing.
neomutt.git 8919dcdd2b63 (2024-11-15; "mutt/memory.c: Add
reallocarray() implementation if missing")
> Mutt in general hasn't placed hard limits all over, because in general
> people connecting to IMAP/POP3 servers have some implicit trust in the host
> of their email, unlike just a random website.
>
> * https://gitlab.com/muttmua/mutt/-/merge_requests/198
> This one seems okay to me. It seems right that the blen should be the same
> type as len.
I haven't looked much into it, but it seems reasonable.
> * https://gitlab.com/muttmua/mutt/-/merge_requests/199
> No comment on this one for now.
>
> * https://gitlab.com/muttmua/mutt/-/merge_requests/200
> This one has an extra "garbage" file placed inside contrib. A pretty dead
> giveaway that this is just an agent. Otherwise no comment.
I don't like this one.
> * https://gitlab.com/muttmua/mutt/-/merge_requests/201
> No comment on this one for now.
>
> Again, I would greatly appreciate anyone who has the time to take a look at
> the patches too. I'll try to do so this weekend.
Have a lovely day!
Alex
--
<https://www.alejandro-colomar.es>
signature.asc
Description: PGP signature
