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-21 02:49:58 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jan ONDREJ 2012-05-28 13:44:05 UTC
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-06-01 03:01:56 UTC
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 20:53:12 UTC
*** Bug 836738 has been marked as a duplicate of this bug. ***

Comment 3 Michael Schwendt 2012-06-30 20:54:37 UTC
(!)

From bug 827919 comment 3:

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

(!)

Comment 4 Michael Schwendt 2012-06-30 20:54:58 UTC
*** Bug 827919 has been marked as a duplicate of this bug. ***

Comment 5 Michael Schwendt 2012-06-30 21:04:03 UTC
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 12:57:26 UTC
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 10:59:50 UTC
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 14:06:08 UTC
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-18 01:21:43 UTC
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 07:39:35 UTC
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 07:40:11 UTC
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 09:59:04 UTC
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 14:13:55 UTC
*** Bug 828660 has been marked as a duplicate of this bug. ***

Comment 14 Thomas Woerner 2012-07-18 15:05:38 UTC
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 09:08:29 UTC
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 09:20:58 UTC
iptables-1.4.14-2.fc17.x86_64 fixes the problem here
i left karma.....

Comment 17 stepglenn 2012-07-19 13:07:14 UTC
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-21 02:49:58 UTC
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.