<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers, branch v3.4.73</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/drivers?h=v3.4.73</id>
<link rel='self' href='https://git.amat.us/linux/atom/drivers?h=v3.4.73'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2013-12-08T15:29:43Z</updated>
<entry>
<title>dm: fix truncated status strings</title>
<updated>2013-12-08T15:29:43Z</updated>
<author>
<name>Mikulas Patocka</name>
<email>mpatocka@redhat.com</email>
</author>
<published>2013-03-01T22:45:44Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=d8b8a43e0f3c99bb29f258ef508969793f8e43bd'/>
<id>urn:sha1:d8b8a43e0f3c99bb29f258ef508969793f8e43bd</id>
<content type='text'>
commit fd7c092e711ebab55b2688d3859d95dfd0301f73 upstream.

Avoid returning a truncated table or status string instead of setting
the DM_BUFFER_FULL_FLAG when the last target of a table fills the
buffer.

When processing a table or status request, the function retrieve_status
calls ti-&gt;type-&gt;status. If ti-&gt;type-&gt;status returns non-zero,
retrieve_status assumes that the buffer overflowed and sets
DM_BUFFER_FULL_FLAG.

However, targets don't return non-zero values from their status method
on overflow. Most targets returns always zero.

If a buffer overflow happens in a target that is not the last in the
table, it gets noticed during the next iteration of the loop in
retrieve_status; but if a buffer overflow happens in the last target, it
goes unnoticed and erroneously truncated data is returned.

In the current code, the targets behave in the following way:
* dm-crypt returns -ENOMEM if there is not enough space to store the
  key, but it returns 0 on all other overflows.
* dm-thin returns errors from the status method if a disk error happened.
  This is incorrect because retrieve_status doesn't check the error
  code, it assumes that all non-zero values mean buffer overflow.
* all the other targets always return 0.

This patch changes the ti-&gt;type-&gt;status function to return void (because
most targets don't use the return code). Overflow is detected in
retrieve_status: if the status method fills up the remaining space
completely, it is assumed that buffer overflow happened.

Signed-off-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Signed-off-by: Alasdair G Kergon &lt;agk@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iommu/vt-d: Fixed interaction of VFIO_IOMMU_MAP_DMA with IOMMU address limits</title>
<updated>2013-12-08T15:29:43Z</updated>
<author>
<name>Julian Stecklina</name>
<email>jsteckli@os.inf.tu-dresden.de</email>
</author>
<published>2013-10-09T08:03:52Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=3dc062d269601c3f2f9860e9033906d303661622'/>
<id>urn:sha1:3dc062d269601c3f2f9860e9033906d303661622</id>
<content type='text'>
commit f9423606ade08653dd8a43334f0a7fb45504c5cc upstream.

The BUG_ON in drivers/iommu/intel-iommu.c:785 can be triggered from userspace via
VFIO by calling the VFIO_IOMMU_MAP_DMA ioctl on a vfio device with any address
beyond the addressing capabilities of the IOMMU. The problem is that the ioctl code
calls iommu_iova_to_phys before it calls iommu_map. iommu_map handles the case that
it gets addresses beyond the addressing capabilities of its IOMMU.
intel_iommu_iova_to_phys does not.

This patch fixes iommu_iova_to_phys to return NULL for addresses beyond what the
IOMMU can handle. This in turn causes the ioctl call to fail in iommu_map and
(correctly) return EFAULT to the user with a helpful warning message in the kernel
log.

Signed-off-by: Julian Stecklina &lt;jsteckli@os.inf.tu-dresden.de&gt;
Acked-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
Signed-off-by: Joerg Roedel &lt;joro@8bytes.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>video: kyro: fix incorrect sizes when copying to userspace</title>
<updated>2013-12-08T15:29:43Z</updated>
<author>
<name>Sasha Levin</name>
<email>sasha.levin@oracle.com</email>
</author>
<published>2013-11-19T19:25:36Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=6fa8c5d6ac1afc5563932d7220ed01ee959a8764'/>
<id>urn:sha1:6fa8c5d6ac1afc5563932d7220ed01ee959a8764</id>
<content type='text'>
commit 2ab68ec927310dc488f3403bb48f9e4ad00a9491 upstream.

kyro would copy u32s and specify sizeof(unsigned long) as the size to copy.

This would copy more data than intended and cause memory corruption and might
leak kernel memory.

Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mmc: block: fix a bug of error handling in MMC driver</title>
<updated>2013-12-08T15:29:42Z</updated>
<author>
<name>KOBAYASHI Yoshitake</name>
<email>yoshitake.kobayashi@toshiba.co.jp</email>
</author>
<published>2013-07-06T22:35:45Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=98048d9b597625034b47f7e0bd04595b6002a045'/>
<id>urn:sha1:98048d9b597625034b47f7e0bd04595b6002a045</id>
<content type='text'>
commit c8760069627ad3b0dbbea170f0c4c58b16e18d3d upstream.

Current MMC driver doesn't handle generic error (bit19 of device
status) in write sequence. As a result, write data gets lost when
generic error occurs. For example, a generic error when updating a
filesystem management information causes a loss of write data and
corrupts the filesystem. In the worst case, the system will never
boot.

This patch includes the following functionality:
  1. To enable error checking for the response of CMD12 and CMD13
     in write command sequence
  2. To retry write sequence when a generic error occurs

Messages are added for v2 to show what occurs.

Signed-off-by: KOBAYASHI Yoshitake &lt;yoshitake.kobayashi@toshiba.co.jp&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</content>
</entry>
<entry>
<title>HID: picolcd_core: validate output report details</title>
<updated>2013-12-08T15:29:42Z</updated>
<author>
<name>Kees Cook</name>
<email>keescook@chromium.org</email>
</author>
<published>2013-08-28T20:31:52Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=12c1f610fe8574b5ea9374344f1684b5d972d50b'/>
<id>urn:sha1:12c1f610fe8574b5ea9374344f1684b5d972d50b</id>
<content type='text'>
commit 1e87a2456b0227ca4ab881e19a11bb99d164e792 upstream.

A HID device could send a malicious output report that would cause the
picolcd HID driver to trigger a NULL dereference during attr file writing.

[jkosina@suse.cz: changed

	report-&gt;maxfield &lt; 1

to

	report-&gt;maxfield != 1

as suggested by Bruno].

CVE-2013-2899

Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Cc: stable@kernel.org
Reviewed-by: Bruno Prémont &lt;bonbons@linux-vserver.org&gt;
Acked-by: Bruno Prémont &lt;bonbons@linux-vserver.org&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
[Kefeng: backported to stable 3.4: adjust filename]
Signed-off-by: Kefeng Wang &lt;wangkefeng.wang@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>atm: idt77252: fix dev refcnt leak</title>
<updated>2013-12-08T15:29:42Z</updated>
<author>
<name>Ying Xue</name>
<email>ying.xue@windriver.com</email>
</author>
<published>2013-11-19T10:09:27Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=12263a242549802fc76da6f39b4d8f5ca080a71b'/>
<id>urn:sha1:12263a242549802fc76da6f39b4d8f5ca080a71b</id>
<content type='text'>
[ Upstream commit b5de4a22f157ca345cdb3575207bf46402414bc1 ]

init_card() calls dev_get_by_name() to get a network deceive. But it
doesn't decrease network device reference count after the device is
used.

Signed-off-by: Ying Xue &lt;ying.xue@windriver.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: rework recvmsg handler msg_name and msg_namelen logic</title>
<updated>2013-12-08T15:29:41Z</updated>
<author>
<name>Hannes Frederic Sowa</name>
<email>hannes@stressinduktion.org</email>
</author>
<published>2013-11-21T02:14:22Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=18719a4c7a90af3de4bb071511dd4a6dcf61a2e0'/>
<id>urn:sha1:18719a4c7a90af3de4bb071511dd4a6dcf61a2e0</id>
<content type='text'>
[ Upstream commit f3d3342602f8bcbf37d7c46641cb9bca7618eb1c ]

This patch now always passes msg-&gt;msg_namelen as 0. recvmsg handlers must
set msg_namelen to the proper size &lt;= sizeof(struct sockaddr_storage)
to return msg_name to the user.

This prevents numerous uninitialized memory leaks we had in the
recvmsg handlers and makes it harder for new code to accidentally leak
uninitialized memory.

Optimize for the case recvfrom is called with NULL as address. We don't
need to copy the address at all, so set it to NULL before invoking the
recvmsg handler. We can do so, because all the recvmsg handlers must
cope with the case a plain read() is called on them. read() also sets
msg_name to NULL.

Also document these changes in include/linux/net.h as suggested by David
Miller.

Changes since RFC:

Set msg-&gt;msg_name = NULL if user specified a NULL in msg_name but had a
non-null msg_namelen in verify_iovec/verify_compat_iovec. This doesn't
affect sendto as it would bail out earlier while trying to copy-in the
address. It also more naturally reflects the logic by the callers of
verify_iovec.

With this change in place I could remove "
if (!uaddr || msg_sys-&gt;msg_namelen == 0)
	msg-&gt;msg_name = NULL
".

This change does not alter the user visible error logic as we ignore
msg_namelen as long as msg_name is NULL.

Also remove two unnecessary curly brackets in ___sys_recvmsg and change
comments to netdev style.

Cc: David Miller &lt;davem@davemloft.net&gt;
Suggested-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>connector: improved unaligned access error fix</title>
<updated>2013-12-08T15:29:41Z</updated>
<author>
<name>Chris Metcalf</name>
<email>cmetcalf@tilera.com</email>
</author>
<published>2013-11-14T17:09:21Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=5faa67af221bba0e3e544d4771d608dc4ef611f6'/>
<id>urn:sha1:5faa67af221bba0e3e544d4771d608dc4ef611f6</id>
<content type='text'>
[ Upstream commit 1ca1a4cf59ea343a1a70084fe7cc96f37f3cf5b1 ]

In af3e095a1fb4, Erik Jacobsen fixed one type of unaligned access
bug for ia64 by converting a 64-bit write to use put_unaligned().
Unfortunately, since gcc will convert a short memset() to a series
of appropriately-aligned stores, the problem is now visible again
on tilegx, where the memset that zeros out proc_event is converted
to three 64-bit stores, causing an unaligned access panic.

A better fix for the original problem is to ensure that proc_event
is aligned to 8 bytes here.  We can do that relatively easily by
arranging to start the struct cn_msg aligned to 8 bytes and then
offset by 4 bytes.  Doing so means that the immediately following
proc_event structure is then correctly aligned to 8 bytes.

The result is that the memset() stores are now aligned, and as an
added benefit, we can remove the put_unaligned() calls in the code.

Signed-off-by: Chris Metcalf &lt;cmetcalf@tilera.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>isdnloop: use strlcpy() instead of strcpy()</title>
<updated>2013-12-08T15:29:41Z</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2013-11-14T08:21:10Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=0434f1641051d148682321b68ba8108ae9c52c98'/>
<id>urn:sha1:0434f1641051d148682321b68ba8108ae9c52c98</id>
<content type='text'>
[ Upstream commit f9a23c84486ed350cce7bb1b2828abd1f6658796 ]

These strings come from a copy_from_user() and there is no way to be
sure they are NUL terminated.

Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>bonding: fix two race conditions in bond_store_updelay/downdelay</title>
<updated>2013-12-08T15:29:41Z</updated>
<author>
<name>Nikolay Aleksandrov</name>
<email>nikolay@redhat.com</email>
</author>
<published>2013-11-13T16:07:46Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=e6f3fa48929dbcdcf3dd92507dbe32347645a969'/>
<id>urn:sha1:e6f3fa48929dbcdcf3dd92507dbe32347645a969</id>
<content type='text'>
[ Upstream commit b869ccfab1e324507fa3596e3e1308444fb68227 ]

This patch fixes two race conditions between bond_store_updelay/downdelay
and bond_store_miimon which could lead to division by zero as miimon can
be set to 0 while either updelay/downdelay are being set and thus miss the
zero check in the beginning, the zero div happens because updelay/downdelay
are stored as new_value / bond-&gt;params.miimon. Use rtnl to synchronize with
miimon setting.

Signed-off-by: Nikolay Aleksandrov &lt;nikolay@redhat.com&gt;
CC: Jay Vosburgh &lt;fubar@us.ibm.com&gt;
CC: Andy Gospodarek &lt;andy@greyhouse.net&gt;
CC: Veaceslav Falico &lt;vfalico@redhat.com&gt;
Acked-by: Veaceslav Falico &lt;vfalico@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
