Fix NO_CAST.INTEGER_OVERFLOW in libev ev.c array_nextsize#515
Fix NO_CAST.INTEGER_OVERFLOW in libev ev.c array_nextsize#515mikhailnov wants to merge 1 commit intolinux-audit:masterfrom
Conversation
Add explicit casts to size_t in arithmetic expressions to prevent potential integer overflow when calculating array sizes. Overflows are not very realistic, but improve code robustness and make analyzers happy. Svace reports: 1) The value of 'elem * ncur' may overflow (ev.c:2259) 2) The value of 'ncur + elem + (MALLOC_ROUND - 1)' may overflow (ev.c:2262) 3) The value of 'elem * *cur' may overflow (ev.c:2275) (CWE190, CWE197) Co-authored-by: Z.AI GLM-5
|
Thanks for looking at this. But I really don't like changing libev much. The reason why is it has it's own upstream. Every libev release requires remembering everything that needs patching. Maybe libev upstream would like the patch? They don't use git. You'd have to submit it to their mail list. |
|
Ok, I will try. I also thought where to send this patch - here or to libev, but saw that other similar fixes were commited here. It is not clear how libev copy is maintained here: is it a fork with its own direction of development or a frequently synced fork with minimal changes. Maybe document this somewhere? |
|
Libev here is mostly an unpacking of the distribution tar file. I have removed the io_uring backend because it was so full of bugs it kept drawing patches to fix it. Otherwise, I have applied a few essential patches that upstream says is my compiler's fault. (06d6355) But I don't want to diverge too much from upstream. I suppose I could add a note and link to the commit for full transparency. It's been almost 6 years since there was a release. I may wind up maintaining at some point. |
Add explicit casts to size_t in arithmetic expressions to prevent potential integer overflow when calculating array sizes.
Overflows are not very realistic, but improve code robustness and make analyzers happy.
Svace reports:
(CWE190, CWE197)