Re: apparent bug about check_free_strict

> On 24. Nov 2025, at 16:46, Dan Carpenter <[email protected]> =
wrote:
>=20
> Hi Toomas,
>=20
> I've recently re-written the check for use after frees.  Could you
> retest?  I have another fix for use after free which I'm going to
> send tomorrow hopefully...
>=20
> regards,
> dan carpenter
>=20
>=20

I do have the latest HEAD and yes, it is still there. It=E2=80=99s not a =
single isolated case, on whole illumos kernel tree its 10 cases.

It *may* be related, but I have stepped on on some curious SIGSEGV case =
too:

tsoome@balrog:/code/illumos-gate/usr/src/cmd/diskinfo$ mdb core=20
Loading modules: [ libumem.so.1 libc.so.1 ld.so.1 ]
> ::stack -t
struct expression * cast_expression+0xf((struct expression *)NULL, =
(struct symbol *)fffff7ffe9334610)
void fake_return_assignment+0x74((struct db_callback_info =
*)fffff7ffffdf0520, (int)405, (int)ffffffff, (char *)1a31938, (char =
*)1a31e38)
int db_assign_return_states_callback+0x2ef((void *)fffff7ffffdf0520, =
(int)6, (char **)1a324e8, (char **)1a324b8)
int libsqlite3.so.3.50.4`sqlite3_exec+0x559()
void sql_exec+0x1b6((struct sqlite3 *)1a0ab98, (int (*)())4e543f, (void =
*)fffff7ffffdf0520, (const char *)fffff7ffffdefd70)
void sql_select_return_states+0x396((const char *)5a2908, (struct =
expression *)fffff7ffec1d6960, (int (*)())4e543f, (void =
*)fffff7ffffdf0520)
int db_return_states_assign+0x89((struct expression *)fffff7ffebff5e70)
void match_assign_call+0x70((struct expression *)fffff7ffebff5e70)
void __pass_to_client+0x57((void *)fffff7ffebff5e70, (enum =
hook_type)CALL_ASSIGNMENT_HOOK)
void parse_assignment+0x2a0((struct expression *)fffff7ffebff5e70, =
(_Bool)0)
void __split_expr+0x317((struct expression *)fffff7ffebff5e70)
void __split_expr+0x644((struct expression *)fffff7ffec1d6780)
void parse_assignment+0x134((struct expression *)fffff7ffebff5ce0, =
(_Bool)0)
void __split_expr+0x317((struct expression *)fffff7ffebff5ce0)
void __split_expr+0x578((struct expression *)fffff7ffec1d6780)
void __split_stmt+0x3e2((struct statement *)fffff7ffea4849f8)
void __split_stmt+0x4c8((struct statement *)fffff7ffea4849a0)
void __split_stmt+0x56b((struct statement *)fffff7ffea484948)
void __split_stmt+0x4c8((struct statement *)fffff7ffea4848f0)
void __split_stmt+0x56b((struct statement *)fffff7ffea484898)
void __split_stmt+0x442((struct statement *)fffff7ffea4828a0)
void handle_pre_loop+0x17f((struct statement *)fffff7ffea482848)
void __split_stmt+0x886((struct statement *)fffff7ffea482848)
void __split_stmt+0x442((struct statement *)fffff7ffea482060)
void split_function+0x113((struct symbol *)fffff7ffeb3c0d30)
void smatch+0x3e3((struct string_list *)fffff7ffef2c1590)
int main+0x18f((int)33, (char **)fffff7ffffdf1ea8)
_start_crt+0x87()
_start+0x18()
>=20

there we also do get some data from sql but for some reason we end up =
passing NULL pointer to cast_expression where it is not expected. I=E2=80=99=
m trying to figure out how to spot the location from source code the =
smatch is processing there, some hints about it would be much welcome;)

rgds,
toomas=