use-after-free in worker_sets_extend/worker_update_flags

[mstrand]

 78 worker_sets_extend (worker_sets *ws,
...
 86         void *ptr = NULL;
 87         ptr = realloc (ws->events, sizeof (struct kevent) * to_allocate);
 88         if (ptr == NULL) {

realloc can move ws->events to a different memory location, thus invalidating all pointers in ws->watches[...]->event.

These pointers are then dereferenced in worker_update_flags:

410 worker_update_flags (worker *wrk, watch *w, uint32_t flags)
...
415     w->flags = flags;
416     w->event->fflags = inotify_to_kqueue (flags, w->is_really_dir, 0);
417 
...
428                 depw->flags = flags;
429                 depw->event->fflags = inotify_to_kqueue (flags, ...
430             }

w->event can here point to freed memory, or into some other data structure.

In this core dump I found, they pointed into the ws->watches array after reallocation. The upper 32 bits of some pointers have been corrupted when w->event->fflags has been set by following an invalid pointer.

(gdb) x/32xg $rcx
0x81149ac00:    0x0000000000000000      0x0000000811418280
0x81149ac10:    0x0000000811418490      0x00000008114184c0
0x81149ac20:    0x00000008114184f0      0x0000001e11418520 <--
0x81149ac30:    0x0000000811418550      0x0000000811418580
0x81149ac40:    0x00000008114185b0      0x0000001e114185e0 <--
0x81149ac50:    0x0000000811418610      0x0000000811418640
0x81149ac60:    0x0000000811418670      0x0000001e114186a0 <--
0x81149ac70:    0x00000008114186d0      0x0000000811418700
0x81149ac80:    0x00000008114187f0      0x0000001e114187c0 <--
0x81149ac90:    0x0000000811418820      0x00000008114188b0
0x81149aca0:    0x00000008114188e0      0x0000000811418880
0x81149acb0:    0x0000000811418940      0x00000008114189a0
0x81149acc0:    0x00000008114189d0      0x0000000811418a00
0x81149acd0:    0x0000000811418a30      0x0000000811418a60
0x81149ace0:    0x0000000811418a90      0x0000000811418ac0
0x81149acf0:    0x0000000811418b20      0x0000000811418b50

The corrupted pointers caused a subsequent crash in worker_add_or_modify.

[dmatveev]

Wow, shame on me.

I know that Vladimir Kondratiev did some work on refactoring and rewriting my design failures - there is still the pull request pending with a major changes (shame on me x2).

I will try to do my best to get it merged, and then will check if the issue will still exist.

Thank you for the report!

[wulf7]

Mstrand, could you check integrate-dmatveev branch from wulf7/libinotify-kqueue repository. It does not store watches in array, so most probably this issue should go away