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: <20190108143828.GA15136@asgard.redhat.com>
Date:   Tue, 8 Jan 2019 15:38:28 +0100
From:   Eugene Syromiatnikov <esyr@...hat.com>
To:     Richard Cochran <richardcochran@...il.com>
Cc:     David Miller <davem@...emloft.net>, mlichvar@...hat.com,
        netdev@...r.kernel.org, jacob.e.keller@...el.com,
        mtosatti@...hat.com
Subject: Re: [PATCH net 1/2] ptp: check that rsv field is zero in struct
 ptp_sys_offset_extended

On Mon, Jan 07, 2019 at 09:19:23PM -0800, Richard Cochran wrote:
> On Mon, Jan 07, 2019 at 08:29:38AM -0800, David Miller wrote:
> > From: Eugene Syromiatnikov <esyr@...hat.com>
> > Date: Mon, 7 Jan 2019 16:22:29 +0100
> > 
> > > Otherwise it is impossible to use it for something else, as it will break
> > > userspace that puts garbage there.
> > > 
> > > The same check should be done in other structures, but the fact that
> > > data in reserved fields is ignored is already part of the kernel ABI.
> > > 
> > > Signed-off-by: Eugene Syromiatnikov <esyr@...hat.com>
> > 
> > I think the opportunity to enforce this has passed and you will break
> > userspace by doing this.
> 
> Does this seriously mean that the 'rsv' field in
> 
> 	struct ptp_extts_request {
> 		unsigned int index;  /* Which channel to configure. */
> 		unsigned int flags;  /* Bit field for PTP_xxx flags. */
> 		unsigned int rsv[2]; /* Reserved for future use. */
> 	};
> 
> can never be extended with some semantics?

Yes[*], since there's no check for garbage in both unused flags bits and rsv
values. The same for ptp_perout_request, ptp_sys_offset, ptp_pin_desc in
PTP_PIN_SETFUNC, and to some extent for ptp_sys_offset_precise, ptp_clock_caps,
and ptp_pin_desc in PTP_PIN_GETFUNC (all newly added data has to be
non-zero there). See also [1][2].

It can be worked around by adding new ioctl commands that operate on the
same structures, but also perform proper checks, though.

[*] Well, it could be extended with some data that is written from kernel
    to user space, but, again, it is not possible due to the fact that no
    new flags can be added there and it is an _IOW and not _IOWR command.
[1] https://www.kernel.org/doc/Documentation/process/adding-syscalls.rsti
    "Designing the API: Planning for Extension"
[2] http://man7.org/conf/lcna2015/designing_linux_kernel_APIs-LCNA_2015-Kerrisk.pdf

> Thanks,
> Richard

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ