BUSINESS PROPOSAL !!!
by Patrick Sullivan
Dearest Friend
I am Patrick Sullivan,staff of Emirate NBD Bank Dubai office,I am Group Chief Financial Officer and Asset Management, I am pleased to get across to you for a very urgent and profitable business proposal which I believe will profit the both of us after completion,Please email me now for more details and understanding.
Await your urgent response.
Regards
Patrick Sullivan
10 months, 3 weeks
Re: general protection fault in selinux_socket_recvmsg
by Ondrej Mosnacek
On Sat, May 23, 2020 at 9:14 AM syzbot
<syzbot+c6bfc3db991edc918432(a)syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 051143e1 Merge tag 'apparmor-pr-2020-05-21' of git://git.k..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1313f016100000
> kernel config: https://syzkaller.appspot.com/x/.config?x=b3368ce0cc5f5ace
> dashboard link: https://syzkaller.appspot.com/bug?extid=c6bfc3db991edc918432
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13eeacba100000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=167163e6100000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+c6bfc3db991edc918432(a)syzkaller.appspotmail.com
>
> general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN
> KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
> CPU: 0 PID: 7370 Comm: syz-executor283 Not tainted 5.7.0-rc6-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> RIP: 0010:selinux_socket_recvmsg+0x1e/0x40 security/selinux/hooks.c:4841
OK, this is obviously not a SELinux bug - the hook just gets sock ==
NULL from the net stack, which is just plain wrong...
> Code: e8 77 f9 1e fe 48 89 ef 5d eb b1 90 53 48 89 fb e8 67 f9 1e fe 48 8d 7b 18 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 0f 48 8b 7b 18 be 02 00 00 00 5b e9 7d fc ff ff e8
> RSP: 0018:ffffc900019d7a58 EFLAGS: 00010206
> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000040000000
> RDX: 0000000000000003 RSI: ffffffff83543bb9 RDI: 0000000000000018
> RBP: dffffc0000000000 R08: ffff88809f45a180 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: dffffc0000000000
> R13: ffffc900019d7d78 R14: 0000000000001000 R15: 0000000040000000
> FS: 00007f5ffb311700(0000) GS:ffff8880ae600000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f5ffb2efe78 CR3: 00000000a33c1000 CR4: 00000000001406f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> security_socket_recvmsg+0x78/0xc0 security/security.c:2070
> sock_recvmsg+0x47/0x110 net/socket.c:902
> mptcp_recvmsg+0xb3b/0xd90 net/mptcp/protocol.c:891
...but this function looks suspicious. If the "unlikely(ssock)" check
at [1] fails, then we continue in the rest of the function with ssock
== NULL. However, when the "unlikely(__mptcp_tcp_fallback(msk))" check
at [2] succeeds, we jump to the "fallback" label, where it is assumed
that ssock != NULL. That seems like an obvious bug to me and I bet
that's what causes the crash.
If I understand the code correctly, the fix should be just to change
this at [2]:
- if (unlikely(__mptcp_tcp_fallback(msk)))
+ if (unlikely(ssock = __mptcp_tcp_fallback(msk)))
@MPTCP folks, can you have a look?
[1] https://elixir.bootlin.com/linux/v5.7-rc6/source/net/mptcp/protocol.c#L886
[2] https://elixir.bootlin.com/linux/v5.7-rc6/source/net/mptcp/protocol.c#L957
> inet_recvmsg+0x121/0x5d0 net/ipv4/af_inet.c:838
> sock_recvmsg_nosec net/socket.c:886 [inline]
> sock_recvmsg net/socket.c:904 [inline]
> sock_recvmsg+0xca/0x110 net/socket.c:900
> __sys_recvfrom+0x1c5/0x2f0 net/socket.c:2057
> __do_sys_recvfrom net/socket.c:2075 [inline]
> __se_sys_recvfrom net/socket.c:2071 [inline]
> __x64_sys_recvfrom+0xdd/0x1b0 net/socket.c:2071
> do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
> entry_SYSCALL_64_after_hwframe+0x49/0xb3
> RIP: 0033:0x448ef9
> Code: e8 cc 14 03 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 9b 0c fc ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007f5ffb310da8 EFLAGS: 00000246 ORIG_RAX: 000000000000002d
> RAX: ffffffffffffffda RBX: 00000000006dec28 RCX: 0000000000448ef9
> RDX: 0000000000001000 RSI: 00000000200004c0 RDI: 0000000000000003
> RBP: 00000000006dec20 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000040000000 R11: 0000000000000246 R12: 00000000006dec2c
> R13: 00007ffc3a001ccf R14: 00007f5ffb3119c0 R15: 00000000006dec2c
> Modules linked in:
> ---[ end trace 60e1f3eb5a5b83ce ]---
> RIP: 0010:selinux_socket_recvmsg+0x1e/0x40 security/selinux/hooks.c:4841
> Code: e8 77 f9 1e fe 48 89 ef 5d eb b1 90 53 48 89 fb e8 67 f9 1e fe 48 8d 7b 18 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 0f 48 8b 7b 18 be 02 00 00 00 5b e9 7d fc ff ff e8
> RSP: 0018:ffffc900019d7a58 EFLAGS: 00010206
> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000040000000
> RDX: 0000000000000003 RSI: ffffffff83543bb9 RDI: 0000000000000018
> RBP: dffffc0000000000 R08: ffff88809f45a180 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: dffffc0000000000
> R13: ffffc900019d7d78 R14: 0000000000001000 R15: 0000000040000000
> FS: 00007f5ffb311700(0000) GS:ffff8880ae600000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f5ffb2efe78 CR3: 00000000a33c1000 CR4: 00000000001406f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller(a)googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
>
--
Ondrej Mosnacek <omosnace at redhat dot com>
Software Engineer, Security Technologies
Red Hat, Inc.
10 months, 3 weeks
[PATCH net] mptcp: use untruncated hash in ADD_ADDR HMAC
by Todd Malsbary
There is some ambiguity in the RFC as to whether the ADD_ADDR HMAC is
the rightmost 64 bits of the entire hash or of the leftmost 160 bits
of the hash. The intention, as clarified with the author of the RFC,
is the entire hash.
This change returns the entire hash from
mptcp_crypto_hmac_sha (instead of only the first 160 bits), and moves
any truncation/selection operation on the hash to the caller.
Fixes: 12555a2d97e5 ("mptcp: use rightmost 64 bits in ADD_ADDR HMAC")
Reviewed-by: Christoph Paasch <cpaasch(a)apple.com>
Reviewed-by: Mat Martineau <mathew.j.martineau(a)linux.intel.com>
Signed-off-by: Todd Malsbary <todd.malsbary(a)linux.intel.com>
---
net/mptcp/crypto.c | 24 +++++++++---------------
net/mptcp/options.c | 9 +++++----
net/mptcp/protocol.h | 1 -
net/mptcp/subflow.c | 15 ++++++++++-----
4 files changed, 24 insertions(+), 25 deletions(-)
diff --git a/net/mptcp/crypto.c b/net/mptcp/crypto.c
index c151628bd416..0f5a414a9366 100644
--- a/net/mptcp/crypto.c
+++ b/net/mptcp/crypto.c
@@ -47,8 +47,6 @@ void mptcp_crypto_key_sha(u64 key, u32 *token, u64 *idsn)
void mptcp_crypto_hmac_sha(u64 key1, u64 key2, u8 *msg, int len, void *hmac)
{
u8 input[SHA256_BLOCK_SIZE + SHA256_DIGEST_SIZE];
- __be32 mptcp_hashed_key[SHA256_DIGEST_WORDS];
- __be32 *hash_out = (__force __be32 *)hmac;
struct sha256_state state;
u8 key1be[8];
u8 key2be[8];
@@ -86,11 +84,7 @@ void mptcp_crypto_hmac_sha(u64 key1, u64 key2, u8 *msg, int len, void *hmac)
sha256_init(&state);
sha256_update(&state, input, SHA256_BLOCK_SIZE + SHA256_DIGEST_SIZE);
- sha256_final(&state, (u8 *)mptcp_hashed_key);
-
- /* takes only first 160 bits */
- for (i = 0; i < 5; i++)
- hash_out[i] = mptcp_hashed_key[i];
+ sha256_final(&state, (u8 *)hmac);
}
#ifdef CONFIG_MPTCP_HMAC_TEST
@@ -101,29 +95,29 @@ struct test_cast {
};
/* we can't reuse RFC 4231 test vectors, as we have constraint on the
- * input and key size, and we truncate the output.
+ * input and key size.
*/
static struct test_cast tests[] = {
{
.key = "0b0b0b0b0b0b0b0b",
.msg = "48692054",
- .result = "8385e24fb4235ac37556b6b886db106284a1da67",
+ .result = "8385e24fb4235ac37556b6b886db106284a1da671699f46db1f235ec622dcafa",
},
{
.key = "aaaaaaaaaaaaaaaa",
.msg = "dddddddd",
- .result = "2c5e219164ff1dca1c4a92318d847bb6b9d44492",
+ .result = "2c5e219164ff1dca1c4a92318d847bb6b9d44492984e1eb71aff9022f71046e9",
},
{
.key = "0102030405060708",
.msg = "cdcdcdcd",
- .result = "e73b9ba9969969cefb04aa0d6df18ec2fcc075b6",
+ .result = "e73b9ba9969969cefb04aa0d6df18ec2fcc075b6f23b4d8c4da736a5dbbc6e7d",
},
};
static int __init test_mptcp_crypto(void)
{
- char hmac[20], hmac_hex[41];
+ char hmac[32], hmac_hex[65];
u32 nonce1, nonce2;
u64 key1, key2;
u8 msg[8];
@@ -140,11 +134,11 @@ static int __init test_mptcp_crypto(void)
put_unaligned_be32(nonce2, &msg[4]);
mptcp_crypto_hmac_sha(key1, key2, msg, 8, hmac);
- for (j = 0; j < 20; ++j)
+ for (j = 0; j < 32; ++j)
sprintf(&hmac_hex[j << 1], "%02x", hmac[j] & 0xff);
- hmac_hex[40] = 0;
+ hmac_hex[64] = 0;
- if (memcmp(hmac_hex, tests[i].result, 40))
+ if (memcmp(hmac_hex, tests[i].result, 64))
pr_err("test %d failed, got %s expected %s", i,
hmac_hex, tests[i].result);
else
diff --git a/net/mptcp/options.c b/net/mptcp/options.c
index b88fae233a62..7793b6011fa7 100644
--- a/net/mptcp/options.c
+++ b/net/mptcp/options.c
@@ -7,6 +7,7 @@
#define pr_fmt(fmt) "MPTCP: " fmt
#include <linux/kernel.h>
+#include <crypto/sha.h>
#include <net/tcp.h>
#include <net/mptcp.h>
#include "protocol.h"
@@ -535,7 +536,7 @@ static bool mptcp_established_options_dss(struct sock *sk, struct sk_buff *skb,
static u64 add_addr_generate_hmac(u64 key1, u64 key2, u8 addr_id,
struct in_addr *addr)
{
- u8 hmac[MPTCP_ADDR_HMAC_LEN];
+ u8 hmac[SHA256_DIGEST_SIZE];
u8 msg[7];
msg[0] = addr_id;
@@ -545,14 +546,14 @@ static u64 add_addr_generate_hmac(u64 key1, u64 key2, u8 addr_id,
mptcp_crypto_hmac_sha(key1, key2, msg, 7, hmac);
- return get_unaligned_be64(&hmac[MPTCP_ADDR_HMAC_LEN - sizeof(u64)]);
+ return get_unaligned_be64(&hmac[SHA256_DIGEST_SIZE - sizeof(u64)]);
}
#if IS_ENABLED(CONFIG_MPTCP_IPV6)
static u64 add_addr6_generate_hmac(u64 key1, u64 key2, u8 addr_id,
struct in6_addr *addr)
{
- u8 hmac[MPTCP_ADDR_HMAC_LEN];
+ u8 hmac[SHA256_DIGEST_SIZE];
u8 msg[19];
msg[0] = addr_id;
@@ -562,7 +563,7 @@ static u64 add_addr6_generate_hmac(u64 key1, u64 key2, u8 addr_id,
mptcp_crypto_hmac_sha(key1, key2, msg, 19, hmac);
- return get_unaligned_be64(&hmac[MPTCP_ADDR_HMAC_LEN - sizeof(u64)]);
+ return get_unaligned_be64(&hmac[SHA256_DIGEST_SIZE - sizeof(u64)]);
}
#endif
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index e4ca6320ce76..d0803dfb8108 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -81,7 +81,6 @@
/* MPTCP ADD_ADDR flags */
#define MPTCP_ADDR_ECHO BIT(0)
-#define MPTCP_ADDR_HMAC_LEN 20
#define MPTCP_ADDR_IPVERSION_4 4
#define MPTCP_ADDR_IPVERSION_6 6
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index 4931a29a6f08..8968b2c065e7 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -10,6 +10,7 @@
#include <linux/module.h>
#include <linux/netdevice.h>
#include <crypto/algapi.h>
+#include <crypto/sha.h>
#include <net/sock.h>
#include <net/inet_common.h>
#include <net/inet_hashtables.h>
@@ -89,7 +90,7 @@ static bool subflow_token_join_request(struct request_sock *req,
const struct sk_buff *skb)
{
struct mptcp_subflow_request_sock *subflow_req = mptcp_subflow_rsk(req);
- u8 hmac[MPTCPOPT_HMAC_LEN];
+ u8 hmac[SHA256_DIGEST_SIZE];
struct mptcp_sock *msk;
int local_id;
@@ -201,7 +202,7 @@ static void subflow_v6_init_req(struct request_sock *req,
/* validate received truncated hmac and create hmac for third ACK */
static bool subflow_thmac_valid(struct mptcp_subflow_context *subflow)
{
- u8 hmac[MPTCPOPT_HMAC_LEN];
+ u8 hmac[SHA256_DIGEST_SIZE];
u64 thmac;
subflow_generate_hmac(subflow->remote_key, subflow->local_key,
@@ -267,6 +268,8 @@ static void subflow_finish_connect(struct sock *sk, const struct sk_buff *skb)
subflow->ssn_offset = TCP_SKB_CB(skb)->seq;
}
} else if (subflow->mp_join) {
+ u8 hmac[SHA256_DIGEST_SIZE];
+
pr_debug("subflow=%p, thmac=%llu, remote_nonce=%u",
subflow, subflow->thmac,
subflow->remote_nonce);
@@ -279,7 +282,9 @@ static void subflow_finish_connect(struct sock *sk, const struct sk_buff *skb)
subflow_generate_hmac(subflow->local_key, subflow->remote_key,
subflow->local_nonce,
subflow->remote_nonce,
- subflow->hmac);
+ hmac);
+
+ memcpy(subflow->hmac, hmac, MPTCPOPT_HMAC_LEN);
if (skb)
subflow->ssn_offset = TCP_SKB_CB(skb)->seq;
@@ -347,7 +352,7 @@ static bool subflow_hmac_valid(const struct request_sock *req,
const struct mptcp_options_received *mp_opt)
{
const struct mptcp_subflow_request_sock *subflow_req;
- u8 hmac[MPTCPOPT_HMAC_LEN];
+ u8 hmac[SHA256_DIGEST_SIZE];
struct mptcp_sock *msk;
bool ret;
@@ -361,7 +366,7 @@ static bool subflow_hmac_valid(const struct request_sock *req,
subflow_req->local_nonce, hmac);
ret = true;
- if (crypto_memneq(hmac, mp_opt->hmac, sizeof(hmac)))
+ if (crypto_memneq(hmac, mp_opt->hmac, MPTCPOPT_HMAC_LEN))
ret = false;
sock_put((struct sock *)msk);
--
2.25.4
10 months, 3 weeks
New Order Request
by John Wallace
Hello Greetings Our company is in need of the following product from you, One of our partners refereed us to you, We need your urgent attention on this. I have attached all product details for your to go through and get back to me Provide us with your Purchase price and shipping requirements Condition of Products What is the Referral fee payable? Regards, John Wallace
10 months, 3 weeks
[PATCH v2 mptcp] mptcp: use untruncated hash in ADD_ADDR HMAC
by Todd Malsbary
There is some ambiguity in the RFC as to whether the ADD_ADDR HMAC is
the rightmost 64 bits of the entire hash or of the leftmost 160 bits
of the hash. The intention, as clarified with the author of the RFC,
is the entire hash.
This change returns the entire hash from
mptcp_crypto_hmac_sha (instead of only the first 160 bits), and moves
any truncation/selection operation on the hash to the caller.
v1 -> v2:
- move the hmac declaration in subflow_finish_connect to where it is
used (Christoph)
Fixes: 12555a2d97e5 ("mptcp: use rightmost 64 bits in ADD_ADDR HMAC")
Signed-off-by: Todd Malsbary <todd.malsbary(a)linux.intel.com>
---
net/mptcp/crypto.c | 24 +++++++++---------------
net/mptcp/options.c | 9 +++++----
net/mptcp/protocol.h | 1 -
net/mptcp/subflow.c | 15 ++++++++++-----
4 files changed, 24 insertions(+), 25 deletions(-)
diff --git a/net/mptcp/crypto.c b/net/mptcp/crypto.c
index c151628bd416..0f5a414a9366 100644
--- a/net/mptcp/crypto.c
+++ b/net/mptcp/crypto.c
@@ -47,8 +47,6 @@ void mptcp_crypto_key_sha(u64 key, u32 *token, u64 *idsn)
void mptcp_crypto_hmac_sha(u64 key1, u64 key2, u8 *msg, int len, void *hmac)
{
u8 input[SHA256_BLOCK_SIZE + SHA256_DIGEST_SIZE];
- __be32 mptcp_hashed_key[SHA256_DIGEST_WORDS];
- __be32 *hash_out = (__force __be32 *)hmac;
struct sha256_state state;
u8 key1be[8];
u8 key2be[8];
@@ -86,11 +84,7 @@ void mptcp_crypto_hmac_sha(u64 key1, u64 key2, u8 *msg, int len, void *hmac)
sha256_init(&state);
sha256_update(&state, input, SHA256_BLOCK_SIZE + SHA256_DIGEST_SIZE);
- sha256_final(&state, (u8 *)mptcp_hashed_key);
-
- /* takes only first 160 bits */
- for (i = 0; i < 5; i++)
- hash_out[i] = mptcp_hashed_key[i];
+ sha256_final(&state, (u8 *)hmac);
}
#ifdef CONFIG_MPTCP_HMAC_TEST
@@ -101,29 +95,29 @@ struct test_cast {
};
/* we can't reuse RFC 4231 test vectors, as we have constraint on the
- * input and key size, and we truncate the output.
+ * input and key size.
*/
static struct test_cast tests[] = {
{
.key = "0b0b0b0b0b0b0b0b",
.msg = "48692054",
- .result = "8385e24fb4235ac37556b6b886db106284a1da67",
+ .result = "8385e24fb4235ac37556b6b886db106284a1da671699f46db1f235ec622dcafa",
},
{
.key = "aaaaaaaaaaaaaaaa",
.msg = "dddddddd",
- .result = "2c5e219164ff1dca1c4a92318d847bb6b9d44492",
+ .result = "2c5e219164ff1dca1c4a92318d847bb6b9d44492984e1eb71aff9022f71046e9",
},
{
.key = "0102030405060708",
.msg = "cdcdcdcd",
- .result = "e73b9ba9969969cefb04aa0d6df18ec2fcc075b6",
+ .result = "e73b9ba9969969cefb04aa0d6df18ec2fcc075b6f23b4d8c4da736a5dbbc6e7d",
},
};
static int __init test_mptcp_crypto(void)
{
- char hmac[20], hmac_hex[41];
+ char hmac[32], hmac_hex[65];
u32 nonce1, nonce2;
u64 key1, key2;
u8 msg[8];
@@ -140,11 +134,11 @@ static int __init test_mptcp_crypto(void)
put_unaligned_be32(nonce2, &msg[4]);
mptcp_crypto_hmac_sha(key1, key2, msg, 8, hmac);
- for (j = 0; j < 20; ++j)
+ for (j = 0; j < 32; ++j)
sprintf(&hmac_hex[j << 1], "%02x", hmac[j] & 0xff);
- hmac_hex[40] = 0;
+ hmac_hex[64] = 0;
- if (memcmp(hmac_hex, tests[i].result, 40))
+ if (memcmp(hmac_hex, tests[i].result, 64))
pr_err("test %d failed, got %s expected %s", i,
hmac_hex, tests[i].result);
else
diff --git a/net/mptcp/options.c b/net/mptcp/options.c
index b88fae233a62..7793b6011fa7 100644
--- a/net/mptcp/options.c
+++ b/net/mptcp/options.c
@@ -7,6 +7,7 @@
#define pr_fmt(fmt) "MPTCP: " fmt
#include <linux/kernel.h>
+#include <crypto/sha.h>
#include <net/tcp.h>
#include <net/mptcp.h>
#include "protocol.h"
@@ -535,7 +536,7 @@ static bool mptcp_established_options_dss(struct sock *sk, struct sk_buff *skb,
static u64 add_addr_generate_hmac(u64 key1, u64 key2, u8 addr_id,
struct in_addr *addr)
{
- u8 hmac[MPTCP_ADDR_HMAC_LEN];
+ u8 hmac[SHA256_DIGEST_SIZE];
u8 msg[7];
msg[0] = addr_id;
@@ -545,14 +546,14 @@ static u64 add_addr_generate_hmac(u64 key1, u64 key2, u8 addr_id,
mptcp_crypto_hmac_sha(key1, key2, msg, 7, hmac);
- return get_unaligned_be64(&hmac[MPTCP_ADDR_HMAC_LEN - sizeof(u64)]);
+ return get_unaligned_be64(&hmac[SHA256_DIGEST_SIZE - sizeof(u64)]);
}
#if IS_ENABLED(CONFIG_MPTCP_IPV6)
static u64 add_addr6_generate_hmac(u64 key1, u64 key2, u8 addr_id,
struct in6_addr *addr)
{
- u8 hmac[MPTCP_ADDR_HMAC_LEN];
+ u8 hmac[SHA256_DIGEST_SIZE];
u8 msg[19];
msg[0] = addr_id;
@@ -562,7 +563,7 @@ static u64 add_addr6_generate_hmac(u64 key1, u64 key2, u8 addr_id,
mptcp_crypto_hmac_sha(key1, key2, msg, 19, hmac);
- return get_unaligned_be64(&hmac[MPTCP_ADDR_HMAC_LEN - sizeof(u64)]);
+ return get_unaligned_be64(&hmac[SHA256_DIGEST_SIZE - sizeof(u64)]);
}
#endif
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index e4ca6320ce76..d0803dfb8108 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -81,7 +81,6 @@
/* MPTCP ADD_ADDR flags */
#define MPTCP_ADDR_ECHO BIT(0)
-#define MPTCP_ADDR_HMAC_LEN 20
#define MPTCP_ADDR_IPVERSION_4 4
#define MPTCP_ADDR_IPVERSION_6 6
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index 4931a29a6f08..8968b2c065e7 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -10,6 +10,7 @@
#include <linux/module.h>
#include <linux/netdevice.h>
#include <crypto/algapi.h>
+#include <crypto/sha.h>
#include <net/sock.h>
#include <net/inet_common.h>
#include <net/inet_hashtables.h>
@@ -89,7 +90,7 @@ static bool subflow_token_join_request(struct request_sock *req,
const struct sk_buff *skb)
{
struct mptcp_subflow_request_sock *subflow_req = mptcp_subflow_rsk(req);
- u8 hmac[MPTCPOPT_HMAC_LEN];
+ u8 hmac[SHA256_DIGEST_SIZE];
struct mptcp_sock *msk;
int local_id;
@@ -201,7 +202,7 @@ static void subflow_v6_init_req(struct request_sock *req,
/* validate received truncated hmac and create hmac for third ACK */
static bool subflow_thmac_valid(struct mptcp_subflow_context *subflow)
{
- u8 hmac[MPTCPOPT_HMAC_LEN];
+ u8 hmac[SHA256_DIGEST_SIZE];
u64 thmac;
subflow_generate_hmac(subflow->remote_key, subflow->local_key,
@@ -267,6 +268,8 @@ static void subflow_finish_connect(struct sock *sk, const struct sk_buff *skb)
subflow->ssn_offset = TCP_SKB_CB(skb)->seq;
}
} else if (subflow->mp_join) {
+ u8 hmac[SHA256_DIGEST_SIZE];
+
pr_debug("subflow=%p, thmac=%llu, remote_nonce=%u",
subflow, subflow->thmac,
subflow->remote_nonce);
@@ -279,7 +282,9 @@ static void subflow_finish_connect(struct sock *sk, const struct sk_buff *skb)
subflow_generate_hmac(subflow->local_key, subflow->remote_key,
subflow->local_nonce,
subflow->remote_nonce,
- subflow->hmac);
+ hmac);
+
+ memcpy(subflow->hmac, hmac, MPTCPOPT_HMAC_LEN);
if (skb)
subflow->ssn_offset = TCP_SKB_CB(skb)->seq;
@@ -347,7 +352,7 @@ static bool subflow_hmac_valid(const struct request_sock *req,
const struct mptcp_options_received *mp_opt)
{
const struct mptcp_subflow_request_sock *subflow_req;
- u8 hmac[MPTCPOPT_HMAC_LEN];
+ u8 hmac[SHA256_DIGEST_SIZE];
struct mptcp_sock *msk;
bool ret;
@@ -361,7 +366,7 @@ static bool subflow_hmac_valid(const struct request_sock *req,
subflow_req->local_nonce, hmac);
ret = true;
- if (crypto_memneq(hmac, mp_opt->hmac, sizeof(hmac)))
+ if (crypto_memneq(hmac, mp_opt->hmac, MPTCPOPT_HMAC_LEN))
ret = false;
sock_put((struct sock *)msk);
--
2.25.4
10 months, 3 weeks
[PATCH mptcp] mptcp: use untruncated hash in ADD_ADDR HMAC
by Todd Malsbary
There is some ambiguity in the RFC as to whether the ADD_ADDR HMAC is
the rightmost 64 bits of the entire hash or of the leftmost 160 bits
of the hash. The intention, as clarified with the author of the RFC,
is the entire hash.
This change returns the entire hash from
mptcp_crypto_hmac_sha (instead of only the first 160 bits), and moves
any truncation/selection operation on the hash to the caller.
Fixes: 12555a2d97e5 ("mptcp: use rightmost 64 bits in ADD_ADDR HMAC")
Signed-off-by: Todd Malsbary <todd.malsbary(a)linux.intel.com>
---
Note that checkpatch complains about the long lines in the crypto
test, but breaking the string causes it to then complain about
splitting on a non-whitespace char.
net/mptcp/crypto.c | 24 +++++++++---------------
net/mptcp/options.c | 9 +++++----
net/mptcp/protocol.h | 1 -
net/mptcp/subflow.c | 14 +++++++++-----
4 files changed, 23 insertions(+), 25 deletions(-)
diff --git a/net/mptcp/crypto.c b/net/mptcp/crypto.c
index c151628bd416..0f5a414a9366 100644
--- a/net/mptcp/crypto.c
+++ b/net/mptcp/crypto.c
@@ -47,8 +47,6 @@ void mptcp_crypto_key_sha(u64 key, u32 *token, u64 *idsn)
void mptcp_crypto_hmac_sha(u64 key1, u64 key2, u8 *msg, int len, void *hmac)
{
u8 input[SHA256_BLOCK_SIZE + SHA256_DIGEST_SIZE];
- __be32 mptcp_hashed_key[SHA256_DIGEST_WORDS];
- __be32 *hash_out = (__force __be32 *)hmac;
struct sha256_state state;
u8 key1be[8];
u8 key2be[8];
@@ -86,11 +84,7 @@ void mptcp_crypto_hmac_sha(u64 key1, u64 key2, u8 *msg, int len, void *hmac)
sha256_init(&state);
sha256_update(&state, input, SHA256_BLOCK_SIZE + SHA256_DIGEST_SIZE);
- sha256_final(&state, (u8 *)mptcp_hashed_key);
-
- /* takes only first 160 bits */
- for (i = 0; i < 5; i++)
- hash_out[i] = mptcp_hashed_key[i];
+ sha256_final(&state, (u8 *)hmac);
}
#ifdef CONFIG_MPTCP_HMAC_TEST
@@ -101,29 +95,29 @@ struct test_cast {
};
/* we can't reuse RFC 4231 test vectors, as we have constraint on the
- * input and key size, and we truncate the output.
+ * input and key size.
*/
static struct test_cast tests[] = {
{
.key = "0b0b0b0b0b0b0b0b",
.msg = "48692054",
- .result = "8385e24fb4235ac37556b6b886db106284a1da67",
+ .result = "8385e24fb4235ac37556b6b886db106284a1da671699f46db1f235ec622dcafa",
},
{
.key = "aaaaaaaaaaaaaaaa",
.msg = "dddddddd",
- .result = "2c5e219164ff1dca1c4a92318d847bb6b9d44492",
+ .result = "2c5e219164ff1dca1c4a92318d847bb6b9d44492984e1eb71aff9022f71046e9",
},
{
.key = "0102030405060708",
.msg = "cdcdcdcd",
- .result = "e73b9ba9969969cefb04aa0d6df18ec2fcc075b6",
+ .result = "e73b9ba9969969cefb04aa0d6df18ec2fcc075b6f23b4d8c4da736a5dbbc6e7d",
},
};
static int __init test_mptcp_crypto(void)
{
- char hmac[20], hmac_hex[41];
+ char hmac[32], hmac_hex[65];
u32 nonce1, nonce2;
u64 key1, key2;
u8 msg[8];
@@ -140,11 +134,11 @@ static int __init test_mptcp_crypto(void)
put_unaligned_be32(nonce2, &msg[4]);
mptcp_crypto_hmac_sha(key1, key2, msg, 8, hmac);
- for (j = 0; j < 20; ++j)
+ for (j = 0; j < 32; ++j)
sprintf(&hmac_hex[j << 1], "%02x", hmac[j] & 0xff);
- hmac_hex[40] = 0;
+ hmac_hex[64] = 0;
- if (memcmp(hmac_hex, tests[i].result, 40))
+ if (memcmp(hmac_hex, tests[i].result, 64))
pr_err("test %d failed, got %s expected %s", i,
hmac_hex, tests[i].result);
else
diff --git a/net/mptcp/options.c b/net/mptcp/options.c
index b88fae233a62..7793b6011fa7 100644
--- a/net/mptcp/options.c
+++ b/net/mptcp/options.c
@@ -7,6 +7,7 @@
#define pr_fmt(fmt) "MPTCP: " fmt
#include <linux/kernel.h>
+#include <crypto/sha.h>
#include <net/tcp.h>
#include <net/mptcp.h>
#include "protocol.h"
@@ -535,7 +536,7 @@ static bool mptcp_established_options_dss(struct sock *sk, struct sk_buff *skb,
static u64 add_addr_generate_hmac(u64 key1, u64 key2, u8 addr_id,
struct in_addr *addr)
{
- u8 hmac[MPTCP_ADDR_HMAC_LEN];
+ u8 hmac[SHA256_DIGEST_SIZE];
u8 msg[7];
msg[0] = addr_id;
@@ -545,14 +546,14 @@ static u64 add_addr_generate_hmac(u64 key1, u64 key2, u8 addr_id,
mptcp_crypto_hmac_sha(key1, key2, msg, 7, hmac);
- return get_unaligned_be64(&hmac[MPTCP_ADDR_HMAC_LEN - sizeof(u64)]);
+ return get_unaligned_be64(&hmac[SHA256_DIGEST_SIZE - sizeof(u64)]);
}
#if IS_ENABLED(CONFIG_MPTCP_IPV6)
static u64 add_addr6_generate_hmac(u64 key1, u64 key2, u8 addr_id,
struct in6_addr *addr)
{
- u8 hmac[MPTCP_ADDR_HMAC_LEN];
+ u8 hmac[SHA256_DIGEST_SIZE];
u8 msg[19];
msg[0] = addr_id;
@@ -562,7 +563,7 @@ static u64 add_addr6_generate_hmac(u64 key1, u64 key2, u8 addr_id,
mptcp_crypto_hmac_sha(key1, key2, msg, 19, hmac);
- return get_unaligned_be64(&hmac[MPTCP_ADDR_HMAC_LEN - sizeof(u64)]);
+ return get_unaligned_be64(&hmac[SHA256_DIGEST_SIZE - sizeof(u64)]);
}
#endif
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index e4ca6320ce76..d0803dfb8108 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -81,7 +81,6 @@
/* MPTCP ADD_ADDR flags */
#define MPTCP_ADDR_ECHO BIT(0)
-#define MPTCP_ADDR_HMAC_LEN 20
#define MPTCP_ADDR_IPVERSION_4 4
#define MPTCP_ADDR_IPVERSION_6 6
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index 4931a29a6f08..234f6c7572a4 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -10,6 +10,7 @@
#include <linux/module.h>
#include <linux/netdevice.h>
#include <crypto/algapi.h>
+#include <crypto/sha.h>
#include <net/sock.h>
#include <net/inet_common.h>
#include <net/inet_hashtables.h>
@@ -89,7 +90,7 @@ static bool subflow_token_join_request(struct request_sock *req,
const struct sk_buff *skb)
{
struct mptcp_subflow_request_sock *subflow_req = mptcp_subflow_rsk(req);
- u8 hmac[MPTCPOPT_HMAC_LEN];
+ u8 hmac[SHA256_DIGEST_SIZE];
struct mptcp_sock *msk;
int local_id;
@@ -201,7 +202,7 @@ static void subflow_v6_init_req(struct request_sock *req,
/* validate received truncated hmac and create hmac for third ACK */
static bool subflow_thmac_valid(struct mptcp_subflow_context *subflow)
{
- u8 hmac[MPTCPOPT_HMAC_LEN];
+ u8 hmac[SHA256_DIGEST_SIZE];
u64 thmac;
subflow_generate_hmac(subflow->remote_key, subflow->local_key,
@@ -223,6 +224,7 @@ static void subflow_finish_connect(struct sock *sk, const struct sk_buff *skb)
struct mptcp_options_received mp_opt;
struct sock *parent = subflow->conn;
struct tcp_sock *tp = tcp_sk(sk);
+ u8 hmac[SHA256_DIGEST_SIZE];
subflow->icsk_af_ops->sk_rx_dst_set(sk, skb);
@@ -279,7 +281,9 @@ static void subflow_finish_connect(struct sock *sk, const struct sk_buff *skb)
subflow_generate_hmac(subflow->local_key, subflow->remote_key,
subflow->local_nonce,
subflow->remote_nonce,
- subflow->hmac);
+ hmac);
+
+ memcpy(subflow->hmac, hmac, MPTCPOPT_HMAC_LEN);
if (skb)
subflow->ssn_offset = TCP_SKB_CB(skb)->seq;
@@ -347,7 +351,7 @@ static bool subflow_hmac_valid(const struct request_sock *req,
const struct mptcp_options_received *mp_opt)
{
const struct mptcp_subflow_request_sock *subflow_req;
- u8 hmac[MPTCPOPT_HMAC_LEN];
+ u8 hmac[SHA256_DIGEST_SIZE];
struct mptcp_sock *msk;
bool ret;
@@ -361,7 +365,7 @@ static bool subflow_hmac_valid(const struct request_sock *req,
subflow_req->local_nonce, hmac);
ret = true;
- if (crypto_memneq(hmac, mp_opt->hmac, sizeof(hmac)))
+ if (crypto_memneq(hmac, mp_opt->hmac, MPTCPOPT_HMAC_LEN))
ret = false;
sock_put((struct sock *)msk);
--
2.25.4
10 months, 3 weeks
[Weekly meetings] MoM - 21th of May 2020
by Matthieu Baerts
Hello,
We just had our 100th (\o/) meeting with Mat, Ossama and Todd (Intel
OTC), Christoph (Apple), Davide (RedHat) and myself (Tessares).
Thanks again for this new good meeting!
Here are the minutes of the meeting:
Accepted patches:
- The list of accepted patches can be seen on PatchWork:
https://patchwork.ozlabs.org/project/mptcp/list/?state=3
netdev (if mptcp ML is in cc) (by: Christoph Paasch, Florian
Westphal, Matthieu Baerts, Paolo Abeni, Todd Malsbary):
1293559 [net] mptcp: use rightmost 64 bits in ADD_ADDR HMAC
1291530 [net-next,v2,3/3] mptcp: cope better with MP_JOIN failure
1291527 [net-next,v2,2/3] inet_connection_sock: factor out destroy help
1291526 [net-next,v2,1/3] mptcp: add new sock flag to deal with join su
1291444 [net] selftests:mptcp:pm: rm the right tmp file
1290468 [net-next] mptcp: Use 32-bit DATA_ACK when possible
1287651 [net-next,7/7] net: allow __skb_ext_alloc to sleep
1287650 [net-next,6/7] mptcp: remove inner wait loop from mptcp_sendmsg
1287649 [net-next,5/7] mptcp: fill skb page frag cache outside of mptcp
1287648 [net-next,4/7] mptcp: fill skb extension cache outside of mptcp
1287647 [net-next,3/7] mptcp: make sure timer is inited once data is pe
1287646 [net-next,2/7] mptcp: avoid blocking in tcp_sendpages
1287644 [net-next,1/7] mptcp: break and restart in case mptcp sndbuf i:
- note: these IDs are from the previous version
our repo (by: /):
(most of the above ones went in our repo, shortly before being sent
upstream)
Pending patches:
- The list of pending patches can be seen on PatchWork:
https://patchwork.ozlabs.org/project/mptcp/list/?state=*
netdev (if mptcp ML is in cc) (by: /):
/
our repo (by: Davide Caratti, Paolo Abeni):
1292675: New: [RFC,net-next,1/2] net: mptcp: improve fallback to TCP:
- a new version is coming addressing the different comments raised
by Mat and Paolo
1292673: New: [RFC,net-next,2/2] mptcp: fix races between shutdown and r
1293349: New: [RFC] mptcp: refactor token container.:
- it needs review
Issues on Github:
https://github.com/multipath-tcp/mptcp_net-next/issues/
open: (latest from last week: 24)
26 NEW: Unstable packetdrill tests:
- https://github.com/multipath-tcp/mptcp_net-next/issues/26
- not easy to reproduce: DSS is different
25 NEW: mptcp_connect: Connection reset by peer during a test:
- "mptcp: fix races between shutdown and recvmsg" might help
- not able to reproduce so far
24 Revisit layout of struct mptcp_subflow_context
23 refactor token container:
- WIP by Paolo
22 fix covscan issues @dcaratti (indirectly fixed by issue 11)
21 sort-out {set,get}sockopt handling
20 implement msk diag interface
19 let PM netlink update live sockets on local addresses list change
18 allow 'force to MPTCP' mode
17 audit 'backup' flag usage
16 get rid of mptcp hooking in tcp_check_req()
15 reduce mptcp_out_option struct size
11 fix fallback to TCP @dcaratti:
- Davide is working on fixing it
6 loss and delay without reordering causes very slow transfer
4 keep a single work struct in mptcp socket
recently closed:
/
FYI: Current Roadmap: (same as last week)
- Part 4 (next merge window):
- Fix bugs reported on Github:
https://github.com/multipath-tcp/mptcp_net-next/issues/
- IPv6 - IPv4 mapped support
- not dropping MPTCP options (ADD_ADDR, etc.)
- FAST_CLOSE
- full MPTCP v1 support (reliable add_addr, etc.)
- after a few attempts of failed MPTCP, we fallback to TCP
(like TFO is doing)
- PM server (more advanced)
- Active backup support
- sending "simultaneously" on different subflows (multiple non
backup subflows)
- Full DATA_FIN support [WIP by Mat]
- ADD_ADDR for MPTCPv1: echo bit [WIP by Peter]
- Opti in TCP option structures (unions) [DONE by Paolo]
- Shared recv window (full support) [DONE by Florian]
- Part 5 (extra needed for prod):
- opti/perfs
- TFO
- PM netlink
- PM bpf
- Scheduler bpf
- syncookies
- [gs]etsockopt per subflow
- notify the userspace when a subflow is added/removed → cmsg
in progress fixes for -net:
- /
Part 4: new features:
- news about "Full DATA_FIN support"?:
- some progress in the shutdown
- when Christoph was doing some interop tests, when killing
iperf, it randomly hangs:
- maybe linked to DATA_FIN?
- anybody else saw that?
- news about "ADD_ADDR for MPTCPv1: echo bit"?:
- /
Extra tests:
- news about Syzkaller? (Christoph):
- /
- news about Intel's kbuild? (Mat):
- Notifications are now only sent to Mat who forwards only the
unstable ones.
- Notification from the 19/05: kselftest UNSTABLE:
- due to changes in MPTCP? maybe not: all bpf tests
- next one OK? (didn't get any new results yet)
- packetdrill (Davide & Todd):
- Todd is progressing on ADD_ADDRv1
- Todd will continue looking at MP_JOIN
- Davide is focusing on TCP fallback
- CI (Matth):
- some unstable tests, see above
- Coverity (Davide):
- 2 issues:
- https://github.com/multipath-tcp/mptcp_net-next/issues/22
- the other one seems to be a false positive when using
kmalloc_cache.
ADD_ADDR HMAC ambiguity:
- feedback from IETF: we need to change it again.
- Todd is preparing a new patch (not a revert, something different)
interop with mptcp.org:
- perf are pretty low but expected due to the way OOO packets are
handled
- for now, testing upstream version for the server → so only upload
is bad when using two subflows and sending data at the same time
- it's limiting the number of tests that can be ran
Next meeting:
- We propose to have the next meeting on Thursday, the 28th of May.
- Usual time: 16:00 UTC (9am PDT, 6pm CEST)
- Still open to everyone!
- https://annuel2.framapad.org/p/mptcp_upstreaming_20200528
Feel free to comment on these points and propose new ones for the next
meeting!
Talk to you next week,
Matt
--
Matthieu Baerts | R&D Engineer
matthieu.baerts(a)tessares.net
Tessares SA | Hybrid Access Solutions
www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium
10 months, 3 weeks
Greetings dearest in the lord,
by Mrs. Flora Diomande
Greetings dearest in the lord,
I greet you with the name of our Lord Jesus Christ; it is true that this letter may come to you as a surprise. Nevertheless, I humbly ask you to give me your attention and hear me well. My name is Mrs. Flora Diomande from United States of America. I am 58 years old and I am married to Mr. Bakayoko Diomande who once worked with our Embassy in Germany in the year 2002 and he also worked in an embassy in Cote d'Ivoire for a period of 16 years before he died.
We were married for 30 years without a child before he died after a brief illness. Since his death I decided not to remarry due to my religious belief. When my late husband was alive he deposited the sum of USD$4.5 Million (Four Million, Five Hundred Thousand United State dollars) with a Bank in Cote d'Ivoire. Presently this money is still in the custody of the Bank. Recently, my Doctor told me that I would not last for the next Four months due to my cancer illness.
Having known my condition I decided to donate this money to churches, organization or good person that will utilize this money the way I am going to instruct herein.
I want you to use this money for churches, Charity organization, orphanages, widows and other people that are in need. l took this decision because I don't have any child that will inherit this money. Moreover, my husband relatives are not close to me since I develop a Cancer problem and it had been their wish to see me dead in order to inherit his wealth since we have no Child. These people are not worthy of this inheritance. This is why I am taking this decision to contact you and donate this fund to you in order for you to use it for the charity works.
As soon as I receive your reply I will give you the contact of the Bank in Cote d'Ivoire where this money is deposited by my husband before his sudden death, also I will instruct our family lawyer in Cote d’Ivoire to issue a letter of authorization to the bank that will prove you the present beneficiary of this money. I also want you to always put me in your daily prayer.
Any delay in your reply may give me room to look for another good person for this same purpose. Please assure me that you will act accordingly as I stated herein.
Thanks and Remain blessed.
Yours sister in the Lord,
Mrs. Flora Diomande,
10 months, 3 weeks
Re: New Order for your ref
by Trang Nguyễn
FYI: Waybill and Invoice
Dear sir,
we wish to inform you that the waybill and invoice of your
consignment
has been sent to you, attached in this mail is a copy of the
documents
kindly acknowledge that you have received it then sign and stamp
the invoice and
send back to me as soon as possible.
Best regards
Indra. ramdani
10 months, 3 weeks
ADD_ADDR HMAC ambiguity
by Christoph Paasch
Hello,
Todd Malsbary from Intel is looking at the HMAC-support for ADD_ADDR in
RFC8684. And it appears that there can be an ambiguity on how to interpret
the truncation.
We want to clarify this and make sure all implementations,... are on the
same page with the intention of the RFC:
RFC8684, Section 3.4.1 says:
" The Truncated HMAC parameter present in this option is the rightmost
64 bits of an HMAC, negotiated and calculated in the same way as for
MP_JOIN as described in Section 3.2. "
Now, in Section 3.2 it mentions:
" This specification defines that HMAC as defined in [RFC2104] is used,
along with the SHA-256 hash algorithm [RFC6234], and that the output
is truncated to the leftmost 160 bits (20 octets). "
One can read these in two different ways:
In Section 3.4.1, the truncation to the rightmost 64 bits is based on the
full 256-bit HMAC-output or whether it is rather the 64 rightmost bits of
the leftmost 160bits (the ones mentioned in Section 3.2).
Can we clarify which of the two options is the correct one?
I personally interpret it as "right most 64 bits of the 256-bit HMAC-output".
Thanks,
Christoph
10 months, 3 weeks
