Re: [PATCH] esp6: Simplify the calculation of variables

r 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

Re: [PATCH] xfrm/compat: Cleanup WARN()s that can be user-triggered

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 > Cc: St

Re: [PATCH net-next] ipv6: fix clang Wformat warning

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] >

Re: [PATCH v1 0/2] net: xfrm: Use seqcount_spinlock_t

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

Re: [PATCH] esp6: remove a duplicative condition

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!

Re: [PATCH] esp4: Simplify the calculation of variables

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!

Re: [PATCH v2 1/1] xfrm: Use actual socket sk instead of skb socket for xfrm_output_resume

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

Re: [PATCH v2] xfrm: Fix incorrect types in assignment

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

Re: [PATCH] xfrm: Use actual socket sk instead of skb socket for xfrm_output_resume

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

Re: [PATCH net-next] xfrm: Return the correct errno code

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!

Re: [PATCH] esp: Simplify the calculation of variables

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!

Re: [PATCH v2] net: Simplify the calculation of variables

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!

Re: [PATCH net v3] udp: ipv4: manipulate network header of NATed UDP GRO fraglist

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

Re: [PATCH net v3] udp: ipv4: manipulate network header of NATed UDP GRO fraglist

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, > > > +

Re: [PATCH net v2] udp: ipv4: manipulate network header of NATed UDP GRO fraglist

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

Re: [PATCH net v2] udp: ipv4: manipulate network header of NATed UDP GRO fraglist

the 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

Re: [PATCH net v2] udp: ipv4: manipulate network header of NATed UDP GRO fraglist

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

Re: [PATCH net v2] udp: ipv4: manipulate network header of NATed UDP GRO fraglist

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.) > >

Re: [PATCH net] udp: ipv4: manipulate network header of NATed UDP GRO fraglist

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

Re: [PATCH net] udp: ipv4: manipulate network header of NATed UDP GRO fraglist

ecases? 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.) > Sig

Re: [RFC PATCH net] udp: check sk for UDP GRO fraglist

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

Re: [RFC PATCH net] udp: check sk for UDP GRO fraglist

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

Re: [PATCH] selftests: xfrm: fix test return value override issue in xfrm_policy.sh

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

Re: linux-next: Signed-off-by missing for commit in the ipsec tree

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.

Re: USGv6 Tunnel Mode Fragmentation Failures

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

Re: [PATCH] net: xfrm: fix memory leak in xfrm_user_policy()

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 >

Re: [PATCH v2 0/3] xfrm/compat: syzbot-found fixes

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): > xfrm/c

Re: [PATCH] xfrm:fragmented ipv4 tunnel packets in inner interface

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 with out

Re: [PATCH 0/3] xfrm/compat: syzbot-found fixes

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. > > Cc: S

Re: WARNING in xfrm_alloc_compat

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

Re: KASAN: slab-out-of-bounds Write in xfrm_attr_cpy32

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

Re: [PATCH v2] net: xfrm: fix a race condition during allocing spi

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 >

Re: [PATCH v3 0/7] xfrm: Add compat layer

(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

Re: [PATCH] xfrm: Use correct address family in xfrm_state_find

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

Re: KASAN: stack-out-of-bounds Read in xfrm_selector_match (2)

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 c

Re: KASAN: stack-out-of-bounds Read in xfrm_selector_match (2)

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 >

Re: [PATCH] xfrm:fragmented ipv4 tunnel packets in inner interface

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

Re: KASAN: use-after-free Read in __xfrm6_tunnel_spi_lookup

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? > > > >

Re: [PATCH v2 1/6] xfrm/compat: Add 64=>32-bit messages translator

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

Re: [PATCH v2 0/6] xfrm: Add compat layer

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) > -

Re: [PATCH v2] padata: add another maintainer and another list

Great, thanks a lot Daniel! Acked-by: Steffen Klassert

Re: [PATCH] padata: add a reviewer

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

Re: [PATCH net-next] ip_vti: Fix unused variable warning

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!

Re: [PATCH net-next] ip_vti: Fix unused variable warning

o 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

Re: [PATCH v2] net: ipv6: fix use-after-free Read in __xfrm6_tunnel_spi_lookup

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); > >

Re: [PATCH] net: xfrm: xfrm_policy.c: remove some unnecessary cases in decode_session6

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

Re: [PATCH v2] af_key: pfkey_dump needs parameter validation

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!

Re: af_key: pfkey_dump needs parameter validation

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

Re: af_key: pfkey_dump needs parameter validation

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. >

Re: mmotm 2020-07-20-19-06 uploaded (net/ipv6/ip6_vti.o)

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: > >

Re: KASAN: slab-out-of-bounds Read in __xfrm6_tunnel_spi_lookup

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.

Re: KASAN: slab-out-of-bounds Read in __xfrm6_tunnel_spi_lookup

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

Re: [PATCH net-next v2] xfrm: introduce oseq-may-wrap flag

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

Re: linux-next: manual merge of the ipsec-next tree with Linus' tree

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

Re: linux-next: manual merge of the ipsec-next tree with Linus' tree

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

Re: linux-next: manual merge of the ipsec-next tree with Linus' tree

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

Re: [PATCH v2] xfrm: policy: Fix xfrm policy match

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.

Re: [PATCH] xfrm : lock input tasklet skb queue

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(>queue, skb); > tasklet_schedule(>tasklet); > Where the

Re: [BUG] net: xfrm: possible null-pointer dereferences in xfrm_policy()

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

Re: [PATCH] net: key: af_key: Fix possible null-pointer dereferences in pfkey_send_policy_notify()

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

Re: [PATCH] net: key: af_key: Fix possible null-pointer dereferences in pfkey_send_policy_notify()

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: >

Re: [PATCH] padata: use smp_mb in padata_reorder to avoid orphaned padata jobs

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 >

Re: [PATCH] [v2] ipsec: select crypto ciphers for xfrm_algo

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'

Re: [PATCH] af_key: Fix memory leak in key_notify_policy.

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

Re: [PATCH][next] xfrm: fix missing break on AF_INET6 case

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. > >

Re: [PATCH net] xfrm: Fix xfrm sel prefix length validation

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

Re: [PATCH] xfrm: Reset secpath in xfrm failure

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

Re: [PATCH v2] net: xfrm: Add '_rcu' tag for rcu protected pointer in netns_xfrm

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 >

Re: [PATCH] net: xfrm: Fix potential oops in xfrm_user_rcv_msg and array out of bounds

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

Re: [PATCH] xfrm: policy: Fix out-of-bound array accesses in __xfrm_policy_unlink

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]'

Re: [PATCH v2] vti4: Fix a ipip packet processing bug in 'IPCOMP' virtual tunnel

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

Re: [PATCH] vti4: Fix a ipip packet processing bug in 'IPCOMP' virtual tunnel

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 > > > i

Re: [PATCH] vti4: Fix a ipip packet processing bug in 'IPCOMP' virtual tunnel

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

Re: [PATCH net-next] xfrm6_tunnel: Fix spi check in __xfrm6_tunnel_alloc_spi

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

Re: [PATCH] xfrm: clean an indentation issue, remove a space

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!

Re: UBSAN: Undefined behaviour in ./include/net/xfrm.h

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 -

Re: UBSAN: Undefined behaviour in ./include/net/xfrm.h

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 -

Re: [PATCHv2] net/xfrm: Revert "[XFRM]: Do not add a state whose SPI is zero to the SPI hash."

und 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 <na...@linux-ipv6.org> > Cc: YOSHIFUJI Hideaki <yoshf...@linux-ipv6.org> &g

Re: [PATCHv2] net/xfrm: Revert "[XFRM]: Do not add a state whose SPI is zero to the SPI hash."

und 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: "David S. Miller"

Re: [PATCH v4 ipsec-next] xfrm: remove VLA usage in __xfrm6_sort()

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 >

Re: [PATCH v4 ipsec-next] xfrm: remove VLA usage in __xfrm6_sort()

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

Re: [PATCH v2 2/2] af_key: Use DIV_ROUND_UP() instead of open-coded equivalent

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

Re: [PATCH v2 2/2] af_key: Use DIV_ROUND_UP() instead of open-coded equivalent

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

Re: [PATCH v2 1/2] af_key: Always verify length of provided sadb_key

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

Re: [PATCH v2 1/2] af_key: Always verify length of provided sadb_key

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

Re: [PATCH v2 0/2] af_key: Fix for sadb_key memcpy read overrun

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

Re: [PATCH v2 0/2] af_key: Fix for sadb_key memcpy read overrun

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

Re: [PATCH 1/2] af_key: Use DIV_ROUND_UP() instead of open-coded equivalent

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

Re: [PATCH 1/2] af_key: Use DIV_ROUND_UP() instead of open-coded equivalent

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

Re: Regression in 4.16-rc7 - ipsec vpn broken

control 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: Steffe

Re: Regression in 4.16-rc7 - ipsec vpn broken

control 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

Re: [PATCH 1/2] af_key: Use DIV_ROUND_UP() instead of open-coded equivalent

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

Re: [PATCH 1/2] af_key: Use DIV_ROUND_UP() instead of open-coded equivalent

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

Re: WARNING in kmalloc_slab (4)

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. >

Re: WARNING in kmalloc_slab (4)

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. >

Re: [PATCH v2 net] net: xfrm: use preempt-safe this_cpu_read() in ipcomp_alloc_tfms()

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

Re: [PATCH v2 net] net: xfrm: use preempt-safe this_cpu_read() in ipcomp_alloc_tfms()

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

Re: [PATCH v2] net: ipv6: xfrm6_state: remove VLA usage

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

Re: [PATCH v2] net: ipv6: xfrm6_state: remove VLA usage

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

Re: [PATCH] net: ipv6: xfrm6_state: remove VLA usage

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 > > ---

  1   2   3   4   >