On Wed, Jan 15, 2025 at 09:19:33AM +, Hangbin Liu wrote:
> On Wed, Jan 08, 2025 at 07:15:00AM +, Hangbin Liu wrote:
> > > > > > > I don't know how to disable bonding sleeping since we use
> > > > > > > mutex_lock now.
> > > > > > > Hi Jianbo, do you have any idea?
> > > > > > >
> > > > >
u Mar 11 10:07:56 2021 +0800
esp6: remove a duplicative condition
Fixes coccicheck warnings:
./net/ipv6/esp6_offload.c:319:32-34:
WARNING !A || A && B is equivalent to !A || B
Signed-off-by: Junlin Yang
Signed-off-by: Steffen Klassert
> (for every type)
>
> Reported-by: syzbot+834ffd1afc7212eb8...@syzkaller.appspotmail.com
> Fixes: 5f3eea6b7e8f ("xfrm/compat: Attach xfrm dumps to 64=>32 bit
> translator")
> Cc: "David S. Miller"
> Cc: Eric Dumazet
> Cc: Herbert Xu
> Cc: Jakub Kicinski
>
On Mon, Mar 22, 2021 at 12:56:49PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> When building with 'make W=1', clang warns about a mismatched
> format string:
>
> net/ipv6/ah6.c:710:4: error: format specifies type 'unsigned short' but the
> argument has type 'int' [-Werror,-Wformat]
>
On Tue, Mar 16, 2021 at 11:56:28AM +0100, Ahmed S. Darwish wrote:
> Hi,
>
> This is a small series to trasform xfrm_state_hash_generation sequence
> counter to seqcount_spinlock_t, instead of plain seqcount_t.
>
> In general, seqcount_LOCKNAME_t sequence counters allows to associate
> the lock us
On Thu, Mar 11, 2021 at 10:07:56AM +0800, angkery wrote:
> From: Junlin Yang
>
> Fixes coccicheck warnings:
> ./net/ipv6/esp6_offload.c:319:32-34:
> WARNING !A || A && B is equivalent to !A || B
>
> Signed-off-by: Junlin Yang
Applied to ipsec-next, thanks!
On Mon, Mar 01, 2021 at 06:46:02PM +0800, Jiapeng Chong wrote:
> Fix the following coccicheck warnings:
>
> ./net/ipv4/esp4.c:757:16-18: WARNING !A || A && B is equivalent to !A || B.
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong
Now applied to ipsec-next, thanks!
On Tue, Mar 02, 2021 at 08:00:04AM +1300, Evan Nimmo wrote:
> A situation can occur where the interface bound to the sk is different
> to the interface bound to the sk attached to the skb. The interface
> bound to the sk is the correct one however this information is lost inside
> xfrm_output2 and
On Sat, Feb 20, 2021 at 11:18:23AM +0800, Yang Li wrote:
> Fix the following sparse warnings:
> net/xfrm/xfrm_policy.c:1303:22: warning: incorrect type in assignment
> (different address spaces)
>
> Reported-by: Abaci Robot
> Signed-off-by: Yang Li
Please add a proper 'Fixes' tag so that it can
On Mon, Mar 01, 2021 at 05:02:08PM +1300, Evan Nimmo wrote:
> A situation can occur where the interface bound to the sk is different
> to the interface bound to the sk attached to the skb. The interface
> bound to the sk is the correct one however this information is lost inside
> xfrm_output2 and
On Thu, Feb 04, 2021 at 03:42:54PM +0800, Zheng Yongjun wrote:
> When kalloc or kmemdup failed, should return ENOMEM rather than ENOBUF.
>
> Signed-off-by: Zheng Yongjun
Applied to ipsec-next, thanks!
On Wed, Feb 03, 2021 at 10:44:30AM +0800, Jiapeng Chong wrote:
> Fix the following coccicheck warnings:
>
> ./net/ipv6/esp6.c:791:16-18: WARNING !A || A && B is equivalent
> to !A || B.
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong
Applied to ipsec-next, thanks!
On Mon, Jan 25, 2021 at 02:41:46PM +0800, Jiapeng Zhong wrote:
> Fix the following coccicheck warnings:
>
> ./net/ipv4/esp4_offload.c:288:32-34: WARNING !A || A && B is
> equivalent to !A || B.
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Zhong
Patch applied, thanks!
t in
> __udp_gso_segment_list. It covers both SNAT and DNAT.
>
> Fixes: 9fd1ff5d2ac7 (udp: Support UDP fraglist GRO/GSO.)
> Signed-off-by: Dongseok Yi
> ---
> v1:
> Steffen Klassert said, there could be 2 options.
> https://lore.kernel.org/patchwork/patch/1362257
On Tue, Jan 26, 2021 at 09:31:29AM +0900, Dongseok Yi wrote:
> On 1/25/21 9:45 PM, Steffen Klassert wrote:
> > On Thu, Jan 21, 2021 at 10:24:39PM +0900, Dongseok Yi wrote:
> > >
> > > +static void __udpv4_gso_segment_csum(struct sk_buff *seg,
> > > +
On Wed, Jan 20, 2021 at 03:55:42PM +0900, Dongseok Yi wrote:
> On 2021-01-18 22:27, Steffen Klassert wrote:
> > On Fri, Jan 15, 2021 at 10:20:35PM +0900, Dongseok Yi wrote:
> > > UDP/IP header of UDP GROed frag_skbs are not updated even after NAT
> > > forwarding. Only
segment list
> in __udp_gso_segment_list. It covers both SNAT and DNAT.
>
> Fixes: 9fd1ff5d2ac7 (udp: Support UDP fraglist GRO/GSO.)
> Signed-off-by: Dongseok Yi
> ---
> v1:
> Steffen Klassert said, there could be 2 options.
> https://lore.kernel.org/patchwork/patch/1362257
On Mon, Jan 18, 2021 at 12:17:34PM +, Alexander Lobakin wrote:
> > From: Steffen Klassert
> > Date: Mon, 18 Jan 2021 07:37:59 +0100
> > On Fri, Jan 15, 2021 at 05:12:33PM +, Alexander Lobakin wrote:
> >>
> >> I used another approach, tried to make
gment list but copy
> > only the MAC header.
> >
> > Update dport, daddr and checksums of each skb of the segment list
> > in __udp_gso_segment_list. It covers both SNAT and DNAT.
> >
> > Fixes: 9fd1ff5d2ac7 (udp: Support UDP fraglist GRO/GSO.)
> >
On Fri, Jan 15, 2021 at 05:55:22PM +0900, Dongseok Yi wrote:
> On 2021-01-15 17:12, Steffen Klassert wrote:
> > On Fri, Jan 15, 2021 at 02:58:24PM +0900, Dongseok Yi wrote:
> > > UDP/IP header of UDP GROed frag_skbs are not updated even after NAT
> > > forwarding. Only
ses?
We copy only the MAC header in skb_segment_list(), so I think
this is a valid bug when NAT changed the UDP header.
>
> Update dport, daddr and checksums of each skb of the segment list
> after __udp_gso_segment.
>
> Fixes: 9fd1ff5d2ac7 (udp: Support UDP fraglist GRO/GSO.)
> Signed-off
On Mon, Jan 11, 2021 at 11:02:42AM +0900, Dongseok Yi wrote:
> On 2021-01-08 22:35, Steffen Klassert wrote:
> > On Fri, Jan 08, 2021 at 09:52:28PM +0900, Dongseok Yi wrote:
> > > It is a workaround patch.
> > >
> > > UDP/IP header of UDP GROed frag
On Fri, Jan 08, 2021 at 09:52:28PM +0900, Dongseok Yi wrote:
> It is a workaround patch.
>
> UDP/IP header of UDP GROed frag_skbs are not updated even after NAT
> forwarding. Only the header of head_skb from ip_finish_output_gso ->
> skb_gso_segment is updated but following frag_skbs are not updat
On Wed, Dec 30, 2020 at 05:52:04PM +0800, Po-Hsu Lin wrote:
> When running this xfrm_policy.sh test script, even with some cases
> marked as FAIL, the overall test result will still be PASS:
>
> $ sudo ./xfrm_policy.sh
> PASS: policy before exception matches
> FAIL: expected ping to .254 to fail (
On Sat, Dec 19, 2020 at 02:26:09PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Commit
>
> 06148d3b3f2e ("xfrm: Fix oops in xfrm_replay_advance_bmp")
>
> is missing a Signed-off-by from its committer.
My bad. I did a forced push to fix it.
On Thu, Nov 26, 2020 at 09:21:39AM +, Marler, Jonathan wrote:
> We've found an issue while running the following USGv6 tests where the kernel
> drops outgoing packets:
>
> 5.3.11 Tunnel Mode: Fragmentation
> 5.4.11 Tunnel Mode: Fragmentation
>
> During the test, an esp PING request is sent t
On Tue, Nov 10, 2020 at 09:14:43AM +0800, Yu Kuai wrote:
> if xfrm_get_translator() failed, xfrm_user_policy() return without
> freeing 'data', which is allocated in memdup_sockptr().
>
> Fixes: 96392ee5a13b ("xfrm/compat: Translate 32-bit user_policy from sockptr")
> Reported-by: Hulk Robot
> Si
O as the memory is initialized during translation.
>
> Cc: Steffen Klassert
> Cc: "David S. Miller"
> Cc: Jakub Kicinski
> Cc: Herbert Xu
> Cc: Hillf Danton
> Cc: net...@vger.kernel.org
>
> Thanks,
> Dmitry
>
> Dmitry Safonov (3):
> x
On Thu, Nov 05, 2020 at 01:52:01PM +0900, Lorenzo Colitti wrote:
> On Tue, Sep 15, 2020 at 4:30 PM Steffen Klassert
> wrote:
> > > In esp's tunnel mode,if inner interface is ipv4,outer is ipv4,one big
> > > packet which travels through tunnel will be fragmented wit
On Fri, Oct 30, 2020 at 02:25:57AM +, Dmitry Safonov wrote:
> WARN_ON() for XFRMA_UNSPEC translation which likely no-one except
> syzkaller uses; properly zerofy tail-padding for 64-bit attribute;
> don't use __GFP_ZERO as the memory is initialized during translation.
>
>
Same here, Dmitry please look into it.
I guess we can just remove the WARN_ON() that
triggeres here.
On Mon, Oct 26, 2020 at 06:58:28AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:f11901ed Merge tag 'xfs-5.10-merge-7' of git://git.kernel...
> git t
Dimitry, you added this code, can you please look into
that?
Thanks!
On Wed, Oct 28, 2020 at 05:00:22PM +0800, Hillf Danton wrote:
> On Fri, 23 Oct 2020 01:38:23 -0700
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:c4d6fe73 Merge tag 'xarray-5.9' of git://git.
On Thu, Oct 22, 2020 at 06:01:27PM +0800, Zhuoliang Zhang wrote:
> From: zhuoliang zhang
>
> we found that the following race condition exists in
> xfrm_alloc_userspi flow:
>
> user threadstate_hash_work thread
>
(Johannes Berg)
> - moved boilerplate from commit messages into cover-letter (Steffen
> Klassert)
> - found on KASAN build and fixed non-initialised stack variable usage
> in the translator
>
> The resulting v2/v3 diff can be found here:
> https://gist.github.com/0x7f454
On Fri, Sep 25, 2020 at 02:42:56PM +1000, Herbert Xu wrote:
> Resend with proper subject.
>
> ---8<---
> The struct flowi must never be interpreted by itself as its size
> depends on the address family. Therefore it must always be grouped
> with its original family value.
>
> In this particular
On Thu, Sep 24, 2020 at 05:43:51PM +1000, Herbert Xu wrote:
> On Thu, Sep 24, 2020 at 09:40:26AM +0200, Steffen Klassert wrote:
> >
> > This is yet another ipv4 mapped ipv6 address with IPsec socket policy
> > combination bug, and I'm sure it is not the last one. We
On Mon, Sep 21, 2020 at 07:56:20AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:eb5f95f1 Merge tag 's390-5.9-6' of git://git.kernel.org/pu..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=13996ad590
> kernel
On Wed, Sep 09, 2020 at 02:26:13PM +0800, mtk81216 wrote:
> In esp's tunnel mode,if inner interface is ipv4,outer is ipv4,one big
> packet which travels through tunnel will be fragmented with outer
> interface's mtu,peer server will remove tunnelled esp header and assemble
> them in big packet.Af
t; > Karthik tested a patch for this bug in July:
> > > https://syzkaller.appspot.com/bug?extid=72ff2fa98097767b5a27
> > >
> > > So perhaps that patch fixes it? Karthik, did you send it? Was it
> > > merged? Did the commit include the syzbot Reported-by tag?
> > >
On Wed, Aug 26, 2020 at 02:49:44AM +0100, Dmitry Safonov wrote:
> XFRM is disabled for compatible users because of the UABI difference.
> The difference is in structures paddings and in the result the size
> of netlink messages differ.
>
> Possibility for compatible application to manage xfrm tunn
On Wed, Aug 26, 2020 at 02:49:43AM +0100, Dmitry Safonov wrote:
> Changes since v1:
> - reworked patches set to use translator
> - separated the compat layer into xfrm_compat.c,
> compiled under XFRM_USER_COMPAT config
> - 32-bit messages now being sent in frag_list (like wext-core does)
> - inst
Daniel Jordan
Great, thanks a lot Daniel!
Acked-by: Steffen Klassert
On Wed, Aug 26, 2020 at 10:59:23AM -0400, Daniel Jordan wrote:
> I volunteer to review padata changes for the foreseeable future.
>
> Signed-off-by: Daniel Jordan
> Cc: Herbert Xu
> Cc: Steffen Klassert
> Cc: linux-cry...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
On Fri, Jul 31, 2020 at 02:49:52PM +0800, YueHaibing wrote:
> If CONFIG_INET_XFRM_TUNNEL is set but CONFIG_IPV6 is n,
>
> net/ipv4/ip_vti.c:493:27: warning: 'vti_ipip6_handler' defined but not used
> [-Wunused-variable]
>
> Signed-off-by: YueHaibing
Now applied to the ipsec tree, thanks!
should go
to the ipsec tree. I'm waiting until I can backmerge
the offending patch into the ipsec tree and apply it
then.
Alternatively to speed things up, you can take it
directly into net-next before you do the pull request
to Linus. In case you prefer that:
Acked-by: Steffen Klassert
On Sat, Jul 25, 2020 at 10:35:12PM -0700, Cong Wang wrote:
> On Sat, Jul 25, 2020 at 8:09 PM B K Karthik wrote:
> > @@ -103,10 +103,10 @@ static int __xfrm6_tunnel_spi_check(struct net *net,
> > u32 spi)
> > {
> > struct xfrm6_tunnel_net *xfrm6_tn = xfrm6_tunnel_pernet(net);
> >
On Sat, Jul 25, 2020 at 07:19:49PM +0530, B K Karthik wrote:
> remove some unnecessary cases in decode_session6
>
> Signed-off-by: B K Karthik
> ---
> net/xfrm/xfrm_policy.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
> index 19c5e
out of range.
>
> Signed-off-by: Mark Salyzyn
> Cc: net...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: kernel-t...@android.com
> Cc: Steffen Klassert
> Cc: Herbert Xu
> Cc: "David S. Miller"
> Cc: Jakub Kicinski
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Applied, thanks a lot!
On Wed, Jul 22, 2020 at 03:20:59AM -0700, Mark Salyzyn wrote:
> On 7/22/20 2:33 AM, Steffen Klassert wrote:
> > On Tue, Jul 21, 2020 at 06:23:54AM -0700, Mark Salyzyn wrote:
> > > In pfkey_dump() dplen and splen can both be specified to access the
> > > xfrm_addres
On Tue, Jul 21, 2020 at 06:23:54AM -0700, Mark Salyzyn wrote:
> In pfkey_dump() dplen and splen can both be specified to access the
> xfrm_address_t structure out of bounds in__xfrm_state_filter_match()
> when it calls addr_match() with the indexes. Return EINVAL if either
> are out of range.
>
>
On Mon, Jul 20, 2020 at 11:09:34PM -0700, Randy Dunlap wrote:
> On 7/20/20 7:07 PM, Andrew Morton wrote:
> > The mm-of-the-moment snapshot 2020-07-20-19-06 has been uploaded to
> >
> >http://www.ozlabs.org/~akpm/mmotm/
> >
> > mmotm-readme.txt says
> >
> > README for mm-of-the-moment:
> >
>
On Wed, Jul 15, 2020 at 05:18:36PM +0800, Xin Long wrote:
> Hi, Steffen,
>
> I've confirmed the patchset I posted yesterday would fix this:
>
> [PATCH ipsec-next 0/3] xfrm: not register one xfrm(6)_tunnel object twice
Thanks for the confirmation! That patchset is now applied
to ipsec-next.
Xin,
this looks a bit like it was introduced with one of your recent
patches. Can you please look into that?
Thanks!
On Mon, Jul 13, 2020 at 03:04:16PM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:be978f8f Add linux-next specific files for 20200713
On Sat, May 30, 2020 at 02:39:12PM +0200, Petr Vaněk wrote:
> RFC 4303 in section 3.3.3 suggests to disable anti-replay for manually
> distributed ICVs in which case the sender does not need to monitor or
> reset the counter. However, the sender still increments the counter and
> when it reaches th
On Tue, Jun 16, 2020 at 07:39:30AM -0600, David Ahern wrote:
> >
> > Indeed. I must have been looking at -net. Both -net and -net-next have
> > it conditional, so yes a fixup patch is needed.
> >
>
> I see that both net and net-next still have the conditional in xfrm_output:
>
> #ifdef CONFIG_N
On Thu, Jun 04, 2020 at 06:44:10AM -0600, David Ahern wrote:
> On 6/4/20 12:41 AM, Steffen Klassert wrote:
> > On Wed, Jun 03, 2020 at 08:55:01PM -0600, David Ahern wrote:
> >> On 6/3/20 7:26 PM, Stephen Rothwell wrote:
> >>>
> >>> And now the net-next tre
On Wed, Jun 03, 2020 at 08:55:01PM -0600, David Ahern wrote:
> On 6/3/20 7:26 PM, Stephen Rothwell wrote:
> >
> > And now the net-next tree has been merged into Linus' tree without this fix
> > :-(
> >
>
> I took a look earlier and I think it is fine. Some code was moved around
> in ipsec-next
On Fri, May 15, 2020 at 04:39:57PM +0800, Yuehaibing wrote:
>
> Friendly ping...
>
> Any plan for this issue?
There was still no consensus between you and Xin on how
to fix this issue. Once this happens, I consider applying
a fix.
On Sun, Oct 20, 2019 at 08:46:10AM -0700, Tom Rix wrote:
> On PREEMPT_RT_FULL while running netperf, a corruption
> of the skb queue causes an oops.
>
> This appears to be caused by a race condition here
> __skb_queue_tail(&trans->queue, skb);
> tasklet_schedule(&trans->tasklet);
>
On Mon, Jul 29, 2019 at 11:43:49AM +0800, Jia-Ju Bai wrote:
> In xfrm_policy(), the while loop on lines 3802-3830 ends when dst->xfrm is
> NULL.
We don't have a xfrm_policy() function, and as said already the
line numbers does not help much as long as you don't say which
tree/branch this is and wh
On Fri, Jul 26, 2019 at 09:15:55PM +0100, Jeremy Sowden wrote:
> On 2019-07-26, at 11:45:14 +0200, Steffen Klassert wrote:
> > On Wed, Jul 24, 2019 at 05:35:09PM +0800, Jia-Ju Bai wrote:
> > >
> > > diff --git a/net/key/af_key.c b/net/key/af_key.c
> > > ind
On Wed, Jul 24, 2019 at 05:35:09PM +0800, Jia-Ju Bai wrote:
> In pfkey_send_policy_notify(), there is an if statement on line 3081 to
> check whether xp is NULL:
> if (xp && xp->type != XFRM_POLICY_TYPE_MAIN)
>
> When xp is NULL, it is used by key_notify_policy() on line 3090:
> key_notify
On Fri, Jul 12, 2019 at 06:06:36PM +0800, Herbert Xu wrote:
> Daniel Jordan wrote:
> >
> > CPU0 CPU1
> >
> > padata_reorder padata_do_serial
> > LOAD reorder_objects // 0
> > INC reorder_objects // 1
>
On Tue, Jun 18, 2019 at 01:22:13PM +0200, Arnd Bergmann wrote:
> kernelci.org reports failed builds on arc because of what looks
> like an old missed 'select' statement:
>
> net/xfrm/xfrm_algo.o: In function `xfrm_probe_algs':
> xfrm_algo.c:(.text+0x1e8): undefined reference to `crypto_has_ahash'
On Fri, Jun 14, 2019 at 04:26:26PM +0800, Young Xiao wrote:
> We leak the allocated out_skb in case pfkey_xfrm_policy2msg() fails.
> Fix this by freeing it on error.
>
> Signed-off-by: Young Xiao <92siuy...@gmail.com>
> ---
> net/key/af_key.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --
On Wed, Jun 12, 2019 at 11:36:24AM +0100, Colin King wrote:
> From: Colin Ian King
>
> It appears that there is a missing break statement for the AF_INET6 case
> that falls through to the default WARN_ONCE case. I don't think that is
> intentional. Fix this by adding in the missing break.
>
> Ad
On Wed, May 22, 2019 at 11:17:00AM +0800, Herbert Xu wrote:
> On Tue, May 21, 2019 at 08:59:47PM +0530, Anirudh Gupta wrote:
> > Family of src/dst can be different from family of selector src/dst.
> > Use xfrm selector family to validate address prefix length,
> > while verifying new sa from usersp
On Wed, Mar 06, 2019 at 04:33:08PM +0900, Myungho Jung wrote:
> In esp4_gro_receive() and esp6_gro_receive(), secpath can be allocated
> without adding xfrm state to xvec. Then, sp->xvec[sp->len - 1] would
> fail and result in dereferencing invalid pointer in esp4_gso_segment()
> and esp6_gso_segme
On Mon, Mar 04, 2019 at 08:19:14PM -0500, Su Yanjun wrote:
> For rcu protected pointers, we'd better add '__rcu' for them.
>
> Once added '__rcu' tag for rcu protected pointer, the sparse tool reports
> warnings.
>
> net/xfrm/xfrm_user.c:1198:39: sparse:expected struct sock *sk
> net/xfrm/xfr
On Tue, Mar 05, 2019 at 03:08:49PM +0800, Su Yanjun
wrote:
> On 2019/3/5 14:49, Herbert Xu wrote:
>
> > On Sun, Mar 03, 2019 at 10:47:39PM -0500, Su Yanjun wrote:
> > > When i review xfrm_user.c code, i found some potentical bug in it.
> > >
> > > In xfrm_user_rcvmsg if type parameter from user
On Thu, Feb 28, 2019 at 03:52:27PM +0800, Herbert Xu wrote:
> On Thu, Feb 28, 2019 at 03:18:59PM +0800, Yue Haibing wrote:
> > From: YueHaibing
> >
> > UBSAN report this:
> >
> > UBSAN: Undefined behaviour in net/xfrm/xfrm_policy.c:1289:24
> > index 6 is out of range for type 'unsigned int [6]'
On Sun, Jan 06, 2019 at 09:31:20PM -0500, Su Yanjun wrote:
> Recently we run a network test over ipcomp virtual tunnel.We find that
> if a ipv4 packet needs fragment, then the peer can't receive
> it.
>
> We deep into the code and find that when packet need fragment the smaller
> fragment will be
On Fri, Jan 04, 2019 at 04:42:05PM +0800, Su Yanjun
wrote:
> On 1/4/2019 3:43 PM, Steffen Klassert wrote:
>
> > On Thu, Jan 03, 2019 at 07:48:41AM -0500, Su Yanjun wrote:
> > > Recently we run a network test over ipcomp virtual tunnel.We find that
> > > if a ipv4 p
On Thu, Jan 03, 2019 at 07:48:41AM -0500, Su Yanjun wrote:
> Recently we run a network test over ipcomp virtual tunnel.We find that
> if a ipv4 packet needs fragment, then the peer can't receive
> it.
>
> We deep into the code and find that when packet need fragment the smaller
> fragment will be
On Wed, Dec 19, 2018 at 02:45:09PM +0800, YueHaibing wrote:
> gcc warn this:
>
> net/ipv6/xfrm6_tunnel.c:143 __xfrm6_tunnel_alloc_spi() warn:
> always true condition '(spi <= 4294967295) => (0-u32max <= u32max)'
>
> 'spi' is u32, which always not greater than XFRM6_TUNNEL_SPI_MAX
> because of wr
On Thu, Dec 06, 2018 at 05:52:28PM +, Colin King wrote:
> From: Colin Ian King
>
> Trivial fix to clean up indentation issue, remove an extraneous
> space.
>
> Signed-off-by: Colin Ian King
Applied, thanks!
On Fri, Jun 22, 2018 at 11:46:44PM +0800, air icy wrote:
> Hi,
>
> static inline bool addr4_match(__be32 a1, __be32 a2, u8 prefixlen)
> {
> /* C99 6.5.7 (3): u32 << 32 is undefined behaviour */
> if (sizeof(long) == 4 && prefixlen == 0)
> return true;
> return !((a1 ^ a2) & htonl(~0UL << (32 - pre
to workaround from userspace as
> xfrm_id_proto_match() will be always true for ah/esp/comp protos.
>
> v1 link: https://lkml.kernel.org/r/<20180502020220.2027-1-d...@arista.com>
>
> Cc: Masahide NAKAMURA
> Cc: YOSHIFUJI Hideaki
> Cc: Steffen Klassert
> Cc: "
On Wed, Apr 25, 2018 at 04:58:52PM +0200, Stefano Brivio wrote:
> On Wed, 25 Apr 2018 07:46:39 -0700
> Kees Cook wrote:
>
> > In the quest to remove all stack VLA usage removed from the kernel[1],
> > just use XFRM_MAX_DEPTH as already done for the "class" array. In one
> > case, it'll do this lo
On Sat, Apr 07, 2018 at 11:40:47AM -0400, Kevin Easton wrote:
> Several places use (x + 7) / 8 to convert from a number of bits to a number
> of bytes. Replace those with DIV_ROUND_UP(x, 8) instead, for consistency
> with other parts of the same file.
>
> Signed-off-by: Kevin Easton
Please resu
On Sat, Apr 07, 2018 at 11:40:33AM -0400, Kevin Easton wrote:
> Key extensions (struct sadb_key) include a user-specified number of key
> bits. The kernel uses that number to determine how much key data to copy
> out of the message in pfkey_msg2xfrm_state().
>
> The length of the sadb_key message
On Sat, Apr 07, 2018 at 11:40:18AM -0400, Kevin Easton wrote:
> As found by syzbot, af_key does not properly validate the key length in
> sadb_key messages from userspace. This can result in copying from beyond
> the end of the sadb_key part of the message, or indeed beyond the end of
> the entire
On Wed, Mar 28, 2018 at 09:35:26PM -0400, Kevin Easton wrote:
> On Wed, Mar 28, 2018 at 07:59:25AM +0200, Steffen Klassert wrote:
> > On Mon, Mar 26, 2018 at 07:39:16AM -0400, Kevin Easton wrote:
> > > Several places use (x + 7) / 8 to convert from a number of bits to a
>
rol buffer is still needed
for some layer 4 protocols. As a result the IPv4/IPv6 control
buffer is overwritten with this structure. Fix this by setting
a apropriate header in front of the structure.
Fixes acf568ee859f ("xfrm: Reinject transport-mode packets ...")
Signed-off-by: Steffen
On Mon, Mar 26, 2018 at 07:39:16AM -0400, Kevin Easton wrote:
> Several places use (x + 7) / 8 to convert from a number of bits to a number
> of bytes. Replace those with DIV_ROUND_UP(x, 8) instead, for consistency
> with other parts of the same file.
>
> Signed-off-by: Kevin Easton
Is this a f
On Tue, Mar 13, 2018 at 12:33:02AM -0700, syzbot wrote:
> Hello,
>
> syzbot hit the following crash on net-next commit
> f44b1886a5f876c87b5889df463ad7b97834ba37 (Fri Mar 9 18:10:06 2018 +)
> Merge branch 's390-qeth-next'
>
> Unfortunately, I don't have any reproducer for this crash yet.
> Ra
On Wed, Mar 07, 2018 at 02:42:53PM -0800, Greg Hackmann wrote:
> f7c83bcbfaf5 ("net: xfrm: use __this_cpu_read per-cpu helper") added a
> __this_cpu_read() call inside ipcomp_alloc_tfms().
>
> At the time, __this_cpu_read() required the caller to either not care
> about races or to handle preempti
On Sat, Mar 10, 2018 at 07:26:44PM +0100, Stefano Brivio wrote:
> On Sat, 10 Mar 2018 09:18:46 -0800
> Kees Cook wrote:
>
> > On Sat, Mar 10, 2018 at 12:43 AM, Stefano Brivio wrote:
> > > On Sat, 10 Mar 2018 09:40:44 +0200
> > > Andreas Christoforou wrote:
> > >
> > >> diff --git a/net/ipv6/x
On Fri, Mar 09, 2018 at 01:49:07PM +0100, Mathias Krause wrote:
> On 9 March 2018 at 13:21, Andreas Christoforou
> wrote:
> > The kernel would like to have all stack VLA usage removed[1].
> >
> > Signed-off-by: Andreas Christoforou
> > ---
> > net/ipv6/xfrm6_state.c | 8 +++-
> > 1 file chan
On Fri, Mar 09, 2018 at 02:21:46PM +0200, Andreas Christoforou wrote:
> The kernel would like to have all stack VLA usage removed[1].
>
> Signed-off-by: Andreas Christoforou
Can you please explain why you want this change?
On Mon, Mar 05, 2018 at 03:49:59PM -0600, Gustavo A. R. Silva wrote:
> Assign true or false to boolean variables instead of an integer value.
>
> This issue was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva
Patch applied to ipsec-next, thanks!
On Sun, Mar 04, 2018 at 09:03:52PM +0200, yoss...@mellanox.com wrote:
> From: Yossi Kuperman
>
> Artem Savkov reported that commit 5efec5c655dd leads to a packet loss under
> IPSec configuration. It appears that his setup consists of a TUN device,
> which does not have a MAC header.
>
> Make sur
On Mon, Feb 19, 2018 at 11:05:38AM +0100, Dmitry Vyukov wrote:
> On Mon, Feb 19, 2018 at 8:22 AM, Steffen Klassert
> wrote:
> >> > wrote:
> >> >> Hello,
> >> >>
> >> >> syzbot hit the following crash on net-next commit
> >&g
On Tue, Feb 13, 2018 at 10:19:17AM +0100, Dmitry Vyukov wrote:
> On Mon, Feb 12, 2018 at 4:26 PM, Dmitry Vyukov wrote:
> > On Mon, Feb 12, 2018 at 4:23 PM, syzbot
> > wrote:
> >> Hello,
> >>
> >> syzbot hit the following crash on net-next commit
> >> 9515a2e082f91457db0ecff4b65371d0fb5d9aad (Thu
On Fri, Feb 02, 2018 at 08:37:50AM +0100, Steffen Klassert wrote:
> On Tue, Jan 30, 2018 at 02:53:48PM +, Colin King wrote:
> > From: Colin Ian King
> >
> > Pointer esph is being assigned a value that is never read, esph is
> > re-assigned and only read inside
On Tue, Jan 30, 2018 at 02:53:48PM +, Colin King wrote:
> From: Colin Ian King
>
> Pointer esph is being assigned a value that is never read, esph is
> re-assigned and only read inside an if statement, hence the
> initialization is redundant and can be removed.
>
> Cleans up clang warning:
>
On Thu, Feb 01, 2018 at 11:30:00AM +0100, Dmitry Vyukov wrote:
> On Thu, Feb 1, 2018 at 9:34 AM, Steffen Klassert
>
> Hi Steffen,
>
> Please see the email footer:
>
> > If you want to test a patch for this bug, please reply with:
> > #syz test: git://repo/address.
have different sizes in this case. This results in
a broken confuguration, so refuse to configure socket policies
when trying to insert from 32 bit userspace as we do it already
with policies inserted via netlink.
Signed-off-by: Steffen Klassert
---
net/xfrm/xfrm_state.c | 5 +
1 file changed
rypto_user_stat.c
> > => this imply also to change makefile (rename crypto_user.c to
> > crypto_user_base.c) since crypto_user.ko is made of two files.
> >
> > Which one do you prefer ?
>
> I think you should check with the crconf author, Steffen Klassert
&
On Mon, Jan 22, 2018 at 04:34:09PM -0600, Gustavo A. R. Silva wrote:
> Assign true or false to boolean variables instead of an integer value.
>
> This issue was detected with the help of Coccinelle.
>
> Fixes: ffdb5211da1c ("xfrm: Auto-load xfrm offload modules")
> Signed-off-by: Gustavo A. R. Si
1 - 100 of 222 matches
Mail list logo
