Bug 1836773

Summary: POST followed by a GET with large headers on the same connection leads to a NULL dereference
Product: Red Hat Enterprise Linux 7 Reporter: Hisanobu Okuda <hokuda>
Component: curlAssignee: Kamil Dudka <kdudka>
Status: CLOSED ERRATA QA Contact: Daniel Rusek <drusek>
Severity: high Docs Contact:
Priority: urgent    
Version: 7.7CC: fkrska, kdudka, lnykryn
Target Milestone: rcKeywords: ZStream
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: curl-7.29.0-59.el7 Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of:
: 1844432 (view as bug list) Environment:
Last Closed: 2020-09-29 19:53:37 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1844432    
Attachments:
Description Flags
reproducer none

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

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):
libcurl-7.29.0-57.el7.x86_64

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.

https://access.redhat.com/errata/RHSA-2020:3916