Repository navigation
2.8.0 release #5122
Description
Activity
- pinned this issue
on Sep 22, 2026 Automotive related changes:
- Added SAE J1939 support
- Added standalone UDS/KWP/OBD/GMLAN packets
- Improved CAN/ISO-TP soft-socket robustness
- Added configurable busy-response retries in automotive scanners
Looks like the commit fixing that issue causes python to segfault when
scapyis in libpcap mode and packets are captured withsniffon 32-bit NetBSD machines at least. I'll double-check but it seems that with that commit reverted it doesn't crash.Thanks @evverx, I think I can see why. The underlying problem predates that commit; the commit just exposed it.
Scapy describes libpcap's packet header with a timestamp made of two C
longs (scapy/libs/winpcapy.py, which despite its name holds the libpcap bindings on every platform). On 32-bit NetBSD the timestamp's seconds field is 64 bits, so the real timestamp is bigger than Scapy expects, and every field after it has always been read from the wrong place. On i386, for example:- the field Scapy calls
lenactually holds the captured length, so the old code happened to read the right number of bytes; - the field Scapy calls
caplenactually holds the timestamp's microseconds (0 to 999,999), so once the fix switched tocaplen, it copies up to about a megabyte from a small packet and crashes.
If that's right, reverting would bring back the original over-read everywhere else, so the header itself needs fixing. Other 32-bit systems with a 64-bit timestamp may be affected too (OpenBSD, musl, Debian armhf), but I haven't tested those.
I'm working on a fix. It would help to know your NetBSD version and architecture, and whether the packet timestamps from
sniffthere look wrong. They should, if this is the cause, both before and after that commit. On i386 I'd expect the microseconds to come out as 0 on every packet.- the field Scapy calls
It's
NetBSD nbsd32 11.0 NetBSD 11.0 (GENERIC)and the analysis looks correct. 30b872b addressed a 64-bit-time_t-related issue in another place (NetBSD switched to 64-bit in https://www.netbsd.org/releases/formal-6/NetBSD-6.0.html).If that's right, reverting would bring back the original over-read everywhere else
I'm not saying it should be reverted. It's just that the python segfault on receiving packets should probably be addressed before 2.8.0 is tagged.
Reacted by GabrielThanks for confirming. I could reproduce the bad reads on a NetBSD 10.1 i386 VM (reading a pcap file, so no crash, but up to 734,512 bytes from a 60-byte packet), and the fix is in #5209.
The layout there is as I described, with
caplenat byte 12 where Scapy expected 8. The same problem affects musl and 64-bit-time glibc on 32-bit ARM and x86. There, packets came back empty before the GHSA fix, and it crashes after it.
WIP
This issue tracks the upcoming 2.8.0 release.
Expected date:
01/10/202602/10/2026.Deprecation notice
Note
We have clarified our CONTRIBUTING and SECURITY guidelines. This notably includes some new guidance related to the use of AI, and some instructions regarding the submission of security issues. We encourage contributors to take a moment to read the updated versions.
Security
Scapy has taken part in
OpenAI + Trail of Bitscollab's initiative called "Patch the Planet". As part of this initiative, we have received a free security coverage of our code overseen by @KernelClint (Trail of Bits) and multiple OpenAI agents. This has led to the discovery of around 130+ bugs, among which were 54 issues that could be considered related to security, with various degrees of severity. You can find a partial list on https://github.com/secdev/scapy/security/advisories and here but please bear in mind that some reports have been written entirely by AI.After analysis, we have marked 5 vulnerabilities with a "High" level of impact, which justify an immediate upgrade to
2.8.0, or backporting if packaged by downstream repositories:NetflowSessionrunning foreverThe other issues have been triaged as "Moderate" or "Low" and don't justify immediate action from users or downstream package maintainers (those include crashes, issues in various protocol implementations, automatons and answering machines, mis-implementations of protocols like our TLS stack, etc. but nothing that leads to a potential compromission of the host machine).
We would like to thank again
OpenAIandTrail of Bits(and in particular @KernelClint) for this opportunity and the time spent on this project.Changelog
smbclient()features