Linux Test Project
 help / color / mirror / Atom feed
From: Richard Palethorpe <rpalethorpe@suse.de>
To: Dylan Jhong <dylan@andestech.com>
Cc: "Randolph Sheng-Kai Lin\(\(\(\(\(\(\(\(\(\(\)"
	<randolph@andestech.com>,
	"ltp@lists.linux.it" <ltp@lists.linux.it>,
	"x5710999x@gmail.com" <x5710999x@gmail.com>,
	"Alan Quey-Liang Kao\(\(\(\(\(\(\(\(\(\(\)"
	<alankao@andestech.com>
Subject: Re: [LTP] [PATCH] syscalls/semctl03: Solve kernel panic in semctl03
Date: Fri, 26 Aug 2022 08:53:22 +0100	[thread overview]
Message-ID: <877d2v1kot.fsf@suse.de> (raw)
In-Reply-To: <Ywh5G6RQi+zitagg@atcsi01>

Hello,

Dylan Jhong <dylan@andestech.com> writes:

> Hi Richard,
>
> Thanks for your reply.
> My opinion is the same as yours, libc should do more checking and
> protection for incoming parameters

This is not my opinion.

Are you saying that libc segfaults? This is an acceptable outcome for
the LTP. To stop the test failing we can fork the test and check if the
child segfaults. However it seems the EFAULT test is already skipped if
we use libc, which is also acceptable.

However the patch title says that this resulted in a kernel panic due to
a null pointer dereference? This is a serious kernel bug that may be
exploitable.

>
> In semctl03.c, the two tv->semctl() implementation functions, which are libc_semctl() and sys_semctl(),
> do not pass the 4th argument ".buf" to the next level system call.
> At present, the 4th argument of semctl() implemented in semctl03.c is hard-coded,
> I think passing parameters instead of hardcoding should be more better for this testcase.
> Should we pass all parameters to the next level semctl() system call?

A 4th arg is never passed, if you remove the vararg the test compiles
and runs fine. So the vararg should be removed, but this is relatively
minor compared to a kernel null pointer dereference.

-- 
Thank you,
Richard.

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2022-08-26  8:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-25 10:52 [LTP] [PATCH] syscalls/semctl03: Solve kernel panic in semctl03 Dylan Jhong
2022-08-26  6:12 ` Richard Palethorpe
2022-08-26  7:41   ` Dylan Jhong
2022-08-26  7:53     ` Richard Palethorpe [this message]
2022-08-29 11:22       ` Dylan Jhong
2022-08-29 14:22         ` Richard Palethorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877d2v1kot.fsf@suse.de \
    --to=rpalethorpe@suse.de \
    --cc=alankao@andestech.com \
    --cc=dylan@andestech.com \
    --cc=ltp@lists.linux.it \
    --cc=randolph@andestech.com \
    --cc=x5710999x@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox