<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers, branch v4.9.110</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.9.110</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.9.110'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2018-06-26T00:08:08+00:00</updated>
<entry>
<title>vhost: fix info leak due to uninitialized memory</title>
<updated>2018-06-26T00:08:08+00:00</updated>
<author>
<name>Michael S. Tsirkin</name>
<email>mst@redhat.com</email>
</author>
<published>2018-05-11T21:33:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9681c3bdb098f6c87a0422b6b63912c1b90ad197'/>
<id>urn:sha1:9681c3bdb098f6c87a0422b6b63912c1b90ad197</id>
<content type='text'>
commit 670ae9caaca467ea1bfd325cb2a5c98ba87f94ad upstream.

struct vhost_msg within struct vhost_msg_node is copied to userspace.
Unfortunately it turns out on 64 bit systems vhost_msg has padding after
type which gcc doesn't initialize, leaking 4 uninitialized bytes to
userspace.

This padding also unfortunately means 32 bit users of this interface are
broken on a 64 bit kernel which will need to be fixed separately.

Fixes: CVE-2018-1118
Cc: stable@vger.kernel.org
Reported-by: Kevin Easton &lt;kevin@guarana.org&gt;
Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Reported-by: syzbot+87cfa083e727a224754b@syzkaller.appspotmail.com
Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>HID: intel_ish-hid: ipc: register more pm callbacks to support hibernation</title>
<updated>2018-06-26T00:08:08+00:00</updated>
<author>
<name>Even Xu</name>
<email>even.xu@intel.com</email>
</author>
<published>2016-02-11T20:11:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a875bc1c9ec116b7b2b2f15f8edc2a2ac3c51f99'/>
<id>urn:sha1:a875bc1c9ec116b7b2b2f15f8edc2a2ac3c51f99</id>
<content type='text'>
commit ebeaa367548e9e92dd9374b9464ff6e7d157117b upstream.

Current ISH driver only registers suspend/resume PM callbacks which don't
support hibernation (suspend to disk). Basically after hiberation, the ISH
can't resume properly and user may not see sensor events (for example: screen
		rotation may not work).

User will not see a crash or panic or anything except the following message
in log:

	hid-sensor-hub 001F:8086:22D8.0001: timeout waiting for response from ISHTP device

So this patch adds support for S4/hiberbation to ISH by using the
SIMPLE_DEV_PM_OPS() MACRO instead of struct dev_pm_ops directly. The suspend
and resume functions will now be used for both suspend to RAM and hibernation.

If power management is disabled, SIMPLE_DEV_PM_OPS will do nothing, the suspend
and resume related functions won't be used, so mark them as __maybe_unused to
clarify that this is the intended behavior, and remove #ifdefs for power
management.

Cc: stable@vger.kernel.org
Signed-off-by: Even Xu &lt;even.xu@intel.com&gt;
Acked-by: Srinivas Pandruvada &lt;srinivas.pandruvada@linux.intel.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>w1: mxc_w1: Enable clock before calling clk_get_rate() on it</title>
<updated>2018-06-26T00:08:08+00:00</updated>
<author>
<name>Stefan Potyra</name>
<email>Stefan.Potyra@elektrobit.com</email>
</author>
<published>2018-05-02T08:55:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=aec3dd5ef1f0fb570027fe3a42bbc1d3d1f1828f'/>
<id>urn:sha1:aec3dd5ef1f0fb570027fe3a42bbc1d3d1f1828f</id>
<content type='text'>
commit 955bc61328dc0a297fb3baccd84e9d3aee501ed8 upstream.

According to the API, you may only call clk_get_rate() after actually
enabling it.

Found by Linux Driver Verification project (linuxtesting.org).

Fixes: a5fd9139f74c ("w1: add 1-wire master driver for i.MX27 / i.MX31")
Signed-off-by: Stefan Potyra &lt;Stefan.Potyra@elektrobit.com&gt;
Acked-by: Evgeniy Polyakov &lt;zbr@ioremap.net&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>libata: Drop SanDisk SD7UB3Q*G1001 NOLPM quirk</title>
<updated>2018-06-26T00:08:08+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2018-05-31T11:21:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=139cd53baf08d80db81eb32a72dc24501cb8f296'/>
<id>urn:sha1:139cd53baf08d80db81eb32a72dc24501cb8f296</id>
<content type='text'>
commit 2cfce3a86b64b53f0a70e92a6a659c720c319b45 upstream.

Commit 184add2ca23c ("libata: Apply NOLPM quirk for SanDisk
SD7UB3Q*G1001 SSDs") disabled LPM for SanDisk SD7UB3Q*G1001 SSDs.

This has lead to several reports of users of that SSD where LPM
was working fine and who know have a significantly increased idle
power consumption on their laptops.

Likely there is another problem on the T450s from the original
reporter which gets exposed by the uncore reaching deeper sleep
states (higher PC-states) due to LPM being enabled. The problem as
reported, a hardfreeze about once a day, already did not sound like
it would be caused by LPM and the reports of the SSD working fine
confirm this. The original reporter is ok with dropping the quirk.

A X250 user has reported the same hard freeze problem and for him
the problem went away after unrelated updates, I suspect some GPU
driver stack changes fixed things.

TL;DR: The original reporters problem were triggered by LPM but not
an LPM issue, so drop the quirk for the SSD in question.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1583207
Cc: stable@vger.kernel.org
Cc: Richard W.M. Jones &lt;rjones@redhat.com&gt;
Cc: Lorenzo Dalrio &lt;lorenzo.dalrio@gmail.com&gt;
Reported-by: Lorenzo Dalrio &lt;lorenzo.dalrio@gmail.com&gt;
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Acked-by: "Richard W.M. Jones" &lt;rjones@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>libata: zpodd: small read overflow in eject_tray()</title>
<updated>2018-06-26T00:08:08+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2018-05-29T09:13:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0e9806ec7376e1a285d7b9ee634a782f10155540'/>
<id>urn:sha1:0e9806ec7376e1a285d7b9ee634a782f10155540</id>
<content type='text'>
commit 18c9a99bce2a57dfd7e881658703b5d7469cc7b9 upstream.

We read from the cdb[] buffer in ata_exec_internal_sg().  It has to be
ATAPI_CDB_LEN (16) bytes long, but this buffer is only 12 bytes.

Fixes: 213342053db5 ("libata: handle power transition of ODD")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>libata: zpodd: make arrays cdb static, reduces object code size</title>
<updated>2018-06-26T00:08:08+00:00</updated>
<author>
<name>Colin Ian King</name>
<email>colin.king@canonical.com</email>
</author>
<published>2017-09-06T08:56:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=21e6919834360389b6f3db6a04603b6aba0c6219'/>
<id>urn:sha1:21e6919834360389b6f3db6a04603b6aba0c6219</id>
<content type='text'>
commit 795ef788145ed2fa023efdf11e8d5d7bedc21462 upstream.

Don't populate the arrays cdb on the stack, instead make them static.
Makes the object code smaller by 230 bytes:

Before:
   text	   data	    bss	    dec	    hex	filename
   3797	    240	      0	   4037	    fc5	drivers/ata/libata-zpodd.o

After:
   text	   data	    bss	    dec	    hex	filename
   3407	    400	      0	   3807	    edf	drivers/ata/libata-zpodd.o

Signed-off-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>cpufreq: Fix new policy initialization during limits updates via sysfs</title>
<updated>2018-06-26T00:08:08+00:00</updated>
<author>
<name>Tao Wang</name>
<email>kevin.wangtao@hisilicon.com</email>
</author>
<published>2018-05-26T07:16:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5930589d3f85484611a9084169c8e86a8c183284'/>
<id>urn:sha1:5930589d3f85484611a9084169c8e86a8c183284</id>
<content type='text'>
commit c7d1f119c48f64bebf0fa1e326af577c6152fe30 upstream.

If the policy limits are updated via cpufreq_update_policy() and
subsequently via sysfs, the limits stored in user_policy may be
set incorrectly.

For example, if both min and max are set via sysfs to the maximum
available frequency, user_policy.min and user_policy.max will also
be the maximum.  If a policy notifier triggered by
cpufreq_update_policy() lowers both the min and the max at this
point, that change is not reflected by the user_policy limits, so
if the max is updated again via sysfs to the same lower value,
then user_policy.max will be lower than user_policy.min which
shouldn't happen.  In particular, if one of the policy CPUs is
then taken offline and back online, cpufreq_set_policy() will
fail for it due to a failing limits check.

To prevent that from happening, initialize the min and max fields
of the new_policy object to the ones stored in user_policy that
were previously set via sysfs.

Signed-off-by: Kevin Wangtao &lt;kevin.wangtao@hisilicon.com&gt;
Acked-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
[ rjw: Subject &amp; changelog ]
Cc: All applicable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>driver core: Don't ignore class_dir_create_and_add() failure.</title>
<updated>2018-06-26T00:08:07+00:00</updated>
<author>
<name>Tetsuo Handa</name>
<email>penguin-kernel@I-love.SAKURA.ne.jp</email>
</author>
<published>2018-05-07T10:10:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4f65ebcffa53ae01ffded87f83d92fd0caaafc5d'/>
<id>urn:sha1:4f65ebcffa53ae01ffded87f83d92fd0caaafc5d</id>
<content type='text'>
commit 84d0c27d6233a9ba0578b20f5a09701eb66cee42 upstream.

syzbot is hitting WARN() at kernfs_add_one() [1].
This is because kernfs_create_link() is confused by previous device_add()
call which continued without setting dev-&gt;kobj.parent field when
get_device_parent() failed by memory allocation fault injection.
Fix this by propagating the error from class_dir_create_and_add() to
the calllers of get_device_parent().

[1] https://syzkaller.appspot.com/bug?id=fae0fb607989ea744526d1c082a5b8de6529116f

Signed-off-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
Reported-by: syzbot &lt;syzbot+df47f81c226b31d89fb1@syzkaller.appspotmail.com&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>bonding: re-evaluate force_primary when the primary slave name changes</title>
<updated>2018-06-26T00:08:06+00:00</updated>
<author>
<name>Xiangning Yu</name>
<email>yuxiangning@gmail.com</email>
</author>
<published>2018-06-07T05:39:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=780617b249e469750a49d38d0cdc845ba7398ea1'/>
<id>urn:sha1:780617b249e469750a49d38d0cdc845ba7398ea1</id>
<content type='text'>
[ Upstream commit eb55bbf865d9979098c6a7a17cbdb41237ece951 ]

There is a timing issue under active-standy mode, when bond_enslave() is
called, bond-&gt;params.primary might not be initialized yet.

Any time the primary slave string changes, bond-&gt;force_primary should be
set to true to make sure the primary becomes the active slave.

Signed-off-by: Xiangning Yu &lt;yuxiangning@gmail.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>usb: musb: fix remote wakeup racing with suspend</title>
<updated>2018-06-26T00:08:06+00:00</updated>
<author>
<name>Daniel Glöckner</name>
<email>dg@emlix.com</email>
</author>
<published>2018-05-14T14:40:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c4f24a093f02bc43a602c08550d828ce34477380'/>
<id>urn:sha1:c4f24a093f02bc43a602c08550d828ce34477380</id>
<content type='text'>
[ Upstream commit ebc3dd688cd988754a304147753b13e58de1b5a1 ]

It has been observed that writing 0xF2 to the power register while it
reads as 0xF4 results in the register having the value 0xF0, i.e. clearing
RESUME and setting SUSPENDM in one go does not work. It might also violate
the USB spec to transition directly from resume to suspend, especially
when not taking T_DRSMDN into account. But this is what happens when a
remote wakeup occurs between SetPortFeature USB_PORT_FEAT_SUSPEND on the
root hub and musb_bus_suspend being called.

This commit returns -EBUSY when musb_bus_suspend is called while remote
wakeup is signalled and thus avoids to reset the RESUME bit. Ignoring
this error when musb_port_suspend is called from musb_hub_control is ok.

Signed-off-by: Daniel Glöckner &lt;dg@emlix.com&gt;
Signed-off-by: Bin Liu &lt;b-liu@ti.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
