[iptables PATCH] xshared: Accept an option if any given command allows it

[iptables PATCH] xshared: Accept an option if any given command allows it

[Phil Sutter]

Fixed commit made option checking overly strict: Some commands may be
commbined (foremost --list and --zero), reject a given option only if it
is not allowed by any of the given commands.

Reported-by: Adam Nielsen <a.nielsen@shikadi.net>
Fixes: 9c09d28102bb4 ("xshared: Simplify generic_opt_check()")
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
 iptables/xshared.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/iptables/xshared.c b/iptables/xshared.c
index cdfd11ab2f279..fc61e0fd832bd 100644
--- a/iptables/xshared.c
+++ b/iptables/xshared.c
@@ -980,7 +980,7 @@ static void generic_opt_check(struct xt_cmd_parse_ops *ops,
 	 */
 	for (i = 0, optval = 1; i < NUMBER_OF_OPT; optval = (1 << ++i)) {
 		if ((options & optval) &&
-		    (options_v_commands[i] & command) != command)
+		    !(options_v_commands[i] & command))
 			xtables_error(PARAMETER_PROBLEM,
 				      "Illegal option `%s' with this command",
 				      ops->option_name(optval));
-- 
2.49.0

Re: [iptables PATCH] xshared: Accept an option if any given command allows it

[Phil Sutter]

On Wed, Apr 23, 2025 at 02:19:29PM +0200, Phil Sutter wrote:
> Fixed commit made option checking overly strict: Some commands may be
> commbined (foremost --list and --zero), reject a given option only if it
> is not allowed by any of the given commands.
> 
> Reported-by: Adam Nielsen <a.nielsen@shikadi.net>
> Fixes: 9c09d28102bb4 ("xshared: Simplify generic_opt_check()")
> Signed-off-by: Phil Sutter <phil@nwl.cc>

Patch applied.

Re: [iptables PATCH] xshared: Accept an option if any given command allows it

[Adam Nielsen]

> > Fixed commit made option checking overly strict: Some commands may be
> > commbined (foremost --list and --zero), reject a given option only if it
> > is not allowed by any of the given commands.
> 
> Patch applied.

Excellent!  Many thanks for such a quick fix!

Hopefully it won't be too long until the next release, given the last
one looks to have been a couple of years...

Cheers,
Adam.

Re: [iptables PATCH] xshared: Accept an option if any given command allows it

[Phil Sutter]

On Thu, Apr 24, 2025 at 08:58:03AM +1000, Adam Nielsen wrote:
> > > Fixed commit made option checking overly strict: Some commands may be
> > > commbined (foremost --list and --zero), reject a given option only if it
> > > is not allowed by any of the given commands.
> > 
> > Patch applied.
> 
> Excellent!  Many thanks for such a quick fix!
> 
> Hopefully it won't be too long until the next release, given the last
> one looks to have been a couple of years...

Something between 6-12 months?

v1.8.11: Wed Nov  6 11:47:59 2024 +0100
v1.8.10: Tue Oct 10 11:20:12 2023 +0200
v1.8.9:  Tue Jan 10 17:46:43 2023 +0100
v1.8.8:  Fri May 13 15:26:12 2022 +0200

There's no rule though, we tend to release whenever there's "enough"
pending work. Right now we're just 14 commits in, I'd say we keep
collecting a bit more. :)

Cheers, Phil

Re: [iptables PATCH] xshared: Accept an option if any given command allows it

[Adam Nielsen]

> > Hopefully it won't be too long until the next release, given the last
> > one looks to have been a couple of years...  
> 
> Something between 6-12 months?
> 
> v1.8.11: Wed Nov  6 11:47:59 2024 +0100
> v1.8.10: Tue Oct 10 11:20:12 2023 +0200
> v1.8.9:  Tue Jan 10 17:46:43 2023 +0100
> v1.8.8:  Fri May 13 15:26:12 2022 +0200
> 
> There's no rule though, we tend to release whenever there's "enough"
> pending work. Right now we're just 14 commits in, I'd say we keep
> collecting a bit more. :)

Fair enough.  I think the previous release sat in my distro's repos for
around 18 months before we got 1.18.11, so I was hoping I wouldn't have
to wait that long again before 1.18.12 comes along and gets my
bandwidth monitoring scripts working again!

I'll probably do a custom package with the git version, then I can get
things going once more without hassling you for more frequent
releases :)

Cheers,
Adam.

Re: [iptables PATCH] xshared: Accept an option if any given command allows it

[Phil Sutter]

On Thu, Apr 24, 2025 at 10:04:09AM +1000, Adam Nielsen wrote:
> > > Hopefully it won't be too long until the next release, given the last
> > > one looks to have been a couple of years...  
> > 
> > Something between 6-12 months?
> > 
> > v1.8.11: Wed Nov  6 11:47:59 2024 +0100
> > v1.8.10: Tue Oct 10 11:20:12 2023 +0200
> > v1.8.9:  Tue Jan 10 17:46:43 2023 +0100
> > v1.8.8:  Fri May 13 15:26:12 2022 +0200
> > 
> > There's no rule though, we tend to release whenever there's "enough"
> > pending work. Right now we're just 14 commits in, I'd say we keep
> > collecting a bit more. :)
> 
> Fair enough.  I think the previous release sat in my distro's repos for
> around 18 months before we got 1.18.11, so I was hoping I wouldn't have
> to wait that long again before 1.18.12 comes along and gets my
> bandwidth monitoring scripts working again!

Which distribution are you using?

> I'll probably do a custom package with the git version, then I can get
> things going once more without hassling you for more frequent
> releases :)

Can't you file a ticket in downstream bug tracker and request a
backport? They probably also want commit 40406dbfaefbc ("nft: fix
interface comparisons in `-C` commands").

Cheers, Phil

Re: [iptables PATCH] xshared: Accept an option if any given command allows it

[Adam Nielsen]

> > Fair enough.  I think the previous release sat in my distro's repos for
> > around 18 months before we got 1.18.11, so I was hoping I wouldn't have
> > to wait that long again before 1.18.12 comes along and gets my
> > bandwidth monitoring scripts working again!  
> 
> Which distribution are you using?

Arch Linux.  They're not particularly open to customising things,
preferring to stick to upstream releases as closely as possible.

> > I'll probably do a custom package with the git version, then I can get
> > things going once more without hassling you for more frequent
> > releases :)  
> 
> Can't you file a ticket in downstream bug tracker and request a
> backport? They probably also want commit 40406dbfaefbc ("nft: fix
> interface comparisons in `-C` commands").

I could but I've tried before and unless it's a serious problem you're
usually out of luck.  They instead prefer to push the maintainers to do
another release so they can just bump the version number in their
package build scripts.

It's not too bad, Arch has a user repository for packages and I have
found that someone has already made a package build script for the git
version of iptables, so I tried installing that and it has fixed the
problem, so my immediate concern is sorted now.

I just have to remember to remove the git version and go back to the
official package when the next version of iptables comes out, as the git
packages don't update automatically.

Thanks again for getting a fix for this done so quickly.

Cheers,
Adam.