Hi, my system observed a segfault due to a NULL-pointer deref. I'm running my "own" webserver (lighttpd2) with `mod_gnutls`. I'm on debian bookworm with `libgnutls30:amd64 3.7.9-2+deb12u4`. ## Backtrace The backtrace showed: ``` #0 0x00007f3a111347cb in _gnutls_figure_common_ciphersuite (session=session@entry=0x56541a3e7400, peer_clist=peer_clist@entry=0x7ffd18645340, ce=ce@entry=0x7ffd18645338) at ../../../lib/algorithms/ciphersuites.c:1567 #1 0x00007f3a110491b2 in _gnutls_server_select_suite (session=session@entry=0x56541a3e7400, data=data@entry=0x565419cb8845 "\023\001\023\002\023\003\300+\300,̩\300/\3000̨\300\023\300\024", datalen=datalen@entry=30, scsv_only=scsv_only@entry=0) at ../../lib/handshake.c:1158 #2 0x00007f3a1104bfad in read_client_hello (datalen=<optimized out>, data=0x565419cb8800 "\003\003q\317\036\265\0270\310@\027\353\203/\211\326\306<\027\312\371\306\343\363\252-v\017\004\252\245\001\n_ \355\025>o&\204\\\vQ\026\024t6\377\231\021\217\266\254\275\250s\227\237\022\257\024e\204\216\377<", session=0x56541a3e7400) at ../../lib/handshake.c:862 #3 _gnutls_recv_handshake (session=session@entry=0x56541a3e7400, type=type@entry=GNUTLS_HANDSHAKE_CLIENT_HELLO, optional=optional@entry=0, buf=buf@entry=0x0) at ../../lib/handshake.c:1641 #4 0x00007f3a11042edd in _gnutls13_handshake_server (session=session@entry=0x56541a3e7400) at ../../lib/handshake-tls13.c:381 #5 0x00007f3a1104f3e0 in handshake_server (session=<optimized out>) at ../../lib/handshake.c:3491 #6 gnutls_handshake (session=0x56541a3e7400) at ../../lib/handshake.c:2887 #7 0x00007f3a112e4a9f in do_gnutls_handshake (f=0x565419c7c470, writing=0) at ../src/modules/gnutls_filter.c:278 ... (this is mod_gnutls from lighttpd2) ``` The debian source has the same line numbers, so this should be here: https://gitlab.com/gnutls/gnutls/-/blob/3.7.9/lib/algorithms/ciphersuites.c?ref_type=tags#L1566-1568 Line 1567 is the second one here: ```c if (session->internals.hsk_flags & HSK_PSK_SELECTED) { if (session->key.binders[0].prf->id != session->internals.priorities->cs.entry[j]->prf) break; ``` ## Some inspected data I could have a memory corruption in my code, but I think this is unlikely here; the GnuTLS state looks basically "well". ``` session->internals.hsk_flags = 0x0801c008 (HSK_HRR_SENT | HSK_PSK_KE_MODE_DHE_PSK | HSK_PSK_SELECTED | HSK_KEY_SHARE_SENT | HSK_OCSP_REQUESTED) session->security_parameters.pversion->id = GNUTLS_TLS1_3 session->security_parameters.pversion->tls13_sem = true session->internals.resumption_requested = true session->internals.priorities->cs.entry[j]->prf = GNUTLS_MAC_SHA384 session->key.binders is completely zeroed. ``` That is: `HSK_PSK_SELECTED` is set, but `session->key.binders[0].prf` is NULL. ## Guesses My guess is that the first client-hello had a good (session resumption) PSK, but for some reasons HRR was triggered, which leads to a call to `reset_binders()`, which clears the binders - but doesn't reset the corresponding `hsk_flags`. The time the second client-hello arrived the PSK expired (?), so binders didn't get set again, but the flags still indicate its presence. I think one should be able to trigger this manually: * first get a proper session PSK from a normal session * in a new connection: * send PSK but send empty (or invalid?) key_share extension -> triggers HRR * send second client-hello without PSK (or an invalid one) -> segfault I didn't manage to do that yet; crafting client hellos manually seems non-trivial (while copying proper PSK data from "good" sessions). As far as I can tell current git HEAD didn't change anything (`HSK_PSK_SELECTED` never gets cleared from `psk_flags` explicitly, binders still get reset). ## Received / sent data Sadly I don't have the full handshake data the client sent. My server received 1177 bytes (including the handshake that is currently parsed) and sent 99 bytes (HRR + CCS). ### current receive buffer 608 bytes in lighttpd2 tcp read buffer: * change-cipher-spec + record header for client-hello ``` 00000000 14 03 03 00 01 01 16 03 03 02 55 |..........U| ``` * followed by the session.internals.full_client_hello ### current client hello ``` session.internals.full_client_hello (597 bytes) 00000000 01 00 02 51 03 03 71 cf 1e b5 17 30 c8 40 17 eb |...Q..q....0.@..| 00000010 83 2f 89 d6 c6 3c 17 ca f9 c6 e3 f3 aa 2d 76 0f |./...<.......-v.| 00000020 04 aa a5 01 0a 5f 20 ed 15 3e 6f 26 84 5c 0b 51 |....._ ..>o&.\.Q| 00000030 16 14 74 36 ff 99 11 8f b6 ac bd a8 73 97 9f 12 |..t6........s...| 00000040 af 14 65 84 8e ff 3c 00 1e 13 01 13 02 13 03 c0 |..e...<.........| 00000050 2b c0 2c cc a9 c0 2f c0 30 cc a8 c0 13 c0 14 00 |+.,.../.0.......| 00000060 9c 00 9d 00 2f 00 35 01 00 01 ea 00 00 00 15 00 |..../.5.........| 00000070 13 00 00 10 72 73 73 2e 73 74 62 75 65 68 6c 65 |....rss.stbuehle| 00000080 72 2e 64 65 00 17 00 00 ff 01 00 01 00 00 0a 00 |r.de............| 00000090 08 00 06 00 1d 00 17 00 18 00 0b 00 02 01 00 00 |................| 000000a0 23 00 00 00 10 00 0e 00 0c 02 68 32 08 68 74 74 |#.........h2.htt| 000000b0 70 2f 31 2e 31 00 05 00 05 01 00 00 00 00 00 0d |p/1.1...........| 000000c0 00 14 00 12 04 03 08 04 04 01 05 03 08 05 05 01 |................| 000000d0 08 06 06 01 02 01 00 33 00 47 00 45 00 17 00 41 |.......3.G.E...A| 000000e0 04 69 a3 9a c4 d4 fa c1 90 aa 9c d9 4f c3 ab f5 |.i..........O...| 000000f0 93 e3 42 d0 84 be dd ae fd 80 c1 17 44 e0 a8 c1 |..B.........D...| 00000100 a1 cf d4 e7 89 20 c2 1c 43 34 ae 1d 1d ab cb 0a |..... ..C4......| 00000110 b4 7e c7 3e a8 8e 51 73 b1 7c 92 30 e7 81 d0 c1 |.~.>..Qs.|.0....| 00000120 6f 00 2d 00 02 01 01 00 2b 00 05 04 03 04 03 03 |o.-.....+.......| 00000130 00 29 01 21 00 ec 00 e6 24 d9 7c 7b eb 71 59 fe |.).!....$.|{.qY.| 00000140 09 de be 29 17 94 db 40 25 05 cf d5 09 b4 2d b3 |...)...@%.....-.| 00000150 91 1c a6 a8 87 04 ae 35 00 b0 ee 60 b4 eb 69 c1 |.......5...`..i.| 00000160 1d c1 35 9b 5f be ad f4 58 8f e8 7c c4 ad 4a 94 |..5._...X..|..J.| 00000170 b9 85 ae ec fd 59 a6 d8 8c 3b 76 25 9f 1e 95 8e |.....Y...;v%....| 00000180 0b 03 f9 31 ba 53 50 cd b5 35 b5 a6 34 8a 78 a4 |...1.SP..5..4.x.| 00000190 f9 ee 06 db e4 bb 40 6b ac 6f 42 12 86 5a df 1a |......@k.oB..Z..| 000001a0 08 81 41 cb 11 60 94 1d 94 57 fb fb 49 32 8d d0 |..A..`...W..I2..| 000001b0 c9 cf 31 1e f4 77 45 aa f5 85 2a 77 a2 45 e9 7c |..1..wE...*w.E.|| 000001c0 6e bb 56 1f 71 9e a7 80 ac 6e 0e cd cb f6 48 c9 |n.V.q....n....H.| 000001d0 1c 9b a4 0b b9 8d ce 09 38 c1 d4 16 50 c1 14 11 |........8...P...| 000001e0 b0 6a 6c 30 79 cb 30 ed 01 d8 5f 41 46 d4 d6 32 |.jl0y.0..._AF..2| 000001f0 ca f5 59 ee 3d 9a 8f b9 96 c7 55 3c f6 2d 7d 53 |..Y.=.....U<.-}S| 00000200 69 12 4e f9 a3 6c 39 99 f8 d2 f8 e1 ee db 27 e7 |i.N..l9.......'.| 00000210 20 b5 99 21 8f 9f 7b 07 7e a7 3c ed 14 c8 1c 55 | ..!..{.~.<....U| 00000220 ed 26 00 31 30 e6 51 a3 0f 24 02 b1 00 23 e0 aa |.&.10.Q..$...#..| 00000230 6c e1 fb 6e 42 93 8f 47 05 b6 2c 1a 4c 35 0e c1 |l..nB..G..,.L5..| 00000240 53 fc 7e c3 8c e9 e5 39 41 eb ec 05 64 f7 9b 77 |S.~....9A...d..w| 00000250 b7 1c 4f cc 97 |..O..| ``` ### sent data The sent data (from lighttpd2 buffers): ``` 00000000 16 03 03 00 58 02 00 00 54 03 03 cf 21 ad 74 e5 |....X...T...!.t.| 00000010 9a 61 11 be 1d 8c 02 1e 65 b8 91 c2 a2 11 16 7a |.a......e......z| 00000020 bb 8c 5e 07 9e 09 e2 c8 a8 33 9c 20 ed 15 3e 6f |..^......3. ..>o| 00000030 26 84 5c 0b 51 16 14 74 36 ff 99 11 8f b6 ac bd |&.\.Q..t6.......| 00000040 a8 73 97 9f 12 af 14 65 84 8e ff 3c 13 02 00 00 |.s.....e...<....| 00000050 0c 00 33 00 02 00 17 00 2b 00 02 03 04 14 03 03 |..3.....+.......| 00000060 00 01 01 |...| ``` ### handshake_hash_buffer 737 bytes in session.internals.handshake_hash_buffer.data: * client-hello1 stub message (message_hash): ``` 00000000 fe 00 00 30 8f 15 13 98 66 8c 8a 1a 31 a1 f5 54 |...0....f...1..T| 00000010 c7 27 4d b8 5b ea 24 08 36 9d b6 74 11 84 d4 58 |.'M.[.$.6..t...X| 00000020 8e e8 a9 52 5e 8b 46 9f ea 5c bd a4 d2 26 d6 7a |...R^.F..\...&.z| 00000030 bf 60 1a b6 |.`..| ``` * HRR (server-hello) ``` 00000000 02 00 00 54 03 03 cf 21 ad 74 e5 9a 61 11 be 1d |...T...!.t..a...| 00000010 8c 02 1e 65 b8 91 c2 a2 11 16 7a bb 8c 5e 07 9e |...e......z..^..| 00000020 09 e2 c8 a8 33 9c 20 ed 15 3e 6f 26 84 5c 0b 51 |....3. ..>o&.\.Q| 00000030 16 14 74 36 ff 99 11 8f b6 ac bd a8 73 97 9f 12 |..t6........s...| 00000040 af 14 65 84 8e ff 3c 13 02 00 00 0c 00 33 00 02 |..e...<......3..| 00000050 00 17 00 2b 00 02 03 04 |...+....| ``` * second client-hello: 597 bytes, same as session.internals.full_client_hello