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-next>] [day] [month] [year] [list]
Message-Id: <1414672952-1587-1-git-send-email-abbotti@mev.co.uk>
Date:	Thu, 30 Oct 2014 12:42:25 +0000
From:	Ian Abbott <abbotti@....co.uk>
To:	<driverdev-devel@...uxdriverproject.org>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Ian Abbott <abbotti@....co.uk>,
	H Hartley Sweeten <hartleys@...ionengravers.com>,
	<linux-kernel@...r.kernel.org>
Subject: [PATCH 0/7] staging: comedi: enforce data transfer direction

Most comedi subdevices that support asynchronous data acquisition
commands only support data transfer in a single direction, as indicated
by the `SDF_CMD_READ` and `SDF_CMD_WRITE` subdevice flags.  A few allow
data transfer in either direction, but only a single direction at a
time, as indicated by the `CMDF_WRITE` command flag in the `flags`
member of the `struct comedi_cmd` from user-space used to set up the
asynchronous command.  The `CMDF_WRITE` flag isn't commonly set for
"write" commands if that is the only direction the subdevice supports.

Since it would be useful for comedi to have a clear indication of which
data transfer direction is being used, patch 1 forces the `CMDF_WRITE`
command flag to the correct state if only one direction is supported.
The flag can then be checked by comedi in the subdevice's local copy of
the current command (in `s->async->cmd`) to determine the data transfer
direction unambiguously.

Patch 2 stops the "me4000" driver clobbering the command flags.

Patch 3 removes some now redundant modification of the `CMDF_WRITE` flag
in "ni_mio_common.c" (used by the "ni_pcimio", "ni_atmio" and
"ni_mio_cs" drivers).

Patches 4 and 5 disallow the read() and write() file operations if the
subdevice has been set up with a command in the "write" or "read" data
transfer direction respectively.

Patch 6 changes the readable/writeable checks for the poll() file
operation.  It already considers the file readable/writeable if
read()/write() would fail with an error, so change it to check for
"wrong direction" as one of the possible failures.

Patch 7 makes the direction test in the handling of the `COMEDI_BUFINFO`
ioctl (used to update buffer positions for mmapped buffers) less
ambiguous.  The current test used the `SDF_CMD_READ` and `SDF_CMD_WRITE`
subdevice flags to check the direction, which is ambiguous if both flags
are set.  Update it to use the `CMDF_WRITE` command flag instead.

1) staging: comedi: maybe force CMDF_WRITE command flag
2) staging: comedi: me4000: don't clobber command flags
3) staging: comedi: ni_mio_common: don't change CMDF_WRITE flag
4) staging: comedi: don't allow read() on async command set up for "write"
5) staging: comedi: don't allow write() on async command set up for "read"
6) staging: comedi: check command direction in poll() file operation
7) staging: comedi: check actual data direction for COMEDI_BUFINFO ioctl

 drivers/staging/comedi/comedi_fops.c           | 37 ++++++++++++++++++++++++--
 drivers/staging/comedi/drivers/me4000.c        |  3 ---
 drivers/staging/comedi/drivers/ni_mio_common.c |  6 -----
 3 files changed, 35 insertions(+), 11 deletions(-)
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ