Contributed by Peter N. M. Hansteen on 2026-04-12 from the AI made me do it dept.

Bogus security bug reports generated by large language model (LLM) tool use are a well known irritant and time sink for open source projects.

As a consequence of one such report, Theo de Raadt (deraadt@) committed a change to pfsync(4) to rename an otherwise unused field in the pfsync(4) packet header.

The commit message reads,

List:       openbsd-cvs
Subject:    CVS: cvs.openbsd.org: src
From:       Theo de Raadt <deraadt () cvs ! openbsd ! org>
Date:       2026-04-12 3:16:04

CVSROOT:	/cvs
Module name:	src
Changes by:	deraadt@cvs.openbsd.org	2026/04/11 21:16:04

Modified files:
	sys/net        : if_pfsync.c if_pfsync.h 

Log message:
The pfcksum[] field in the pfsync packet header is not a hash of the
packet.  It provides absolutely no security benefits, keep reading to
find out.

According to dlg, during early development this field was hopefully
going to be a hash related to the ruleset for optimizing state
match. That approach was abandoned (I guess because ruleset drift
between firewalls happens too often during normal practice). As is
usual in protocol development, at least 6 people were already using
pfsync in production, so for compatibility the field was not
removed...  and forgotten.  On send, it was left as zero, due to
the full-header zero initialization code.

So there is no useful checksum or hash stored in this field called
'pfcksum[PF_MD5_DIGEST_LENGTH]'.  Actually there isn't a single line
of code in the entire tree which writes to this array.  Besides the
field definition in the structure, there is 1 comment elsewhere
mentioning the field.  So no code at all.  I said no code, which is
why there is no code checking it on receive, not even checking if it
is still zero.

An (obviously) AI-assisted report (which I do not intend to share)
arrived which tells us FOR SURE that field is being computed on send,
but not checked on arrival which is a security risk!!!!
It goes into extensive detail saying where various parts of this subsystem
are and how it all fits together but apparently it is all an elaborate
fiction built upon two words 'pfcksum' and 'PF_MD5_DIGEST_LENGTH'.  No
words about security principles are found anywhere in the code or
in the manual page because everyone uses this on a dedicated wire
between firewall boxes.

The human who caused an AI to generate that report did not "peer-review"
the result (hint: the command is grep) before sending it to us, and has
caused David to pull a muscle when his eyes rolled back too far.

To avoid future confusion by AI+humans, rename the field from
pfcksum[PF_MD5_DIGEST_LENGTH] to spare[16].
ok dlg

In a related commit, Theo also updated the pfsync(4) man page with clearer words about the security, or rather lack of, in the protocol itself.

This means, dear friends, that in the upcoming OpenBSD 7.9 release, pfsync(4) will have improved documentation as well as a spare field in its packet header.