[Bug]: wolfSSL_provide_quic_data fails with certain amount of input data #8156
Assignees
Labels
Comments
|
Hi tatsuhiro-t, Thanks for the in-depth bug report, I'm reviewing this with the team. |
|
Hi @kareem-wolfssl. Is there any estimate on fixing this please? This bug is causing instability of certain test cases with ngtcp2 server in quic-interop testsuite. |
|
Hi @vranem1, My apologies for the delay on this, I'm assigning this to my colleague who will review it shortly. |
julek-wolfssl
added a commit
to julek-wolfssl/wolfssl
that referenced
this issue
Jan 8, 2025
0-return from quic_record_append is an error. `quic_record_complete(qr) || len == 0` is not an error condition. We should return as normal on success. The issue is that passing in buffers with length 1 then 3 causes `qr_length` (in `quic_record_make`) to return 0. Then when `quic_record_append` gets called the `len` gets consumed by the first `if` and `len == 0` is true. This causes the error return which is not correct behaviour. Reported in wolfSSL#8156. Reproducing is a bit tricky. I couldn't get the docker to work. First setup ngtcp2 as described in https://github.com/ngtcp2/ngtcp2/pkgs/container/ngtcp2-interop. The Relevant steps are (I tested with master/main branches of all libs): ``` $ git clone --depth 1 -b v5.7.4-stable https://github.com/wolfSSL/wolfssl $ cd wolfssl $ autoreconf -i $ # For wolfSSL < v5.6.6, append --enable-quic. $ ./configure --prefix=$PWD/build \ --enable-all --enable-aesni --enable-harden --enable-keylog-export \ --disable-ech $ make -j$(nproc) $ make install $ cd .. $ git clone --recursive https://github.com/ngtcp2/nghttp3 $ cd nghttp3 $ autoreconf -i $ ./configure --prefix=$PWD/build --enable-lib-only $ make -j$(nproc) check $ make install $ cd .. $ git clone --recursive https://github.com/ngtcp2/ngtcp2 $ cd ngtcp2 $ autoreconf -i $ # For Mac users who have installed libev with MacPorts, append $ # LIBEV_CFLAGS="-I/opt/local/include" LIBEV_LIBS="-L/opt/local/lib -lev" $ ./configure PKG_CONFIG_PATH=$PWD/../wolfssl/build/lib/pkgconfig:$PWD/../nghttp3/build/lib/pkgconfig \ --with-wolfssl $ make -j$(nproc) check ``` Download and unzip https://github.com/user-attachments/files/17621329/failing.pcap.zip From the ngtcp2 dir: ``` ./examples/wsslserver 127.0.0.1 44433 /path/to/wolfssl/certs/server-key.pem /path/to/wolfssl/certs/server-cert.pem ``` Then run the following python script (`failing.pcap` has to be available in the running dir) (probably needs to be run as `sudo`): ``` from scapy.utils import rdpcap, PcapNgReader from scapy.all import * reader = PcapNgReader("failing.pcap") for i in reader: p = i[IP] p.dport = 44433 p.dst = "127.0.0.1" p[UDP].chksum=0 p.display() send(p) ``` Then observe the log line: ``` I00000000 0xa48accb7b49ec1556ac7111c64d3a4572a81 frm tx 625216795 Initial CONNECTION_CLOSE(0x1c) error_code=CRYPTO_ERROR(0x100) frame_type=0 reason_len=0 reason=[] ``` You can also use `gdb` and place a break inside the following section in `wolfssl/src/quic.c`. ``` if (quic_record_complete(qr) || len == 0) { return 0; } ```
|
Hi All, please see the fix and analysis at #8340. Juliusz |
|
Reverted in #8352 |
julek-wolfssl
added a commit
to julek-wolfssl/wolfssl
that referenced
this issue
Jan 16, 2025
0-return from quic_record_append is an error. `quic_record_complete(qr) || len == 0` is not an error condition. We should return as normal on success. The issue is that passing in buffers with length 1 then 3 causes `qr_length` (in `quic_record_make`) to return 0. Then when `quic_record_append` gets called the `len` gets consumed by the first `if` and `len == 0` is true. This causes the error return which is not correct behaviour. Reported in wolfSSL#8156. Reproducing is a bit tricky. I couldn't get the docker to work. First setup ngtcp2 as described in https://github.com/ngtcp2/ngtcp2/pkgs/container/ngtcp2-interop. The Relevant steps are (I tested with master/main branches of all libs): ``` $ git clone --depth 1 -b v5.7.4-stable https://github.com/wolfSSL/wolfssl $ cd wolfssl $ autoreconf -i $ # For wolfSSL < v5.6.6, append --enable-quic. $ ./configure --prefix=$PWD/build \ --enable-all --enable-aesni --enable-harden --enable-keylog-export \ --disable-ech $ make -j$(nproc) $ make install $ cd .. $ git clone --recursive https://github.com/ngtcp2/nghttp3 $ cd nghttp3 $ autoreconf -i $ ./configure --prefix=$PWD/build --enable-lib-only $ make -j$(nproc) check $ make install $ cd .. $ git clone --recursive https://github.com/ngtcp2/ngtcp2 $ cd ngtcp2 $ autoreconf -i $ # For Mac users who have installed libev with MacPorts, append $ # LIBEV_CFLAGS="-I/opt/local/include" LIBEV_LIBS="-L/opt/local/lib -lev" $ ./configure PKG_CONFIG_PATH=$PWD/../wolfssl/build/lib/pkgconfig:$PWD/../nghttp3/build/lib/pkgconfig \ --with-wolfssl $ make -j$(nproc) check ``` Download and unzip https://github.com/user-attachments/files/17621329/failing.pcap.zip From the ngtcp2 dir: ``` ./examples/wsslserver 127.0.0.1 44433 /path/to/wolfssl/certs/server-key.pem /path/to/wolfssl/certs/server-cert.pem ``` Then run the following python script (`failing.pcap` has to be available in the running dir) (probably needs to be run as `sudo`): ``` from scapy.utils import rdpcap, PcapNgReader from scapy.all import * reader = PcapNgReader("failing.pcap") for i in reader: p = i[IP] p.dport = 44433 p.dst = "127.0.0.1" p[UDP].chksum=0 p.display() send(p) ``` Then observe the log line: ``` I00000000 0xa48accb7b49ec1556ac7111c64d3a4572a81 frm tx 625216795 Initial CONNECTION_CLOSE(0x1c) error_code=CRYPTO_ERROR(0x100) frame_type=0 reason_len=0 reason=[] ``` You can also use `gdb` and place a break inside the following section in `wolfssl/src/quic.c`. ``` if (quic_record_complete(qr) || len == 0) { return 0; } ```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Contact Details
No response
Version
master
Description
wolfSSL_provide_quic_data fails if certain amount of data is given.
See ngtcp2/ngtcp2#1403 for the detailed explanation and the pointer to the possible offending code.
Reproduction steps
See ngtcp2/ngtcp2#1403
Relevant log output
No response
The text was updated successfully, but these errors were encountered: