Bug 1411021

The same F23 bug was reported on EL7 as well:
https://gitlab.com/ocserv/ocserv/issues/89


Please add an ABI check as part of the upgrade cycle.

+++ This bug was initially created as a clone of Bug #1374081 +++

http-parser recently got updated from 2.0-9.20121128gitcd01361.fc23 to 2.7.1-2.fc23.

Since then, ocserv segfaults when accepting connections:

[root@shinybook tests]# valgrind  /usr/sbin/ocserv -d 1 -f -c configs/test-user-cert.config
==2261== Memcheck, a memory error detector
==2261== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==2261== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==2261== Command: /usr/sbin/ocserv -d 1 -f -c configs/test-user-cert.config
==2261== 
Skipping unknown option 'cookie-validity'
Parsing plain auth method subconfig using legacy format
Setting 'certificate+plain' as primary authentication method
listening (TCP) on 0.0.0.0:443...
listening (TCP) on [::]:443...
listening (UDP) on 0.0.0.0:443...
listening (UDP) on [::]:443...
ocserv[2261]: main: not using control unix socket
ocserv[2261]: main: initialized ocserv 0.10.12
ocserv[2263]: sec-mod: reading supplemental config from files
ocserv[2263]: sec-mod: sec-mod initialized (socket: ./ocserv-socket.2261)
ocserv[2261]: main: processed 1 CA certificate(s)
ocserv[2272]: worker:  tlslib.c:379: no certificate was found
==2272== Conditional jump or move depends on uninitialised value(s)
==2272==    at 0x5E1FFC4: http_parser_execute (http_parser.c:1927)
==2272==    by 0x11B6B0: vpn_server (worker-vpn.c:520)
==2272==    by 0x115869: main (main.c:1265)
==2272== 
==2272== Use of uninitialised value of size 8
==2272==    at 0x5E1FFE3: http_parser_execute (http_parser.c:1927)
==2272==    by 0xBFAD1AF: ???
==2272==    by 0x11B6B0: vpn_server (worker-vpn.c:520)
==2272==    by 0x115869: main (main.c:1265)
==2272== 
==2272== Jump to the invalid address stated on the next line
==2272==    at 0x6F6974616D726F66: ???
==2272==    by 0x6F6973726576206B: ???
==2272==    by 0x2022302E31223D6D: ???
==2272==    by 0x676E69646F636E64: ???
==2272==    by 0x22382D465455223C: ???
==2272==    by 0x666E6F633C0A3E3E: ???
==2272==    by 0x20687475612D6768: ???
==2272==    by 0x223D746E65696C62: ???
==2272==    by 0x70797420226E7075: ???
==2272==    by 0x2274696E69223D64: ???
==2272==    by 0x6F69737265763C3D: ???
==2272==    by 0x76223D6F6877206D: ???
==2272==  Address 0x6f6974616d726f66 is not stack'd, malloc'd or (recently) free'd
==2272== 
==2272== 
==2272== Process terminating with default action of signal 11 (SIGSEGV)
==2272==  Bad permissions for mapped region at address 0x6F6974616D726F66
==2272==    at 0x6F6974616D726F66: ???
==2272==    by 0x6F6973726576206B: ???
==2272==    by 0x2022302E31223D6D: ???
==2272==    by 0x676E69646F636E64: ???
==2272==    by 0x22382D465455223C: ???
==2272==    by 0x666E6F633C0A3E3E: ???
==2272==    by 0x20687475612D6768: ???
==2272==    by 0x223D746E65696C62: ???
==2272==    by 0x70797420226E7075: ???
==2272==    by 0x2274696E69223D64: ???
==2272==    by 0x6F69737265763C3D: ???
==2272==    by 0x76223D6F6877206D: ???
==2272== 
==2272== HEAP SUMMARY:
==2272==     in use at exit: 249,462 bytes in 851 blocks
==2272==   total heap usage: 3,114 allocs, 2,263 frees, 1,302,359 bytes allocated
==2272== 
==2272== LEAK SUMMARY:
==2272==    definitely lost: 8,448 bytes in 2 blocks
==2272==    indirectly lost: 0 bytes in 0 blocks
==2272==      possibly lost: 42,521 bytes in 30 blocks
==2272==    still reachable: 125,789 bytes in 818 blocks
==2272==         suppressed: 72,704 bytes in 1 blocks
==2272== Rerun with --leak-check=full to see details of leaked memory
==2272== 
==2272== For counts of detected and suppressed errors, rerun with: -v
==2272== Use --track-origins=yes to see where uninitialised values come from
==2272== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
ocserv[2261]: main: [::1]:54118 user disconnected (rx: 0, tx: 0)
ocserv[2261]: main: main.c:521: Child 2272 died with sigsegv

--- Additional comment from David Woodhouse on 2016-09-07 18:35:02 EDT ---

Rebuilding ocserv against the new http-parser 'fixes' it. Did the library break binary compatibility without updating its soname?