Bug 1836773 - POST followed by a GET with large headers on the same connection leads to a NULL dereference
Summary: POST followed by a GET with large headers on the same connection leads to a N...
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: curl
Version: 7.7
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Kamil Dudka
QA Contact: Daniel Rusek
Depends On:
Blocks: 1844432
TreeView+ depends on / blocked
Reported: 2020-05-18 06:05 UTC by Hisanobu Okuda
Modified: 2020-09-29 19:53 UTC (History)
3 users (show)

Fixed In Version: curl-7.29.0-59.el7
Doc Type: No Doc Update
Doc Text:
Clone Of:
: 1844432 (view as bug list)
Last Closed: 2020-09-29 19:53:37 UTC
Target Upstream Version:

Attachments (Terms of Use)
reproducer (11.10 KB, application/gzip)
2020-05-18 06:05 UTC, Hisanobu Okuda
no flags Details

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2020:3916 0 None None None 2020-09-29 19:53:46 UTC

Description Hisanobu Okuda 2020-05-18 06:05:11 UTC
Created attachment 1689514 [details]

Description of problem:
POST followed by a GET with large headers on the same connection leads to a NULL dereference and segfaults.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. yum install libcurl
2. ./post-get-crash

Then it crashes as follows:

Program terminated with signal 11, Segmentation fault.
#0  __GI__IO_fread (buf=0x1e248d8, size=1, count=16384, fp=0x0) at iofread.c:37
warning: Source file is more recent than executable.
37        _IO_acquire_lock (fp);
(gdb) bt
#0  __GI__IO_fread (buf=0x1e248d8, size=1, count=16384, fp=0x0) at iofread.c:37
#1  0x00007f59f5f72373 in Curl_fillreadbuffer (conn=conn@entry=0x1e43fc0, bytes=bytes@entry=16384, nreadp=nreadp@entry=0x7ffc2ecf1cf0) at transfer.c:120
#2  0x00007f59f5f72f4f in readwrite_upload (didwhat=<synthetic pointer>, k=0x1e24030, conn=0x1e43fc0, data=0x1e24000) at transfer.c:841
#3  Curl_readwrite (conn=0x1e43fc0, done=done@entry=0x7ffc2ecf1d6f) at transfer.c:1034
#4  0x00007f59f5f7cc3b in multi_runsingle (multi=multi@entry=0x1e2ce00, now=..., easy=easy@entry=0x1ef9800) at multi.c:1485
#5  0x00007f59f5f7d5e1 in curl_multi_perform (multi_handle=multi_handle@entry=0x1e2ce00, running_handles=running_handles@entry=0x7ffc2ecf1e60) at multi.c:1763
#6  0x00007f59f5f747f3 in curl_easy_perform (easy=0x1e24000) at easy.c:480
#7  0x0000000000400cca in send_get (handle=0x1e24000) at post-get-crash.c:82
#8  0x0000000000400d78 in main (argc=1, argv=0x7ffc2ecf2bc8) at post-get-crash.c:111

In the frame 0, fp=0 causes segfault.

Actual results:

Expected results:

Additional info:

Comment 3 Hisanobu Okuda 2020-05-21 01:59:45 UTC
The customer pointed out the fix is included in https://github.com/curl/curl/commit/4ad8e142da463ab208d5b5565e53291c8e5ef038.
I built libcurl.so with curl-7.29.0-58.el7.src.rpm + the commit, and I confirmed no segfault is observed.

Comment 4 Kamil Dudka 2020-05-21 17:02:55 UTC
Thank you for providing the reproducer and link to the upstream fix!  I am able to reproduce the crash locally.

Comment 20 errata-xmlrpc 2020-09-29 19:53:37 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: curl security update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.