commit df58fae72428b "smb3: Incorrect size for netname negotiate
context" (patch was added in 5.4) turns out to be more important than
we realized (fixing a feature added in 5.3 by commit 96d3cca1241d6
which sends the "netname context" during protocol negotiations).
commit df58fae72428b should be cc:stable for 5.3
--
Thanks,
Steve
This patch set is aim to update the old IP_TOS_MASK to new IP_DSCP_MASK
as tos value has been obsoleted for a long time. But to make sure we don't
break any existing behaviour, we can't just replease all IP_TOS_MASK
to new IP_DSCP_MASK.
So let's update it case by case. The first issue we will fix is that vxlan
is unable to take the first 3 bits from DSCP field before xmit. Use the
new RT_DSCP() would resolve this.
v2: Remove IP_DSCP() definition as it's duplicated with RT_DSCP().
Post the patch to net instead of net-next as we need fix the vxlan issue
Hangbin Liu (2):
net: add IP_DSCP_MASK
vxlan: fix getting tos value from DSCP field
drivers/net/vxlan.c | 4 ++--
include/uapi/linux/in_route.h | 1 +
include/uapi/linux/ip.h | 1 +
3 files changed, 4 insertions(+), 2 deletions(-)
--
2.25.4
On Tue, Aug 4, 2020 at 5:52 PM Marc Plumb <lkml.mplumb(a)gmail.com> wrote:
>
> TL;DR This change takes the seed data from get_random_bytes and broadcasts it to the network, thereby destroying the security of dev/random. This change needs to be reverted and redesigned.
This was discussed.,
It's theoretical, not practical.
The patch improves real security, and the fake "but in theory" kind is
meaningless and people should stop that kind of behavior.
Linus
Willy and Ted,
This commit has serious security flaws
f227e3ec3b5cad859ad15666874405e8c1bbc1d4
TL;DR This change takes the seed data from get_random_bytes and
broadcasts it to the network, thereby destroying the security of
dev/random. This change needs to be reverted and redesigned.
It is inefficient:
This function is called from an interrupt context, so there is no chance
of a CPU switch, therefore the this_cpu_add function should be
__this_cpu_add. This is a sign that the patch may have been rushed and
may not be suitable for a stable release.
It is fixing the wrong problem:
The net_rand_state PRNG is a weak PRNG for the purpose of avoiding
collisions, not to be unguessable to an attacker. The network PRNG does
not need secure seeding. If you need a secure PRNG then you shouldn't be
using the net_rand_state PRNG. Please reconsider why you think that this
change is necessary.
It dramatically weakens dev/random:
Seeding two PRNGs with the same entropy causes two problems. The minor
one is that you're double counting entropy. The major one is that anyone
who can determine the state of one PRNG can determine the state of the
other.
The net_rand_state PRNG is effectively a 113 bit LFSR, so anyone who can
see any 113 bits of output can determine the complete internal state.
The output of the net_rand_state PRNG is used to determine how data is
sent to the network, so the output is effectively broadcast to anyone
watching network traffic. Therefore anyone watching the network traffic
can determine the seed data being fed to the net_rand_state PRNG. Since
this is the same seed data being fed to get_random_bytes, it allows an
attacker to determine the state and there output of /dev/random. I
sincerely hope that this was not the intended goal. :)
Thank you
Marc
From: Muchun Song <songmuchun(a)bytedance.com>
We found a case of kernel panic on our server. The stack trace is as
follows(omit some irrelevant information):
BUG: kernel NULL pointer dereference, address: 0000000000000080
RIP: 0010:kprobe_ftrace_handler+0x5e/0xe0
RSP: 0018:ffffb512c6550998 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff8e9d16eea018 RCX: 0000000000000000
RDX: ffffffffbe1179c0 RSI: ffffffffc0535564 RDI: ffffffffc0534ec0
RBP: ffffffffc0534ec1 R08: ffff8e9d1bbb0f00 R09: 0000000000000004
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff8e9d1f797060 R14: 000000000000bacc R15: ffff8e9ce13eca00
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000080 CR3: 00000008453d0005 CR4: 00000000003606e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<IRQ>
ftrace_ops_assist_func+0x56/0xe0
ftrace_call+0x5/0x34
tcpa_statistic_send+0x5/0x130 [ttcp_engine]
The tcpa_statistic_send is the function being kprobed. After analysis,
the root cause is that the fourth parameter regs of kprobe_ftrace_handler
is NULL. Why regs is NULL? We use the crash tool to analyze the kdump.
crash> dis tcpa_statistic_send -r
<tcpa_statistic_send>: callq 0xffffffffbd8018c0 <ftrace_caller>
The tcpa_statistic_send calls ftrace_caller instead of ftrace_regs_caller.
So it is reasonable that the fourth parameter regs of kprobe_ftrace_handler
is NULL. In theory, we should call the ftrace_regs_caller instead of the
ftrace_caller. After in-depth analysis, we found a reproducible path.
Writing a simple kernel module which starts a periodic timer. The
timer's handler is named 'kprobe_test_timer_handler'. The module
name is kprobe_test.ko.
1) insmod kprobe_test.ko
2) bpftrace -e 'kretprobe:kprobe_test_timer_handler {}'
3) echo 0 > /proc/sys/kernel/ftrace_enabled
4) rmmod kprobe_test
5) stop step 2) kprobe
6) insmod kprobe_test.ko
7) bpftrace -e 'kretprobe:kprobe_test_timer_handler {}'
We mark the kprobe as GONE but not disarm the kprobe in the step 4).
The step 5) also do not disarm the kprobe when unregister kprobe. So
we do not remove the ip from the filter. In this case, when the module
loads again in the step 6), we will replace the code to ftrace_caller
via the ftrace_module_enable(). When we register kprobe again, we will
not replace ftrace_caller to ftrace_regs_caller because the ftrace is
disabled in the step 3). So the step 7) will trigger kernel panic. Fix
this problem by disarming the kprobe when the module is going away.
Link: https://lkml.kernel.org/r/20200728064536.24405-1-songmuchun@bytedance.com
Cc: stable(a)vger.kernel.org
Fixes: ae6aa16fdc16 ("kprobes: introduce ftrace based optimization")
Acked-by: Masami Hiramatsu <mhiramat(a)kernel.org>
Signed-off-by: Muchun Song <songmuchun(a)bytedance.com>
Co-developed-by: Chengming Zhou <zhouchengming(a)bytedance.com>
Signed-off-by: Chengming Zhou <zhouchengming(a)bytedance.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
---
kernel/kprobes.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 4a904cc56d68..07bf03fcf574 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -2113,6 +2113,13 @@ static void kill_kprobe(struct kprobe *p)
* the original probed function (which will be freed soon) any more.
*/
arch_remove_kprobe(p);
+
+ /*
+ * The module is going away. We should disarm the kprobe which
+ * is using ftrace.
+ */
+ if (kprobe_ftrace(p))
+ disarm_kprobe_ftrace(p);
}
/* Disable one kprobe */
--
2.26.2
From: Nick Desaulniers <ndesaulniers(a)google.com>
__tracepoint_string's have their string data stored in .rodata, and an
address to that data stored in the "__tracepoint_str" section. Functions
that refer to those strings refer to the symbol of the address. Compiler
optimization can replace those address references with references
directly to the string data. If the address doesn't appear to have other
uses, then it appears dead to the compiler and is removed. This can
break the /tracing/printk_formats sysfs node which iterates the
addresses stored in the "__tracepoint_str" section.
Like other strings stored in custom sections in this header, mark these
__used to inform the compiler that there are other non-obvious users of
the address, so they should still be emitted.
Link: https://lkml.kernel.org/r/20200730224555.2142154-2-ndesaulniers@google.com
Cc: Ingo Molnar <mingo(a)redhat.com>
Cc: Miguel Ojeda <miguel.ojeda.sandonis(a)gmail.com>
Cc: stable(a)vger.kernel.org
Fixes: 102c9323c35a8 ("tracing: Add __tracepoint_string() to export string pointers")
Reported-by: Tim Murray <timmurray(a)google.com>
Reported-by: Simon MacMullen <simonmacm(a)google.com>
Suggested-by: Greg Hackmann <ghackmann(a)google.com>
Signed-off-by: Nick Desaulniers <ndesaulniers(a)google.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
---
include/linux/tracepoint.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
index a1fecf311621..3a5b717d92e8 100644
--- a/include/linux/tracepoint.h
+++ b/include/linux/tracepoint.h
@@ -361,7 +361,7 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
static const char *___tp_str __tracepoint_string = str; \
___tp_str; \
})
-#define __tracepoint_string __attribute__((section("__tracepoint_str")))
+#define __tracepoint_string __attribute__((section("__tracepoint_str"), used))
#else
/*
* tracepoint_string() is used to save the string address for userspace
--
2.26.2