On 2022-11-21, at 22:52:18 +0000, Jeremy Sowden wrote: > On 2022-11-14, at 19:12:58 +0100, Pablo Neira Ayuso wrote: > > On Mon, Nov 14, 2022 at 12:47:52PM -0500, Robert O'Brien wrote: > > > I will create a bug report and attach an example ulogd > > > configuration file that demonstrates the issue. > > > > OK. > > > > > I will send a patch using git send-email and mention it in my bug > > > report. What is the email address to where I should send the > > > patch? > > > > Please use netfilter-devel@xxxxxxxxxxxxxxx so patchwork catches this > > patch. > > I think there are at least a couple more places where IP addresses are > not correctly handled: > > https://git.netfilter.org/ulogd2/tree/output/sqlite3/ulogd_output_SQLITE3.c?h=ulogd-2.0.8&id=79aa980f2df9dda0c097e8f883a62f414b9e5138#n176 > https://git.netfilter.org/ulogd2/tree/filter/raw2packet/ulogd_raw2packet_BASE.c?h=ulogd-2.0.8&id=79aa980f2df9dda0c097e8f883a62f414b9e5138#n647 > > I'll see if I can find any others. Didn't find any other endianness bugs, but there are assumptions in some of the output plug-ins that all `ULOGD_RET_IPADDR` values are IPv4 addresses that can be treated as uint32_t values, which is not valid. One possibility would be to handle all IP addresses internally as in IPv6 format (i.e., convert IPv4 addresses to `::ffff:w.x.y.z` -- this is what the IP2BIN filter does) and then convert the IPv4 addresses back on output. J.
Attachment:
signature.asc
Description: PGP signature
