Poll panic on corrupted input

[pothos]

I've seen a similar trace for mismatch of equal slice length for both left: 6, right: 0 and left: 4, right: 4. Here is only the one for 6, but I guess the one for 4 is about parsing the IPv4 address.

I don't see the problem rightnow because it looks like new_checked is used in process_ethernet. And there is a match for 6 and 4 for packet.hardware_len() and packet.protocol_len() in ArpPacket::parse Ideas?

panicked at 'assertion failed: `(left == right)`
  left: `6`,
 right: `0`: destination and source slices have different lengths', libcore/slice/mod.rs:1618:9                                                      
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:475
   5: std::panicking::continue_panic_fmt
             at libstd/panicking.rs:390
   6: rust_begin_unwind
             at libstd/panicking.rs:325
   7: core::panicking::panic_fmt
             at libcore/panicking.rs:77
   8: smoltcp::wire::ethernet::Address::from_bytes
   9: smoltcp::wire::arp::Repr::parse
  10: smoltcp::iface::ethernet::InterfaceInner::process_ethernet

[dlrobertson]

Do you have a packet capture of the packet that caused this?

[pothos]

Unfortunately not, but I'll try to reproduce it with a somehow patched version that dumps the packet (sounds possible) or maybe in gdb…

[pothos]

Maybe this issue was outside of smoltcp. I can reopen if not.

[pothos]

Yes, it was due to a buffer being used twice. Sorry for the noise ;)