Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 16 Jul 2020 14:09:13 +0200
From: Solar Designer <>
Subject: Re: error: redefinition of ???struct stack_trace??? - Centos 8 with default kernel.

On Thu, Jul 16, 2020 at 02:31:24AM +0200, Adam Zabrocki wrote:
> I've just pushed fix. Can you verify if that helps?

Adam refers to this commit in the Bitbucket repo:

commit 32fc7d27ae81cc5254e4c1f28c4e7b05c157bb63
Author: Adam_pi3 <>
Date:   Wed Jul 15 20:26:23 2020 -0400

    New RHEL kernels define 'struct stack_trace' by themselves. Take this into account

diff --git a/src/modules/exploit_detection/p_exploit_detection.h b/src/modules/exploit_detection/p_exploit_detection.h
index 10330af..1ef58f5 100644
--- a/src/modules/exploit_detection/p_exploit_detection.h
+++ b/src/modules/exploit_detection/p_exploit_detection.h
@@ -148,7 +148,8 @@ struct p_selinux_state {
+#if !defined(CONFIG_STACKTRACE) || \
+    (defined(CONFIG_STACKTRACE) && defined(CONFIG_ARCH_STACKWALK) && !defined(RHEL_RELEASE))
 struct stack_trace {
     unsigned int nr_entries, max_entries;
     unsigned long *entries;

Adam, I am concerned that this might break build on older RHEL.  I've
just tried on my outdated CentOS 7, and the build succeeded anyway, but
perhaps this does break build on older RHEL 8 (and CentOS 8, etc.) prior
to some change that broke the build for bryn1u?

We should possibly avoid the clash differently, e.g. by using a
different struct name when we choose to declare our own.  Maybe instead
of your patch above, we can add this line:

#define stack_trace p_struct_stack_trace

right before the "struct stack_trace {" line.

Would this work?  What do you think?


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.