From: Maciej Żenczykowski
Found by virtue of ipv6 raw sockets not honouring the per-socket
IP{,V6}_FREEBIND setting.
Based on hits found via:
git grep '[.]ip_nonlocal_bind'
We fix both raw ipv6 sockets to honour IP{,V6}_FREEBIND and IP{,V6}_TRANSPARENT,
and we fix sctp sockets to
> > The code is relying on the identical layout of the beginning
> > of the v0 and v1 structs, but this can easily lead to code bugs
> > if one were to try to extend this further...
>
> What is the concern? These structs are part of ABI, they
> cannot be changed.
That is a reasonable point, but t
From: Maciej Żenczykowski
(this is needed at least with bionic)
Signed-off-by: Maciej Żenczykowski
---
libxtables/xtables.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libxtables/xtables.c b/libxtables/xtables.c
index bc42ba82..77bc18f6 100644
--- a/libxtables/xtables.c
+++ b
From: Maciej Żenczykowski
The code is relying on the identical layout of the beginning
of the v0 and v1 structs, but this can easily lead to code bugs
if one were to try to extend this further...
I use:
char (*plabel)[MAX_IDLETIMER_LABEL_SIZE]
instead of:
char label[MAX_IDLETIMER_LABEL_SIZE
> On Thu, Oct 8, 2020 at 12:31 PM Maciej Żenczykowski
> wrote:
> > diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
> > index 2a5277758379..598415743f46 100644
> > --- a/include/net/ip6_route.h
> > +++ b/include/net/ip6_route.h
> > @@ -
From: Maciej Żenczykowski
This matches the new ipv4 behaviour as of commit:
commit 02a1b175b0e92d9e0fa5df3957ade8d733ceb6a0
Author: Maciej Żenczykowski
Date: Wed Sep 23 13:18:15 2020 -0700
net/ipv4: always honour route mtu during forwarding
The reasoning is similar: There doesn&#
From: Maciej Żenczykowski
This is basically just a refactor.
But it does affect (a presumably buggy) call site in:
net/netfilter/nf_flow_table_core.c
flow_offload_fill_route()
Signed-off-by: Maciej Żenczykowski
---
include/net/ip6_route.h | 4 ++--
net/ipv6/ip6_output.c | 2 --
2 files
From: Maciej Żenczykowski
Documentation/networking/ip-sysctl.txt:46 says:
ip_forward_use_pmtu - BOOLEAN
By default we don't trust protocol path MTUs while forwarding
because they could be easily forged and can lead to unwanted
fragmentation by the router.
You only ne
From: Maciej Żenczykowski
Documentation/networking/ip-sysctl.txt:46 says:
ip_forward_use_pmtu - BOOLEAN
By default we don't trust protocol path MTUs while forwarding
because they could be easily forged and can lead to unwanted
fragmentation by the router.
You only ne
From: Maciej Żenczykowski
Documentation/networking/ip-sysctl.txt:46 says:
ip_forward_use_pmtu - BOOLEAN
By default we don't trust protocol path MTUs while forwarding
because they could be easily forged and can lead to unwanted
fragmentation by the router.
You only ne
From: Maciej Żenczykowski
This reduces likelihood of incorrect use.
Test: builds
Signed-off-by: Maciej Żenczykowski
---
drivers/net/veth.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index e56cd562a664..b80cbffeb88e 100644
From: Maciej Żenczykowski
This provides a minor performance boost by virtue of inlining
instead of cross module function calls.
Test: builds
Signed-off-by: Maciej Żenczykowski
---
drivers/net/tun.c | 18 --
include/linux/if_tun.h | 15 ---
2 files changed, 12
From: Maciej Żenczykowski
This reduces likelihood of incorrect use.
Test: builds
Signed-off-by: Maciej Żenczykowski
---
drivers/net/tun.c | 6 +++---
include/linux/if_tun.h | 8
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
From: Maciej Żenczykowski
Test: builds
Signed-off-by: Maciej Żenczykowski
---
drivers/net/tun.c | 6 +++---
include/linux/if_tun.h | 8
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 3c11a77f5709..5dd7f353eeef 100644
> void xtables_fini(void)
> {
> +#ifndef NO_SHARED_LIBS
> dlreg_free();
> +#endif
> }
Note: I also considered just adding an empty 'void dlreg_free(void)
{}' function in the NO_SHARED_LIBS case, but that doesn't seem to be
the prevalent style...
From: Maciej Żenczykowski
Fixes two issues with NO_SHARED_LIBS:
- #include is ifdef'ed out and thus dlclose()
triggers an undeclared function compiler warning
- dlreg_add() is unused and thus triggers an unused
function warning
Test: builds without warnings
Signed-off-by: M
From: Maciej Żenczykowski
This is a fix for a regression introduced in 5.8-rc1 by:
commit 2c78ee898d8f10ae6fb2fa23a3fbaec96b1b7366
'bpf: Implement CAP_BPF'
Before the above commit it was possible to load network bpf programs
with just the CAP_SYS_ADMIN privilege.
The Android
From: Maciej Żenczykowski
This is a 5.8-rc1 regression.
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Fixes: 2c78ee898d8f ("bpf: Implement CAP_BPF")
Signed-off-by: Maciej Żenczykowski
---
kernel/bpf/syscall.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
{cmsg_len=32, cmsg_level=SOL_SOCKET,
> cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1590340680, tv_usec=272424}},
> {cmsg_len=60, cmsg_level=SOL_IPV6,
> cmsg_type=IPV6_RECVERR}],
> msg_controllen=96, msg_flags=MSG_ERRQUEUE}, MSG_ERRQUEU
Apparently no, did you send the wrong patch?
But since you'll have to resend again, 2 more minor stylistic comments.
> +P_2 being succesful in reaching its destination and advancing the connection
successful
> +state normally. It is conceivable that the late-arriving P may be considered
> to
> +
is conceivable that the late-arriving P may be considered
> to
> +be not associated with any connection tracking entry. Generating a reject
> +packet for this packet would then terminate the healthy connection.
> +.PP
> +So, instead of:
> +.PP
> +-A INPUT ... -j REJECT
> +.PP
> +do consider using:
> +.PP
> +-A INPUT ... -m conntrack --ctstate INVALID -j DROP
> +-A INPUT ... -j REJECT
> --
> 2.26.2
>
Maciej Żenczykowski, Kernel Networking Developer @ Google
Reviewed-by: Maciej Żenczykowski
From: Maciej Żenczykowski
This looks like an oversight which is easy to fix.
Furthermore:
git grep ';;OK'
does not find any other matches, so this is the last unverified test case.
Test:
[root@f32vm IPT]# uname -r
5.6.10-300.fc32.x86_64
[root@f32vm IPT]# md5sum
From: Maciej Żenczykowski
Fixes:
In file included from libip4tc.c:113:
In function ‘iptcc_compile_chain’,
inlined from ‘iptcc_compile_table’ at libiptc.c:1246:13,
inlined from ‘iptc_commit’ at libiptc.c:2575:8,
inlined from ‘iptc_commit’ at libiptc.c:2513:1:
libiptc.c
> Applied, thanks for explaning.
You're welcome!
> Ido's response gave introductory commands which can also be found here:
> https://www.kernel.org/doc/Documentation/networking/vrf.txt
>
> This should answer most questions about more advanced topics:
> http://schd.ws/hosted_files/ossna2017/fe/vrf-tutorial-oss.pdf
>
> Lately, I am putting
Do we have some sort of beginner's introduction to Linux VRF somewhere?
What they are? How to use them?
Currently the concept simply doesn't fit into my mental model of networking...
We've actually talked about maybe possibly using VRF's in Android (for
our multi network support)...
but no-one on
Also maybe the example should be:
instead of just:
-A INPUT ... -j REJECT
do:
-A INPUT ... -m conntrack --ctstate INVALID -j DROP
-A INPUT ... -j REJECT
I *think* that your talk of 3 packets is not needed, ie. the initial
delayed packet doesn't have to be a retransmission.
It can be the first copy of that segment that gets massively delayed
and arrives late and causes problems,
by virtue of arriving after the retransmission already caused the
conne
>
> On Mon, Apr 27, 2020 at 05:14:24PM -0700, Maciej Żenczykowski wrote:
> > > Could you check if this slows down iptables-restore?
> >
> > per the iptables-restore man page
> >-v, --verbose
> > Print additional debug info during ruleset p
From: Maciej Żenczykowski
This is present in bionic header files regardless of compiler
being used (likely clang)
Test: builds
Signed-off-by: Maciej Żenczykowski
---
libiptc/libip4tc.c | 2 +-
libiptc/libip6tc.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libiptc
Argh. I've never understood the faintest thing about VRF's.
Side note, it doesn't have to be nearly as aggressive as the above.
With just:
tc qdisc replace dev ifb0 root netem reorder 99.9% 0% delay 1s
I still see 169.58M @ 7.02MB/s in 26s:
[24263:180667450] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
[27:174654] -A INPUT -m state --state
So I've never tried to figure out how things break, just observed that
they do - first many many years ago (close to 15ish) - between my wifi
connected laptop at home and my university server in the same city.
I've kept an INVALID->DROP rule in all my firewalls since then and not
had problems. I v
From: Maciej Żenczykowski
This appears to be a common, but hard to debug, misconfiguration.
Signed-off-by: Maciej Żenczykowski
---
extensions/libip6t_REJECT.man | 15 +++
extensions/libipt_REJECT.man | 15 +++
2 files changed, 30 insertions(+)
diff --git a/extensions
From: Maciej Żenczykowski
This makes 'ping' 'ping6' and icmp based traceroute no longer
require any suid or file capabilities.
These sockets have baked long enough that the restriction
to make them unusable by default is no longer necessary.
The concerns were around expl
> I've thought about this some more and decided to apply this and
> queue it up for -stable, thank you.
Thank you!
From: Maciej Żenczykowski
it doesn't actually exist...
Test: builds and 'git grep tcp_default_init_rwnd' comes up empty
Signed-off-by: Maciej Żenczykowski
---
include/net/tcp.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
ind
From: Maciej Żenczykowski
__bpf_skb_max_len(skb) is used from:
bpf_skb_adjust_room
__bpf_skb_change_tail
__bpf_skb_change_head
but in the case of forwarding we're likely calling these functions
during receive processing on ingress and bpf_redirect()'ing at
a later point in time
> > I thought we have established that checking device MTU (m*T*u)
> > at ingress makes a very limited amount of sense, no?
> >
> > Shooting from the hip here, but won't something like:
> >
> > if (!skb->dev || skb->tc_at_ingress)
> > return SKB_MAX_ALLOC;
> > return skb->dev->mtu +
> I thought we have established that checking device MTU (m*T*u)
> at ingress makes a very limited amount of sense, no?
>
> Shooting from the hip here, but won't something like:
>
> if (!skb->dev || skb->tc_at_ingress)
> return SKB_MAX_ALLOC;
> return skb->dev->mtu + skb->dev->hard_
From: Maciej Żenczykowski
__bpf_skb_max_len(skb) is used from:
bpf_skb_adjust_room
__bpf_skb_change_tail
__bpf_skb_change_head
but in the case of forwarding we're likely calling these functions
during receive processing on ingress and bpf_redirect()'ing at
a later point in time
> > It's local system policy, how do I react to packets. If it doesn't
> > violate the min/max limits for ipv6 packets it emits onto the internet
> > I don't see this as something that can be seen as mandatory.
It does violate the max limit for ipv6 packets it emits onto the internet.
You're not
> It's local system policy, how do I react to packets. If it doesn't
> violate the min/max limits for ipv6 packets it emits onto the internet
> I don't see this as something that can be seen as mandatory.
And if you *truly* do want to violate internet standards you can
indeed already achieve this
I don't buy your argument at all.
There's *lots* of places where internet standards prevent Linux from
doing various things.
Trying to prevent users from shooting themselves in the foot, or
trying to be a good netizen.
If users require their computers to be broken, they can patch and
build their o
From: Maciej Żenczykowski
This reverts commit 19bda36c4299ce3d7e5bce10bebe01764a655a6d:
| ipv6: add mtu lock check in __ip6_rt_update_pmtu
|
| Prior to this patch, ipv6 didn't do mtu lock check in ip6_update_pmtu.
| It leaded to that mtu lock doesn't really work when receiving th
> Considering how frequent this pattern (a callback where not all
> instances use all parameters) is, maybe we could consider disabling the
> warning with -Wno-unused-parameter instead of marking all places where
> it is issued.
Once you fix it... it stays fixed. There's no cost to carrying aroun
> So you conclude as it is not leak too? Then what are you trying to
> fix?
I conclude there is no easily *visible* leak.
At least not at first glance - not with single threaded code.
> I am becoming more confused after this. :-/
I think adding kmemleak_not_leak() is hiding the fact that there
a
From: Maciej Żenczykowski
This fixes:
external/ethtool/de2104x.c:115:43: error: unused parameter 'info'
[-Werror,-Wunused-parameter]
de21040_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
external/ethtool/de2104x.c:421:43: error: unused parameter '
From: Maciej Żenczykowski
This fixes:
external/ethtool/igb.c:92:39: error: unused parameter 'info'
[-Werror,-Wunused-parameter]
igb_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
Signed-off-by: Maciej Żenczykowski
Change-Id: If2e175d1b1bd3976d760dc359b52c3
From: Maciej Żenczykowski
This fixes:
external/ethtool/fec.c:197:43: error: unused parameter 'info'
[-Werror,-Wunused-parameter]
int fec_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
Signed-off-by: Maciej Żenczykowski
From: Maciej Żenczykowski
This fixes:
external/ethtool/tse.c:28:50: error: unused parameter 'info'
[-Werror,-Wunused-parameter]
int altera_tse_dump_regs(struct ethtool_drvinfo *info,
Signed-off-by: Maciej Żenczykowski
Change-Id: I555f0e3c55bba999aeb64f1e1435744590ea389d
---
From: Maciej Żenczykowski
This fixes:
external/ethtool/e100.c:40:40: error: unused parameter 'info'
[-Werror,-Wunused-parameter]
e100_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
Signed-off-by: Maciej Żenczykowski
Change-Id: Idc6e3bb3fb837555425ddd6cc903e8
From: Maciej Żenczykowski
This fixes:
external/ethtool/ethtool.c:1271:70: error: unused parameter 'info'
[-Werror,-Wunused-parameter]
static int dump_eeprom(int geeprom_dump_raw, struct ethtool_drvinfo *info,
Signed-off-by: Maciej Żenczykowski
From: Maciej Żenczykowski
This fixes:
external/ethtool/natsemi.c:967:45: error: unused parameter 'info'
[-Werror,-Wunused-parameter]
natsemi_dump_eeprom(struct ethtool_drvinfo *info, struct ethtool_eeprom *ee)
Signed-off-by: Maciej Żenczykowski
From: Maciej Żenczykowski
This fixes:
external/ethtool/sfc.c:3894:39: error: unused parameter 'info'
[-Werror,-Wunused-parameter]
sfc_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
Signed-off-by: Maciej Żenczykowski
Change-Id: Ia255a280742332c44b66bf8f5bb678
From: Maciej Żenczykowski
This fixes:
external/ethtool/vioc.c:14:44: error: unused parameter 'info'
[-Werror,-Wunused-parameter]
int vioc_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
Signed-off-by: Maciej Żenczykowski
From: Maciej Żenczykowski
This fixes:
external/ethtool/ixgb.c:42:40: error: unused parameter 'info'
[-Werror,-Wunused-parameter]
ixgb_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
Signed-off-by: Maciej Żenczykowski
Change-Id: I674e03805dc9a4633d0299d9f4e88b
From: Maciej Żenczykowski
This fixes:
external/ethtool/e1000.c:368:41: error: unused parameter 'info'
[-Werror,-Wunused-parameter]
e1000_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
Signed-off-by: Maciej Żenczykowski
From: Maciej Żenczykowski
This fixes:
external/ethtool/vmxnet3.c:6:43: error: unused parameter 'info'
[-Werror,-Wunused-parameter]
vmxnet3_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
Signed-off-by: Maciej Żenczykowski
From: Maciej Żenczykowski
This fixes:
external/ethtool/e1000.c:258:38: error: unused parameter 'revision_id'
[-Werror,-Wunused-parameter]
e1000_get_mac_type(u16 device_id, u8 revision_id)
Signed-off-by: Maciej Żenczykowski
Change-Id: I2469ef61996fd273cc3a2a6a7af0ae889c81b02b
--
From: Maciej Żenczykowski
This fixes:
external/ethtool/marvell.c:262:44: error: unused parameter 'info'
[-Werror,-Wunused-parameter]
int skge_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
external/ethtool/marvell.c:382:44: error: unused parameter '
From: Maciej Żenczykowski
This fixes:
external/ethtool/smsc911x.c:5:48: error: unused parameter 'info'
[-Werror,-Wunused-parameter]
int smsc911x_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs
*regs)
Signed-off-by: Maciej Żenczykowski
From: Maciej Żenczykowski
This fixes:
external/ethtool/at76c50x-usb.c:16:48: error: unused parameter 'info'
[-Werror,-Wunused-parameter]
at76c50x_usb_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs
*regs)
Signed-off-by: Maciej Żenczykowski
From: Maciej Żenczykowski
This fixes:
external/ethtool/ibm_emac.c:317:48: error: unused parameter 'info'
[-Werror,-Wunused-parameter]
int ibm_emac_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs
*regs)
Signed-off-by: Maciej Żenczykowski
From: Maciej Żenczykowski
This fixes:
external/ethtool/amd8111e.c:155:48: error: unused parameter 'info'
[-Werror,-Wunused-parameter]
int amd8111e_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs
*regs)
Signed-off-by: Maciej Żenczykowski
From: Maciej Żenczykowski
This fixes:
external/ethtool/et131x.c:5:46: error: unused parameter 'info'
[-Werror,-Wunused-parameter]
int et131x_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
Signed-off-by: Maciej Żenczykowski
From: Maciej Żenczykowski
This fixes:
external/ethtool/fjes.c:5:44: error: unused parameter 'info'
[-Werror,-Wunused-parameter]
int fjes_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
Signed-off-by: Maciej Żenczykowski
From: Maciej Żenczykowski
This fixes:
external/ethtool/lan78xx.c:5:47: error: unused parameter 'info'
[-Werror,-Wunused-parameter]
int lan78xx_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
Signed-off-by: Maciej Żenczykowski
From: Maciej Żenczykowski
This fixes:
external/ethtool/natsemi.c:326:43: error: unused parameter 'info'
[-Werror,-Wunused-parameter]
natsemi_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
Signed-off-by: Maciej Żenczykowski
From: Maciej Żenczykowski
This fixes:
external/ethtool/ethtool.c:473:43: error: unused parameter 'ctx'
[-Werror,-Wunused-parameter]
static int do_version(struct cmd_context *ctx)
external/ethtool/ethtool.c:5392:43: error: unused parameter 'ctx'
[-Werror,-Wunused-par
From: Maciej Żenczykowski
This fixes:
external/ethtool/stmmac.c:21:49: error: unused parameter 'info'
[-Werror,-Wunused-parameter]
int st_mac100_dump_regs(struct ethtool_drvinfo *info,
external/ethtool/stmmac.c:54:47: error: unused parameter 'info'
[-Werror,-Wunu
From: Maciej Żenczykowski
This fixes:
external/ethtool/dsa.c:677:43: error: unused parameter 'info'
[-Werror,-Wunused-parameter]
int dsa_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
Signed-off-by: Maciej Żenczykowski
From: Maciej Żenczykowski
This fixes:
external/ethtool/ixgbevf.c:6:43: error: unused parameter 'info'
[-Werror,-Wunused-parameter]
ixgbevf_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
Signed-off-by: Maciej Żenczykowski
From: Maciej Żenczykowski
This fixes:
external/ethtool/ixgbe.c:171:41: error: unused parameter 'info'
[-Werror,-Wunused-parameter]
ixgbe_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
Signed-off-by: Maciej Żenczykowski
From: Maciej Żenczykowski
This fixes:
external/ethtool/marvell.c:127:22: error: arithmetic on a pointer to void is
a GNU extension [-Werror,-Wpointer-arith]
dump_timer("LED", p + 0x20);
(and remove some spare whitespace while we're at it)
Signed-off-by: Maciej Żenczyko
From: Maciej Żenczykowski
This fixes:
external/ethtool/fec_8xx.c:50:47: error: unused parameter 'info'
[-Werror,-Wunused-parameter]
int fec_8xx_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
Signed-off-by: Maciej Żenczykowski
From: Maciej Żenczykowski
This fixes:
external/ethtool/realtek.c:244:43: error: unused parameter 'info'
[-Werror,-Wunused-parameter]
realtek_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
Signed-off-by: Maciej Żenczykowski
From: Maciej Żenczykowski
This fixes:
external/ethtool/tg3.c:8:41: error: unused parameter 'info'
[-Werror,-Wunused-parameter]
tg3_dump_eeprom(struct ethtool_drvinfo *info, struct ethtool_eeprom *ee)
external/ethtool/tg3.c:27:39: error: unused parameter 'info'
From: Maciej Żenczykowski
This fixes:
external/ethtool/sfc.c:3811:29: error: unused parameter 'revision'
[-Werror,-Wunused-parameter]
print_simple_table(unsigned revision, const struct efx_nic_reg_table *table,
Signed-off-by: Maciej Żenczykowski
From: Maciej Żenczykowski
This fixes:
external/ethtool/ethtool.c:5417:28: error: unused parameter 'argc'
[-Werror,-Wunused-parameter]
static int find_option(int argc, char **argp)
Signed-off-by: Maciej Żenczykowski
Change-Id: I7782cac5f58e217fc6032037a2f248b03573b9d4
---
eth
You can merge them via:
git fetch https://github.com/zenczykowski/ethtool.git fix-warnings
git merge FETCH_HEAD
and I'll follow up this email with the full set.
> The Fixes tag is missing. Calling sendmsg on a packet socket bound to
> ETH_P_ALL goes back a long way. It is a user, not kernel, bug to do
> so.
I would argue it's not a bug at all - at least not the way you phrased it.
AFAIK it can/could be done correctly via specifying the protocol in
the sl
Here's my reasoning:
old = ct->ext;
//... stuff that doesn't change old.
alloc = max(newlen, NF_CT_EXT_PREALLOC); <-- will be >= 128,
so not zero
kmemleak_not_leak(old);
new = __krealloc(old, alloc, gfp);
if (!new)
return NULL; <-
95893>] init_conntrack+0x278/0x4a0
[<9e67654a>] nf_conntrack_in+0x2b4/0x7b4
[<ca4d0a3e>] ipv4_conntrack_local+0xa4/0xac
[<81d01fa2>] nf_hook_slow+0x4c/0xdc
[<97b73dfa>] __ip_local_out+0xfc/0x140
[<b21eaa8e>] i
oc+rcu+kmemleak thing I'm missing.
On Mon, Oct 7, 2019 at 10:35 PM Maciej Żenczykowski
wrote:
>
> From: Maciej Żenczykowski
>
> This reverts commit 114aa35d06d4920c537b72f9fa935de5dd205260.
>
> By my understanding of kmemleak the reasoning for this patch
> is incor
From: Maciej Żenczykowski
This reverts commit 114aa35d06d4920c537b72f9fa935de5dd205260.
By my understanding of kmemleak the reasoning for this patch
is incorrect. If kmemleak couldn't handle rcu we'd have it
reporting leaks all over the place. My belief is that this
was instead pap
From: Maciej Żenczykowski
Cc: Cong Wang
Cc: Eric Dumazet
Cc: Pablo Neira Ayuso
Signed-off-by: Maciej Żenczykowski
---
net/netfilter/nf_conntrack_core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/netfilter/nf_conntrack_core.c
b/net/netfilter
> Removing this is going to break things, you can't just remove a sysctl
> because "oh it was a bad idea to add this, sorry."
Yeah, I know... but do you have any other suggestions?
Would you take an alternative to make the default wide opened?
The current sysctl just doesn't work. It can even p
From: Maciej Żenczykowski
It is high time to make icmp sockets available to all, and thus allow
utilities like ping, ping6, traceroute and others to not require suid
root nor file system (or otherwise gained) CAP_NET_RAW privs.
While in the past there have been a number of exploits, extensive
From: Maciej Żenczykowski
Fixes a stupid bug I recently introduced...
ip6_route_info_create() returns an ERR_PTR(err) and not a NULL on error.
Fixes: d55a2e374a94 ("net-ipv6: fix excessive RTF_ADDRCONF flag on ::1/128
local route (and others)'")
Cc: David Ahern
Cc: Lorenzo Co
> Shouldn't it use
>
> if (!IS_ERR(f6i))
> f6i->dst_nocount = true;
>
> ???
Yes, certainly. I'll send a fix.
Well, if you look at the commit my commit is fixing, ie.
commit c7a1ce397adacaf5d4bb2eab0a738b5f80dc3e43
then you'll see this in the commit description:
"- dst_nocount is handled by the RTF_ADDRCONF flag"
and the patch diff itself is from
"f6i->fib6_flags = RTF_UP | RTF_NONEXTHOP;
f6i->dst
From: Maciej Żenczykowski
There is a subtle change in behaviour introduced by:
commit c7a1ce397adacaf5d4bb2eab0a738b5f80dc3e43
'ipv6: Change addrconf_f6i_alloc to use ip6_route_info_create'
Before that patch /proc/net/ipv6_route includes:
0
Some background:
This was found due to bad interactions with one of the few remaining
Android common kernel networking patches.
(The one that makes it possible for RA's to create routes in interface
specific tables)
The cleanup portion of it scours all tables and deletes all relevant
ADDRCONF rou
From: Maciej Żenczykowski
There is a subtle change in behaviour introduced by:
commit c7a1ce397adacaf5d4bb2eab0a738b5f80dc3e43
'ipv6: Change addrconf_f6i_alloc to use ip6_route_info_create'
Before that patch /proc/net/ipv6_route includes:
0
> Applied to net-next
Any chance we could get this into LTS releases?
I can trivially backport this into Android common kernels - which
would get this into the kernel in time for devices that launch with
Android R, but by getting it into LTS we'd get this support even on
devices that upgrade to A
From: Maciej Żenczykowski
This is trivial since we already have support for the entirely
identical (from the kernel's point of view) RDNSS and DNSSL that
also contain opaque data that needs to be passed down to userspace.
As specified in RFC7710, Captive Portal option contains a URL.
(side note: change was reverted in net stable)
On Wed, Jun 5, 2019 at 8:33 AM David Ahern wrote:
> On 6/4/19 10:58 PM, Lorenzo Colitti wrote:
> > As for making this change in 5.3: we might be able to structure the
> > code differently in a future Android release, assuming the same
> > userspace c
FYI, this userspace visible change in behaviour breaks Android.
We rely on being able to add a rule and either have a dup be created
(in which case we'll remove it later) or have it fail with EEXIST (in
which case we won't remove it later).
Returning 0 makes atomically changing a rule difficult.
1 - 100 of 261 matches
Mail list logo
