Bug 2242725 - iptables-save generates wrong data and garbage
Summary: iptables-save generates wrong data and garbage
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: iptables
Version: 37
Hardware: aarch64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Phil Sutter
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-10-08 12:53 UTC by Patrick Monnerat
Modified: 2023-10-21 01:29 UTC (History)
2 users (show)

Fixed In Version: iptables-1.8.9-4.fc38.1
Clone Of:
Environment:
Last Closed: 2023-10-21 01:29:31 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
iptables loading script (505 bytes, application/x-shellscript)
2023-10-08 12:56 UTC, Patrick Monnerat
no flags Details

Description Patrick Monnerat 2023-10-08 12:53:24 UTC
The data output by iptables-save contains data that do not match what has been set by the iptables command (wrong addresses) and garbage in an interface name with wild cards.

Reproducible: Always

Steps to Reproduce:
1. as root, bash testfw.sh
2. iptables-save >output
3. compare output to commands in testfw.sh
Actual Results:
# Generated by iptables-save v1.8.8 (nf_tables) on Sun Oct  8 14:27:23 2023
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
# Completed on Sun Oct  8 14:27:23 2023
# Generated by iptables-save v1.8.8 (nf_tables) on Sun Oct  8 14:27:23 2023
*filter
:INPUT ACCEPT [4:208]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [4:464]
:Anti-spoofing - [0:0]
-A Anti-spoofing -s 3.0.0.0/24 -i ��+ -m mark --mark 0x3/0x3 -j RETURN
-A Anti-spoofing -s 2.0.0.0/24 -m mark --mark 0x2/0x3 -j RETURN
COMMIT
# Completed on Sun Oct  8 14:27:23 2023
# Generated by iptables-save v1.8.8 (nf_tables) on Sun Oct  8 14:27:23 2023
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
# Completed on Sun Oct  8 14:27:23 2023

Expected Results:  
# Generated by iptables-save v1.8.8 (nf_tables) on Sun Oct  8 14:27:23 2023
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
# Completed on Sun Oct  8 14:27:23 2023
# Generated by iptables-save v1.8.8 (nf_tables) on Sun Oct  8 14:27:23 2023
*filter
:INPUT ACCEPT [4:208]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [4:464]
:Anti-spoofing - [0:0]
-A Anti-spoofing -s 192.168.3.0/24 -i + -m mark --mark 0x3/0x3 -j RETURN
-A Anti-spoofing -s 192.168.2.0/24 -m mark --mark 0x2/0x3 -j RETURN
COMMIT
# Completed on Sun Oct  8 14:27:23 2023
# Generated by iptables-save v1.8.8 (nf_tables) on Sun Oct  8 14:27:23 2023
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
# Completed on Sun Oct  8 14:27:23 2023

- I cannot reproduce on an x86_64
- The garbage in the interface name corresponds to the first bytes of the address.
- I don't know if the actual data in the kernel tables are OK (either an iptables or iptables.save problem).

Comment 1 Patrick Monnerat 2023-10-08 12:56:30 UTC
Created attachment 1992934 [details]
iptables loading script

Comment 2 Patrick Monnerat 2023-10-08 23:01:01 UTC
Additional information:
- iptables -L is also affected.
- after some more checks and with the help of logging, kernel filtering seems correct. Thus the setting commands (iptables -A) seem OK and the problem probably lies in some common getter procedure.
- The first (wrongly) generated ip address byte seems to come from the --mask value.

Comment 3 Patrick Monnerat 2023-10-10 11:11:20 UTC
Rebuilding and installing iptables-1.8.9-5.fc39.src.rpm for Fedora 37 aarch64 fixes the problem.

Comment 4 Phil Sutter 2023-10-10 16:55:46 UTC
I think this was implicitly fixed by commit f315af1cf8871 ("nft: track each
register individually") in v1.8.9.

I am currently preparing a stable update for f38 containing a fix. Is updating
to f38 a viable solution for you?

Comment 5 Patrick Monnerat 2023-10-10 17:48:14 UTC
Many thanks for your reply.

> Is updating to f38 a viable solution for you?

I will move directly from f37 to f39 in a very few weeks now! And for the time being, I updated my rpi4s with my custom-build 1.8.9 package, so everything's fine for me, thanks.

Maybe some other f37 aarch64 users are affected and f37 eol is forcast for 2023-11-14: one month. At least they should easily find this report until then.

Comment 6 Phil Sutter 2023-10-11 10:50:19 UTC
OK, thanks for clarifying!

Comment 7 Fedora Update System 2023-10-11 10:54:53 UTC
FEDORA-2023-722ad471a7 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-722ad471a7

Comment 8 Fedora Update System 2023-10-12 02:59:39 UTC
FEDORA-2023-722ad471a7 has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-722ad471a7`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-722ad471a7

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 9 Fedora Update System 2023-10-21 01:29:31 UTC
FEDORA-2023-722ad471a7 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.