Bug 825796

Summary: Wrong parameter passing for iptables -j LOG --log-prefix
Product: [Fedora] Fedora Reporter: Jan ONDREJ <ondrejj>
Component: iptablesAssignee: Thomas Woerner <twoerner>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: alanh, bill, bkurt, bugs.michael, frank, h.reindl, iny, jpopelka, psabata, rambler8, stepglenn, tom, twoerner
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-07-20 22:49:58 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Jan ONDREJ 2012-05-28 09:44:05 EDT
Description of problem:
When loading iptables parameters from /etc/sysconfig/iptables file, --log-prefix and may be other log parameters are not prolerly loaded. 

Version-Release number of selected component (if applicable):
iptables-1.4.12.2-5.fc17.x86_64
kernel-3.3.7-1.fc17.x86_64

How reproducible:
always

Steps to Reproduce:
1. systemctl stop iptables.service
2. iptables -A INPUT -p tcp -m tcp --dport 22 --tcp-flags RST RST -j LOG --log-prefix "TELNET-D " --log-level 3
3. iptables-save > /etc/sysconfig/iptables
4. systemctl restart iptables.service
5. iptables -L INPUT
  
Actual results:
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
LOG        tcp  --  anywhere             anywhere             tcp dpt:sshflags: RST/RST LOG level error prefix "--log-pre"

Expected results:
LOG        tcp  --  anywhere             anywhere             tcp dpt:sshflags: RST/RST LOG level error prefix "TELNET-D "

Additional info:
As you see, TELNET-D has been replace by --log-pre. This started happening in Fedora 17, no same problem in Fedora 16.
Comment 1 Kurt Bechstein 2012-05-31 23:01:56 EDT
I am having the exact same issue in Fedora 17.  My exact same firewall script worked just fine with F16.
Comment 2 Michael Schwendt 2012-06-30 16:53:12 EDT
*** Bug 836738 has been marked as a duplicate of this bug. ***
Comment 3 Michael Schwendt 2012-06-30 16:54:37 EDT
(!)

From bug 827919 comment 3:

Patch available on http://bugzilla.netfilter.org/show_bug.cgi?id=774

(!)
Comment 4 Michael Schwendt 2012-06-30 16:54:58 EDT
*** Bug 827919 has been marked as a duplicate of this bug. ***
Comment 5 Michael Schwendt 2012-06-30 17:04:03 EDT
From http://bugzilla.netfilter.org/show_bug.cgi?id=774 :

| With optimization flags -O1 or higher, this bug kicks in.
| It is a tricky one that the compiler does not catch. No wonder,
| it is undefined behavior.
Comment 6 Jan ONDREJ 2012-07-11 08:57:26 EDT
Ping. Patch looks simple and it's from upstream. Why it's problem to apply it? Can I help?
Comment 7 Harald Reindl 2012-07-16 06:59:50 EDT
it is really NOT funny if iptables are messed up
this is a CORE security component on each system
Comment 8 stepglenn 2012-07-16 10:06:08 EDT
I built IPTables v1.4.14 with optimization turned off
(removed -O2 from Makefiles). Everything seems to work
correctly. The Firewall is operational and log-prefix is
correctly working. So is this a Compiler issue or a
IPTables issue?
Comment 9 Alan Hamilton 2012-07-17 21:21:43 EDT
Yes, I ran into this too. The issue is that the gcc optimizer is optimizing out the code that collects quoted strings in iptables-restore.c at line 396. If inside a quotemark and it hasn't seen another one yet, it executes

   param_buffer[param_len++] = *curchar;
   continue;

At -O1 or higher, the write to param_buffer[] never happens. It just increments param_len and continues.

Moving the definition of char param_buffer[1024]; outside the loop fixes it. Why, I'm not sure. Defining the param_buffer[] inside the loop should simply restrict its scope to inside the loop.
Comment 10 Thomas Woerner 2012-07-18 03:39:35 EDT
The new 1.4.14 version is working for me without the need to change optimization flags. Please have a look at the testing package.
Comment 11 Fedora Update System 2012-07-18 03:40:11 EDT
iptables-1.4.14-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/iptables-1.4.14-1.fc17
Comment 12 Harald Reindl 2012-07-18 05:59:04 EDT
not confirmed!

iptables-1.4.14-1.fc17.x86_64

* iptables updated
* iptables.sh called
* all looked fine first
* after reboot see below
________________________

[root@rh:~]$ /sbin/iptables --list --numeric --verbose | grep LOG
    0     0 LOG        udp  --  br0    *      !10.0.0.0/24          0.0.0.0/0            state NEW recent: UPDATE seconds: 2 hit_count: 70 name: udpflood side: source limit: avg 1/min burst 5 LOG flags 0 level 7 prefix "--log-prefix"
    0     0 LOG        tcp  --  br0    *      !10.0.0.0/24          0.0.0.0/0            state NEW recent: UPDATE seconds: 2 hit_count: 150 name: DEFAULT side: source limit: avg 1/min burst 5 LOG flags 0 level 7 prefix "--log-prefix"
    0     0 LOG        udp  --  bond0  *      !10.0.0.0/24          0.0.0.0/0            state NEW recent: UPDATE seconds: 2 hit_count: 70 name: udpflood side: source limit: avg 1/min burst 5 LOG flags 0 level 7 prefix "--log-prefix"
    0     0 LOG        tcp  --  bond0  *      !10.0.0.0/24          0.0.0.0/0            state NEW recent: UPDATE seconds: 2 hit_count: 150 name: DEFAULT side: source limit: avg 1/min burst 5 LOG flags 0 level 7 prefix "--log-prefix"
    0     0 LOG        udp  --  eth1   *      !10.0.0.0/24          0.0.0.0/0            state NEW recent: UPDATE seconds: 2 hit_count: 70 name: udpflood side: source limit: avg 1/min burst 5 LOG flags 0 level 7 prefix "--log-prefix"
    0     0 LOG        tcp  --  eth1   *      !10.0.0.0/24          0.0.0.0/0            state NEW recent: UPDATE seconds: 2 hit_count: 150 name: DEFAULT side: source limit: avg 1/min burst 5 LOG flags 0 level 7 prefix "--log-prefix"
    0     0 LOG        udp  --  eth0   *      !10.0.0.0/24          0.0.0.0/0            state NEW recent: UPDATE seconds: 2 hit_count: 70 name: udpflood side: source limit: avg 1/min burst 5 LOG flags 0 level 7 prefix "--log-prefix"
    0     0 LOG        tcp  --  eth0   *      !10.0.0.0/24          0.0.0.0/0            state NEW recent: UPDATE seconds: 2 hit_count: 150 name: DEFAULT side: source limit: avg 1/min burst 5 LOG flags 0 level 7 prefix "--log-prefix"
    0     0 LOG        tcp  --  !lo    *      !10.0.0.0/24          0.0.0.0/0            multiport dports 19,24,52,79,109,142,442,464,548,586,631,992,994,3305 limit: avg 10/hour burst 5 LOG flags 0 level 7 prefix "--log-prefix"
Comment 13 Thomas Woerner 2012-07-18 10:13:55 EDT
*** Bug 828660 has been marked as a duplicate of this bug. ***
Comment 14 Thomas Woerner 2012-07-18 11:05:38 EDT
Please have a look at 
https://admin.fedoraproject.org/updates/iptables-1.4.14-2.fc17

I have added the fixrestore patch.
Comment 15 Fedora Update System 2012-07-19 05:08:29 EDT
Package iptables-1.4.14-2.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing iptables-1.4.14-2.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-10826/iptables-1.4.14-2.fc17
then log in and leave karma (feedback).
Comment 16 Harald Reindl 2012-07-19 05:20:58 EDT
iptables-1.4.14-2.fc17.x86_64 fixes the problem here
i left karma.....
Comment 17 stepglenn 2012-07-19 09:07:14 EDT
I loaded the "updates-testing" version on one machine, for testing. It looks like it does fix this BUG. I will wait for the official release to update the other machines. Thanks!
Comment 18 Fedora Update System 2012-07-20 22:49:58 EDT
iptables-1.4.14-2.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.