Hi, I've found several potential issues in picoTCP v1.7.0 and picoTCP-NG v2.1. While it's difficult for these bugs to actually have an impact, I still think it's worth letting you know about and fixing these potential issues.

1. Integer Overflow in pico_icmp4_send_echo

The parameter cookie of function pico_icmp4_send_echo is completely controllable by the developer. When the cookie->size is set to a large value, an integer overflow will occur when calculating transport_len (Line 393). PICO_ICMPHDR_UN_SIZE is specified as 8, so overflow occurs when the value of cookie->size larger than 65528.

If developers use PicoTCP to develop applications and allow remote visitors to set cookie->size, it may lead to out-of-bounds read and write, which may eventually lead to information leakage and even remote code execution.

2. Integer Overflow in pico_socket_fionread

I think there are two potential integer overflows in the pico_socket_fionread function. When a packet that is too short is received, an integer underflow may occur when calculating f->payload_len of the received packet. This issue may occur when UDP packets are less than 8 bytes ([Line 1619]) or IPV4 packets are less than 20 bytes ([Line 1633). (just like CVE-2020-17443)
Although I didn't find where to call pico_socket_fionread, but to be on the safe side, I hope you can fix both issues.

Hi,

Please, what is the recommended way to report security issues?

I have written a custom device to my application to allow PicoTCP to send and receive data over raw sockets on Linux. (e.g. using socket (AF_PACKET, SOCK_RAW, htons (ETH_P_ALL)), with sendto and recvfrom) which is working well when sending traffic between hosts. (e.g. one app with PicoTCP embedded acting as a TCP server on one host and another app acting as the TCP client on another host).

However, it would be helpful to also run this for testing purposes with both client and server running on the same host (either on a loop-back adapter or even on a physical adapter) . Unfortunately, when the client is listening for its responses on the same IP address as the server it is intending to send it's packets to, rather than the out-bound packets being sent down to the device layer to be written to the link, the client application attempts to process the out-bound packet itself resulting in an error message saying "No such port".

It would seem that the design (understandably) is such that the stack assumes it has exclusive ownership of any IP it is managing, but is there any means to modify this behavior?

I found a security issue in picoTCP v1.7.0 and picoTCP-NG v2.1. It's a double free bug in function pico_fragments_reassemble (Line 362 and Line 364 in modules/pico_fragments.c ).

In function pico_transport_receive, when the switch goes into a default branch, it would release f (Line 239 in stack/pico_stack.c) and return -1. However, after -1 have been return from pico_transport_receive(full, proto) (Line 362 in modules/pico_fragments.c), another pico_frame_discard(full)(Line 364 in modules/pico_fragments.c) would be called and pico_frame_discard release full again. This leads a double free bug.

Hi All,

I am currently trying to port from the original PicoTCP to PicoTCP-NG and ecountered an issue.
As I was not yet able to find the source of the bug, I am kindly asking for your help/advice.

During the Handshake process, the following check in module/pico_tcp.c: tcp_parse_options fails:

static int tcp_parse_options(struct pico_frame *f)
{
    struct pico_socket_tcp *t = (struct pico_socket_tcp *)f->sock;
    uint8_t *opt = f->transport_hdr + PICO_SIZE_TCPHDR;
    uint32_t i = 0;
    f->timestamp = 0;

    if (f->buffer + f->buffer_len > f->transport_hdr + f->transport_len) //THIS CHECK FAILS
        return -1;

   [...]

I added some logging to the function and the output is as follows: (I cutted some output)

[...]
pico_tcp.c:2893: [sam] TCP> [tcp input] t_len: 40
pico_tcp.c:2894: [sam] TCP> flags = 0x02
pico_tcp.c:2895: [sam] TCP> s->state >> 8 = 2
pico_tcp.c:2896: [sam] TCP> [tcp input] socket: 0x1a7014 state: 2 <-- local port:5555 remote port: 59288 seq: 0x5e7f74ae ack: 0x00000000 flags: 0x02 t_len: 40, hdr: 40 payload: 0

pico_tcp.c:897: f->buffer + f->buffer_len (1733274) > f-transport_hdr + f->transport_len(1733270)
pico_tcp.c:898: f->buffer: 1733196 f->buffer_len: 78
pico_tcp.c:898: f-transport_hdr: 1733230 f->transport_len: 40
[...]

This log repeats till the test ist shutdown.

As the above check returns with -1 the frame is discarded and a handshake is never completed.

My understanding is, if the header len is 40, this means no options are present, therefore there are no options to parse.
Would it maybe correct if the return value of the check is instead 0? (in this case its working correct in my test)

I am not sure I 100% understand whats happening here, so I would be very glad if someone had some answers for me.

Kind Regards,
Felix