linux-kernel - Re: [PATCH] kernel/itimer.c: for return value, using -EINVAL instead of -EFAULT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.02.1306200847300.4013@ionos.tec.linutronix.de>
Date:	Thu, 20 Jun 2013 08:59:33 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Chen Gang <gang.chen@...anux.com>
cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] kernel/itimer.c: for return value, using -EINVAL instead
 of -EFAULT

On Thu, 20 Jun 2013, Chen Gang wrote:

> For the system call getitimer(), if the parameter 'value' is NULL, need
> return -EINVAL, not -EFAULT.

Care to explain why? Because you are feeling so?

I recommend reading the man page of getitimer:

 ERRORS
       EFAULT new_value, old_value, or curr_value is not valid a pointer.

And NULL is definitely NOT a valid pointer.

The Posix spec does not specify an explicit error value for this
syscall, but the general policy is:

[EFAULT]
    Bad address. The system detected an invalid address in attempting
    to use an argument of a call. The reliable detection of this error
    cannot be guaranteed, and when not detected may result in the
    generation of a signal, indicating an address violation, which is
    sent to the process.

And we made use of this, which is correct and makes sense.

Returning EINVAL makes no sense at all, because EINVAL _IS_ a
specified error code for this syscall:

[EINVAL]
        The which argument is not recognized.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/