<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/s390/char, branch linux-3.12.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.12.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.12.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2017-01-26T16:39:06Z</updated>
<entry>
<title>s390/vmlogrdr: fix IUCV buffer allocation</title>
<updated>2017-01-26T16:39:06Z</updated>
<author>
<name>Gerald Schaefer</name>
</author>
<published>2016-11-21T11:13:58Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=22f604f0eac8189f92489a061796e94004e7aa1f'/>
<id>urn:sha1:22f604f0eac8189f92489a061796e94004e7aa1f</id>
<content type='text'>
commit 5457e03de918f7a3e294eb9d26a608ab8a579976 upstream.

The buffer for iucv_message_receive() needs to be below 2 GB. In
__iucv_message_receive(), the buffer address is casted to an u32, which
would result in either memory corruption or an addressing exception when
using addresses &gt;= 2 GB.

Fix this by using GFP_DMA for the buffer allocation.

Signed-off-by: Gerald Schaefer &lt;gerald.schaefer@de.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
</entry>
<entry>
<title>s390/sclp_ctl: fix potential information leak with /dev/sclp</title>
<updated>2016-09-29T09:14:05Z</updated>
<author>
<name>Martin Schwidefsky</name>
</author>
<published>2016-04-25T15:54:28Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6ec8ba03f408beac5bad1e9ec06c8a90b373f3ac'/>
<id>urn:sha1:6ec8ba03f408beac5bad1e9ec06c8a90b373f3ac</id>
<content type='text'>
commit 532c34b5fbf1687df63b3fcd5b2846312ac943c6 upstream.

The sclp_ctl_ioctl_sccb function uses two copy_from_user calls to
retrieve the sclp request from user space. The first copy_from_user
fetches the length of the request which is stored in the first two
bytes of the request. The second copy_from_user gets the complete
sclp request, but this copies the length field a second time.
A malicious user may have changed the length in the meantime.

Reported-by: Pengfei Wang &lt;wpengfeinudt@gmail.com&gt;
Reviewed-by: Michael Holzheu &lt;holzheu@linux.vnet.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Signed-off-by: Juerg Haefliger &lt;juerg.haefliger@hpe.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
</entry>
<entry>
<title>s390/3270: redraw screen on unsolicited device end</title>
<updated>2015-10-07T07:24:58Z</updated>
<author>
<name>Martin Schwidefsky</name>
</author>
<published>2015-08-19T14:50:10Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8638bf1f07b3f4f3095b721cd4b863d13fec082e'/>
<id>urn:sha1:8638bf1f07b3f4f3095b721cd4b863d13fec082e</id>
<content type='text'>
commit 05bfd70bcdd3cd12c061cb77b73a11ba6f87379d upstream.

If a 3270 terminal is disconnected and later reconnected again,
it gets an unsolicited device end. This is currently ignored and
you have to hit the clear key to get the screen redrawn.
Add an automatic full redraw of the screen for this case.

Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>s390/3215: fix tty output containing tabs</title>
<updated>2015-01-06T14:01:22Z</updated>
<author>
<name>Martin Schwidefsky</name>
</author>
<published>2014-08-13T10:01:30Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a611d4e3b0f5aace35a0c2577548f0e46d46910e'/>
<id>urn:sha1:a611d4e3b0f5aace35a0c2577548f0e46d46910e</id>
<content type='text'>
commit e512d56c799517f33b301d81e9a5e0ebf30c2d1e upstream.

git commit 37f81fa1f63ad38e16125526bb2769ae0ea8d332
"n_tty: do O_ONLCR translation as a single write"
surfaced a bug in the 3215 device driver. In combination this
broke tab expansion for tty ouput.

The cause is an asymmetry in the behaviour of tty3215_ops-&gt;write
vs tty3215_ops-&gt;put_char. The put_char function scans for '\t'
but the write function does not.

As the driver has logic for the '\t' expansion remove XTABS
from c_oflag of the initial termios as well.

Reported-by: Stephen Powell &lt;zlinuxman@wowway.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>s390/3215: fix hanging console issue</title>
<updated>2015-01-06T14:01:15Z</updated>
<author>
<name>Martin Schwidefsky</name>
</author>
<published>2014-07-15T15:53:12Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=22c60914c060fc8c62f52526411b73ea29eef46f'/>
<id>urn:sha1:22c60914c060fc8c62f52526411b73ea29eef46f</id>
<content type='text'>
commit 26d766c60f4ea08cd14f0f3435a6db3d6cc2ae96 upstream.

The ccw_device_start in raw3215_start_io can fail. raw3215_try_io
does not check if the request could be started and removes any
pending timer. This can leave the system in a hanging state.
Check for pending request after raw3215_start_io and start a
timer if necessary.

Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>s390/cio: fix driver callback initialization for ccw consoles</title>
<updated>2014-05-15T07:54:50Z</updated>
<author>
<name>Sebastian Ott</name>
</author>
<published>2014-01-27T12:26:10Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=afff7621bd106a71610f6c390b26c5ae21e2e2c6'/>
<id>urn:sha1:afff7621bd106a71610f6c390b26c5ae21e2e2c6</id>
<content type='text'>
commit 2253e8d79237c69086ded391e6767afe16972527 upstream.

ccw consoles are in use before they can be properly registered with
the driver core. For devices which are in use by a device driver we
rely on the ccw_device's pointer to the driver callbacks to be valid.
For ccw consoles this pointer is NULL until they are registered later
during boot and we dereferenced this pointer. This worked by
chance on 64 bit builds (cdev-&gt;drv was NULL but the optional callback
cdev-&gt;drv-&gt;path_event was also NULL by coincidence) and was unnoticed
until we received reports about boot failures on 31 bit systems.
Fix it by initializing the driver pointer for ccw consoles.

Reported-by: Mike Frysinger &lt;vapier@gentoo.org&gt;
Reported-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Reviewed-by: Peter Oberparleiter &lt;oberpar@linux.vnet.ibm.com&gt;
Signed-off-by: Sebastian Ott &lt;sebott@linux.vnet.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>s390/3270: fix missing device_destroy() call</title>
<updated>2014-03-12T08:39:40Z</updated>
<author>
<name>Hendrik Brueckner</name>
</author>
<published>2013-11-12T14:03:37Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c1b73028e93c7a9217ad75ed75a7fe167606054d'/>
<id>urn:sha1:c1b73028e93c7a9217ad75ed75a7fe167606054d</id>
<content type='text'>
commit d1e61fe49fd450be15d402ac353784f5ba8a624e upstream.

Unloading the fs3270 kernel module does not remove the created
"3270/tub" device.  Reloading the module then causes a sysfs warning:
"sysfs: cannot create duplicate filename '/devices/virtual/3270/3270!tub'".

Call device_destroy() in the module exit function to solve this issue.

Signed-off-by: Hendrik Brueckner &lt;brueckner@linux.vnet.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>s390/3270: fix allocation of tty3270_screen structure</title>
<updated>2014-01-09T20:25:15Z</updated>
<author>
<name>Martin Schwidefsky</name>
</author>
<published>2013-12-18T13:36:18Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6f3241a8ac9644c17ce7dc053d425f4bae7b0fb7'/>
<id>urn:sha1:6f3241a8ac9644c17ce7dc053d425f4bae7b0fb7</id>
<content type='text'>
commit 36d9f4d3b68c7035ead3850dc85f310a579ed0eb upstream.

The tty3270_alloc_screen function is called from tty3270_install with
swapped arguments, the number of columns instead of rows and vice versa.
The number of rows is typically smaller than the number of columns which
makes the screen array too big but the individual cell arrays for the
lines too small. Creating lines longer than the number of rows will
clobber the memory after the end of the cell array.
The fix is simple, call tty3270_alloc_screen with the correct argument
order.

Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>s390/time: correct use of store clock fast</title>
<updated>2013-10-22T07:16:40Z</updated>
<author>
<name>Martin Schwidefsky</name>
</author>
<published>2013-10-17T10:38:17Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8c071b0f19dfa230335d22ce56a8fab5bd20cedc'/>
<id>urn:sha1:8c071b0f19dfa230335d22ce56a8fab5bd20cedc</id>
<content type='text'>
The result of the store-clock-fast (STCKF) instruction is a bit fuzzy.
It can happen that the value stored on one CPU is smaller than the value
stored on another CPU, although the order of the stores is the other
way around. This can cause deltas of get_tod_clock() values to become
negative when they should not be.

We need to be more careful with store-clock-fast, this patch partially
reverts git commit e4b7b4238e666682555461fa52eecd74652f36bb "time:
always use stckf instead of stck if available". The get_tod_clock()
function now uses the store-clock-extended (STCKE) instruction.
get_tod_clock_fast() can be used if the fuzziness of store-clock-fast
is acceptable e.g. for wait loops local to a CPU.

Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/vmlogrdr: fix array access in vmlogrdr_open()</title>
<updated>2013-10-15T11:47:59Z</updated>
<author>
<name>Heiko Carstens</name>
</author>
<published>2013-10-14T12:26:08Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9784bd4f1a6ea736ad9bf241f5a965e0a2913a5e'/>
<id>urn:sha1:9784bd4f1a6ea736ad9bf241f5a965e0a2913a5e</id>
<content type='text'>
Fix check within vmlogrdr_open() if the minor address is not larger
than the number of array elements.

Found with "smatch":

drivers/s390/char/vmlogrdr.c:318 vmlogrdr_open() warn:
  buffer overflow 'sys_ser' 3 &lt;= 3

Acked-by: Stefan Weinhuber &lt;wein@de.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
</entry>
</feed>
