2021-10-18 03:29:58

by Gaosheng Cui

[permalink] [raw]
Subject: [PATCH -next,v3 0/2] Audit: fix warning and check priority early

v3:
drop the redundant commit message and add a Fixes tag to the first
patch
v2:
audit: fix possible null-pointer dereference in audit_filter_rules
audit: return early if the rule has a lower priority
v1:
audit: return early if the rule has a lower priority

Gaosheng Cui (2):
audit: fix possible null-pointer dereference in audit_filter_rules
audit: return early if the rule has a lower priority

kernel/auditsc.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)

--
2.30.0


2021-10-18 03:30:32

by Gaosheng Cui

[permalink] [raw]
Subject: [PATCH -next,v3 2/2] audit: return early if the rule has a lower priority

It is not necessary for audit_filter_rules() functions to check
audit fileds of the rule with a lower priority, and if we did,
there might be some unintended effects, such as the ctx->ppid
may be changed unexpectedly, so return early if the rule has
a lower priority.

Signed-off-by: Gaosheng Cui <[email protected]>
---
kernel/auditsc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 42d4a4320526..b517947bfa48 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -470,6 +470,9 @@ static int audit_filter_rules(struct task_struct *tsk,
u32 sid;
unsigned int sessionid;

+ if (ctx && rule->prio <= ctx->prio)
+ return 0;
+
cred = rcu_dereference_check(tsk->cred, tsk == current || task_creation);

for (i = 0; i < rule->field_count; i++) {
@@ -737,8 +740,6 @@ static int audit_filter_rules(struct task_struct *tsk,
}

if (ctx) {
- if (rule->prio <= ctx->prio)
- return 0;
if (rule->filterkey) {
kfree(ctx->filterkey);
ctx->filterkey = kstrdup(rule->filterkey, GFP_ATOMIC);
--
2.30.0

2021-10-18 03:31:05

by Gaosheng Cui

[permalink] [raw]
Subject: [PATCH -next,v3 1/2] audit: fix possible null-pointer dereference in audit_filter_rules

Fix possible null-pointer dereference in audit_filter_rules.

audit_filter_rules() error: we previously assumed 'ctx' could be null

Fixes: bf361231c295 ("audit: add saddr_fam filter field")
Reported-by: kernel test robot <[email protected]>
Reported-by: Dan Carpenter <[email protected]>
Signed-off-by: Gaosheng Cui <[email protected]>
---
kernel/auditsc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 4ba3b8573ff4..42d4a4320526 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -647,7 +647,7 @@ static int audit_filter_rules(struct task_struct *tsk,
result = audit_comparator(audit_loginuid_set(tsk), f->op, f->val);
break;
case AUDIT_SADDR_FAM:
- if (ctx->sockaddr)
+ if (ctx && ctx->sockaddr)
result = audit_comparator(ctx->sockaddr->ss_family,
f->op, f->val);
break;
--
2.30.0

2021-10-18 22:30:18

by Paul Moore

[permalink] [raw]
Subject: Re: [PATCH -next,v3 1/2] audit: fix possible null-pointer dereference in audit_filter_rules

On Sat, Oct 16, 2021 at 3:21 AM Gaosheng Cui <[email protected]> wrote:
>
> Fix possible null-pointer dereference in audit_filter_rules.
>
> audit_filter_rules() error: we previously assumed 'ctx' could be null
>
> Fixes: bf361231c295 ("audit: add saddr_fam filter field")
> Reported-by: kernel test robot <[email protected]>
> Reported-by: Dan Carpenter <[email protected]>
> Signed-off-by: Gaosheng Cui <[email protected]>
> ---
> kernel/auditsc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)

Thank you for the patch; I added a stable tag and merged it into
audit/stable-5.15, I'll send it up to Linus later this week once it
has gone through some additional testing.

--
paul moore
http://www.paul-moore.com

2021-10-18 22:40:27

by Paul Moore

[permalink] [raw]
Subject: Re: [PATCH -next,v3 2/2] audit: return early if the rule has a lower priority

On Sat, Oct 16, 2021 at 3:21 AM Gaosheng Cui <[email protected]> wrote:
>
> It is not necessary for audit_filter_rules() functions to check
> audit fileds of the rule with a lower priority, and if we did,
> there might be some unintended effects, such as the ctx->ppid
> may be changed unexpectedly, so return early if the rule has
> a lower priority.
>
> Signed-off-by: Gaosheng Cui <[email protected]>
> ---
> kernel/auditsc.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)

Merged to audit/next, thanks!

--
paul moore
http://www.paul-moore.com

2021-10-19 14:56:14

by Steve Grubb

[permalink] [raw]
Subject: Re: [PATCH -next, v3 2/2] audit: return early if the rule has a lower priority

Hello,

On Saturday, October 16, 2021 3:23:51 AM EDT Gaosheng Cui wrote:
> It is not necessary for audit_filter_rules() functions to check
> audit fileds of the rule with a lower priority, and if we did,
> there might be some unintended effects, such as the ctx->ppid
> may be changed unexpectedly, so return early if the rule has
> a lower priority.
>
> Signed-off-by: Gaosheng Cui <[email protected]>
> ---
> kernel/auditsc.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index 42d4a4320526..b517947bfa48 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -470,6 +470,9 @@ static int audit_filter_rules(struct task_struct *tsk,
> u32 sid;
> unsigned int sessionid;
>
> + if (ctx && rule->prio <= ctx->prio)
> + return 0;
> +

Just wondering something... If the first thing we do is to decide to return,
should we have called the function in the first place? I wonder if this test
should be used to break out of the rule iteration loops so that we don't keep
calling only to return ?

-Steve

> cred = rcu_dereference_check(tsk->cred, tsk == current ||
task_creation);
>
> for (i = 0; i < rule->field_count; i++) {
> @@ -737,8 +740,6 @@ static int audit_filter_rules(struct task_struct *tsk,
> }
>
> if (ctx) {
> - if (rule->prio <= ctx->prio)
> - return 0;
> if (rule->filterkey) {
> kfree(ctx->filterkey);
> ctx->filterkey = kstrdup(rule->filterkey, GFP_ATOMIC);




2021-10-19 14:56:57

by Paul Moore

[permalink] [raw]
Subject: Re: [PATCH -next, v3 2/2] audit: return early if the rule has a lower priority

On Tue, Oct 19, 2021 at 10:51 AM Steve Grubb <[email protected]> wrote:
> Just wondering something... If the first thing we do is to decide to return,
> should we have called the function in the first place? I wonder if this test
> should be used to break out of the rule iteration loops so that we don't keep
> calling only to return ?

Patches are welcome ... ;)

--
paul moore
http://www.paul-moore.com