From: | vignesh C <vignesh21(at)gmail(dot)com> |
---|---|
To: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | initdb SegFault |
Date: | 2019-11-19 14:34:04 |
Message-ID: | CALDaNm0ubwYDzbdYG5ezr6_qLodFM7KGoUJJJQQOBXe6_r=ZEQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Hi,
While checking initdb code, I found one segmentation fault, stack
trace for the same is:
Core was generated by `./initdb -D data6'.
Program terminated with signal 11, Segmentation fault.
#0 0x000000000040ea22 in main (argc=3, argv=0x7ffc82237308) at initdb.c:3340
3340 printf(_("\nSuccess. You can now start the database server
using:\n\n"
Analysis for the same is given below:
createPQExpBuffer allocates memory and returns the pointer, there is a
possibility that createPQExpBuffer can return NULL pointer in case of
malloc failiure, but initdb's main function does not check this
condition. During malloc failure when pointer is accessed it results
in segmentation fault. Made changes to check and exit if
createPQExpBuffer return's NULL pointer. Patch for the same is
attached.
Let me know your thoughts for the same. Similar issue exists in few
other places, if changes are ok, I can check and fix the issue in
other places also.
Regards,
Vignesh
EnterpriseDB: http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
0001-initdb-crash-fix-when-createPQExpBuffer-returns-NULL.patch | text/x-patch | 1.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Dolgov | 2019-11-19 14:38:42 | Re: Failed assertion clauses != NIL |
Previous Message | Manuel Rigger | 2019-11-19 14:31:43 | No = operator for opfamily 426 |
From | Date | Subject | |
---|---|---|---|
Next Message | Nicolas Lutic | 2019-11-19 15:15:14 | Re: PITR on DROP DATABASE, deleting of the database directory despite the recovery_target_time set before. |
Previous Message | Julien Rouhaud | 2019-11-19 14:27:27 | Re: Planning counters in pg_stat_statements (using pgss_store) |