| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com> | 
| Cc: | pgsql-bugs <pgsql-bugs(at)postgresql(dot)org> | 
| Subject: | Re: [PATCH] Fix segfault calling PQflush on invalid connection | 
| Date: | 2022-08-15 01:44:07 | 
| Message-ID: | 819197.1660527847@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-bugs | 
Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com> writes:
> PQflush calls pqFlush, which performs struct access to the connection
> without checking if it's valid, resulting in a segfault if called with
> a null pointer.
> Please find attached a patch adding a guard to PQflush().
Seems reasonable, but this tickled a thought that's been in my
hindbrain for awhile: just checking for a null pointer is not
much of a check for being passed a valid PGconn pointer.  Should
we add a magic number to struct PGconn, and modify all libpq's
entry points along the lines of
	if (!conn || conn->magic != PGCONN_MAGIC)
		return failure;
I'm honestly not entirely sure if this is worth the trouble;
I've not heard of many application bugs that this would've caught.
But the lack of any such check does seem like it's not up to
modern standards.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | 巨鲸 | 2022-08-15 02:27:26 | Re: BUG #17580: use pg_terminate_backend to terminate a wal sender process may wait a long time | 
| Previous Message | Daniele Varrazzo | 2022-08-15 00:44:55 | [PATCH] Fix segfault calling PQflush on invalid connection |