Bug 825796 - Wrong parameter passing for iptables -j LOG --log-prefix
Wrong parameter passing for iptables -j LOG --log-prefix
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: iptables (Show other bugs)
17
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Thomas Woerner
Fedora Extras Quality Assurance
:
: 827919 828660 836738 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-28 09:44 EDT by Jan ONDREJ
Modified: 2012-07-20 22:49 EDT (History)
13 users (show)

See Also:
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:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Netfilter 774 None None None 2012-06-30 17:04:03 EDT

  None (edit)
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.

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