Hi Steve,
Many thanks for reproducing this and for offering a the detailed
explanation. I would be happy to forward your findings to upstream
(however, my previous issues/PRs on upstream's GitHub have gone
unanswered). For the time being, I must admit I unfortunately do not
have the time to fix it via a patch.
Do you think we should wait for this to be fixed? As I said before I
(just from my practical point of view) would be in favor of just
removing the problematic architectures.
Cheers
Sascha
On 13.04.22 22:39, Steve Langasek wrote:
Note that this will consistently fail alignment checks on architectures
which require alignment, because the initial buffer is allocated with
reasonable alignment (32bit) but the ethernet header is 14 bytes long, so
the TCP header fields will always be unaligned within the buffer.
On Wed, Apr 13, 2022 at 01:20:49PM -0700, Steve Langasek wrote:
Here is a backtrace of the armhf SIGBUS.
Note that not all ARM implementations return SIGBUS which is probably why
this was not reproducible on the porter machine.
# gdb --args pktanon -c /usr/share/doc/pktanon/examples/profiles/profile.xml
./profiles/sample.pcap ./out.pcap
[...]
Reading symbols from pktanon...
Reading symbols from
/usr/lib/debug/.build-id/af/1ac53f46ae133c8898358966960cba95ac7a70.debug...
(gdb) run
Starting program: /usr/bin/pktanon -c
/usr/share/doc/pktanon/examples/profiles/profile.xml ./profiles/sample.pcap
./out.pcap
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
-----------------------------------------------
pktanon --- profile-based traffic anonymization
-----------------------------------------------
initializing PktAnon, configuration =
/usr/share/doc/pktanon/examples/profiles/profile.xml
unknown element: pktanon-config: 37
unknown element: anonymizations: 102
istream: opened file ./profiles/sample.pcap
ostream: opened output file ./out.pcap
initialized
Program received signal SIGBUS, Bus error.
pktanon::TcpPacketTransformation::transform (this=<optimized out>, source_buffer=<optimized
out>, destination_buffer=0xfffef35a "\212y\262X\335\300l\221", max_packet_length=40) at
transformations/TcpPacketTransformation.cpp:88
88 hton32 (output_header->ack_num);
(gdb) bt
#0 pktanon::TcpPacketTransformation::transform (this=<optimized out>,
source_buffer=<optimized out>,
destination_buffer=0xfffef35a "\212y\262X\335\300l\221",
max_packet_length=40) at transformations/TcpPacketTransformation.cpp:88
#1 0x0040b77c in pktanon::IPv4PacketTransformation::transform (this=0x4b4eb0,
source_buffer=<optimized out>, destination_buffer=0xfffef346 "E",
max_packet_length=<optimized out>)
at transformations/IPv4PacketTransformation.cpp:153
#2 0x0040af64 in pktanon::EthernetPacketTransformation::transform (
this=0x4ad780, source_buffer=<optimized out>,
destination_buffer=0xfffef338
"\376\212\a\213\001\254\303\341\372DI\355\b", max_packet_length=74) at
transformations/EthernetPacketTransformation.cpp:53
#3 0x00416862 in pktanon::transform_packet (stats=...,
packet_len=<optimized out>,
transformed_packet=0xfffef338 "\376\212\a\213\001\254\303\341\372DI\355\b",
original_packet=0xfffef438 "", record_header=...) at Utils.h:26
#4 pktanon::IstreamInput::read_packets (this=0x4b3ce0)
at IstreamRecordsHandler.cpp:121
#5 0x00415130 in pktanon::PktAnonRuntime::run () at PktAnonRuntime.cpp:37
#6 0x00405bfa in main (argc=<optimized out>, argv=<optimized out>)
at src/Main.cpp:73
(gdb)
So, this is trying to do an hton32() operation on a field that is not 4-byte
aligned.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
