<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/scsi, branch v3.12.59</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>be2iscsi: set the boot_kset pointer to NULL in case of failure</title>
<updated>2016-04-11T14:44:03+00:00</updated>
<author>
<name>Maurizio Lombardi</name>
<email>mlombard@redhat.com</email>
</author>
<published>2016-03-04T09:41:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bbb8253942cd0e935bb5b3b01970e098422ef270'/>
<id>bbb8253942cd0e935bb5b3b01970e098422ef270</id>
<content type='text'>
commit 84bd64993f916bcf86270c67686ecf4cea7b8933 upstream.

In beiscsi_setup_boot_info(), the boot_kset pointer should be set to
NULL in case of failure otherwise an invalid pointer dereference may
occur later.

Signed-off-by: Maurizio Lombardi &lt;mlombard@redhat.com&gt;
Reviewed-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Reviewed-by: Jitendra Bhivare &lt;jitendra.bhivare@broadcom.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 84bd64993f916bcf86270c67686ecf4cea7b8933 upstream.

In beiscsi_setup_boot_info(), the boot_kset pointer should be set to
NULL in case of failure otherwise an invalid pointer dereference may
occur later.

Signed-off-by: Maurizio Lombardi &lt;mlombard@redhat.com&gt;
Reviewed-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Reviewed-by: Jitendra Bhivare &lt;jitendra.bhivare@broadcom.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>aacraid: Fix memory leak in aac_fib_map_free</title>
<updated>2016-04-11T14:44:02+00:00</updated>
<author>
<name>Raghava Aditya Renukunta</name>
<email>raghavaaditya.renukunta@pmcs.com</email>
</author>
<published>2016-02-03T23:06:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2b565174937e555c5d92770c71987a5b5cb942eb'/>
<id>2b565174937e555c5d92770c71987a5b5cb942eb</id>
<content type='text'>
commit f88fa79a61726ce9434df9b4aede36961f709f17 upstream.

aac_fib_map_free() calls pci_free_consistent() without checking that
dev-&gt;hw_fib_va is not NULL and dev-&gt;max_fib_size is not zero.If they are
indeed NULL/0, this will result in a hang as pci_free_consistent() will
attempt to invalidate cache for the entire 64-bit address space
(which would take a very long time).

Fixed by adding a check to make sure that dev-&gt;hw_fib_va and
dev-&gt;max_fib_size are not NULL and 0 respectively.

Fixes: 9ad5204d6 - "[SCSI]aacraid: incorrect dma mapping mask during blinked recover or user initiated reset"
Signed-off-by: Raghava Aditya Renukunta &lt;raghavaaditya.renukunta@pmcs.com&gt;
Reviewed-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Reviewed-by: Tomas Henzl &lt;thenzl@redhat.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit f88fa79a61726ce9434df9b4aede36961f709f17 upstream.

aac_fib_map_free() calls pci_free_consistent() without checking that
dev-&gt;hw_fib_va is not NULL and dev-&gt;max_fib_size is not zero.If they are
indeed NULL/0, this will result in a hang as pci_free_consistent() will
attempt to invalidate cache for the entire 64-bit address space
(which would take a very long time).

Fixed by adding a check to make sure that dev-&gt;hw_fib_va and
dev-&gt;max_fib_size are not NULL and 0 respectively.

Fixes: 9ad5204d6 - "[SCSI]aacraid: incorrect dma mapping mask during blinked recover or user initiated reset"
Signed-off-by: Raghava Aditya Renukunta &lt;raghavaaditya.renukunta@pmcs.com&gt;
Reviewed-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Reviewed-by: Tomas Henzl &lt;thenzl@redhat.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>sg: fix dxferp in from_to case</title>
<updated>2016-04-11T14:44:02+00:00</updated>
<author>
<name>Douglas Gilbert</name>
<email>dgilbert@interlog.com</email>
</author>
<published>2016-03-03T05:31:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5a180c98143ff8f05bd99e585690f2e658328405'/>
<id>5a180c98143ff8f05bd99e585690f2e658328405</id>
<content type='text'>
commit 5ecee0a3ee8d74b6950cb41e8989b0c2174568d4 upstream.

One of the strange things that the original sg driver did was let the
user provide both a data-out buffer (it followed the sg_header+cdb)
_and_ specify a reply length greater than zero. What happened was that
the user data-out buffer was copied into some kernel buffers and then
the mid level was told a read type operation would take place with the
data from the device overwriting the same kernel buffers. The user would
then read those kernel buffers back into the user space.

From what I can tell, the above action was broken by commit fad7f01e61bf
("sg: set dxferp to NULL for READ with the older SG interface") in 2008
and syzkaller found that out recently.

Make sure that a user space pointer is passed through when data follows
the sg_header structure and command.  Fix the abnormal case when a
non-zero reply_len is also given.

Fixes: fad7f01e61bf737fe8a3740d803f000db57ecac6
Signed-off-by: Douglas Gilbert &lt;dgilbert@interlog.com&gt;
Reviewed-by: Ewan Milne &lt;emilne@redhat.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 5ecee0a3ee8d74b6950cb41e8989b0c2174568d4 upstream.

One of the strange things that the original sg driver did was let the
user provide both a data-out buffer (it followed the sg_header+cdb)
_and_ specify a reply length greater than zero. What happened was that
the user data-out buffer was copied into some kernel buffers and then
the mid level was told a read type operation would take place with the
data from the device overwriting the same kernel buffers. The user would
then read those kernel buffers back into the user space.

From what I can tell, the above action was broken by commit fad7f01e61bf
("sg: set dxferp to NULL for READ with the older SG interface") in 2008
and syzkaller found that out recently.

Make sure that a user space pointer is passed through when data follows
the sg_header structure and command.  Fix the abnormal case when a
non-zero reply_len is also given.

Fixes: fad7f01e61bf737fe8a3740d803f000db57ecac6
Signed-off-by: Douglas Gilbert &lt;dgilbert@interlog.com&gt;
Reviewed-by: Ewan Milne &lt;emilne@redhat.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Fix kmalloc overflow in LPFC driver at large core count</title>
<updated>2016-04-11T14:43:55+00:00</updated>
<author>
<name>Ian Mitchell</name>
<email>imitchell@sgi.com</email>
</author>
<published>2015-08-31T20:48:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d93cbb4439e3d9e898df3dd526db2e4c3f5d7968'/>
<id>d93cbb4439e3d9e898df3dd526db2e4c3f5d7968</id>
<content type='text'>
commit c0365c0692d6ea038bb4feda308eec69e11292a3 upstream.

This patch allows the LPFC to start up without a fatal kernel bug based
on an exceeded KMALLOC_MAX_SIZE and a too large NR_CPU-based maskbits
field. The bug was based on the number of CPU cores in a system.
Using the get_cpu_mask() function declared in kernel/cpu.c allows the
driver to load on the community kernel 4.2 RC1.

Below is the kernel bug reproduced:

8&lt;--------------------------------------------------------------------
2199382.828437 (    0.005216)| lpfc 0003:02:00.0: enabling device (0140 -&gt; 0142)
2199382.999272 (    0.170835)| ------------[ cut here ]------------
2199382.999337 (    0.000065)| WARNING: CPU: 84 PID: 404 at mm/slab_common.c:653 kmalloc_slab+0x2f/0x89()
2199383.004534 (    0.005197)| Modules linked in: lpfc(+) usbcore(+) mptctl scsi_transport_fc sg lpc_ich i2c_i801 usb_common tpm_tis mfd_core tpm acpi_cpufreq button scsi_dh_alua scsi_dh_rdacusbcore: registered new device driver usb
2199383.020568 (    0.016034)|
2199383.020581 (    0.000013)|  scsi_dh_hp_sw scsi_dh_emc scsi_dh gru thermal sata_nv processor piix fan thermal_sysehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
2199383.035288 (    0.014707)|
2199383.035306 (    0.000018)|  hwmon ata_piix
2199383.035336 (    0.000030)| CPU: 84 PID: 404 Comm: kworker/84:0 Not tainted 3.18.0-rc2-gat-00106-ga7ca10f-dirty #178
2199383.047077 (    0.011741)| ehci-pci: EHCI PCI platform driver
2199383.047134 (    0.000057)| Hardware name: SGI UV2000/ROMLEY, BIOS SGI UV 2000/3000 series BIOS 01/15/2013
2199383.056245 (    0.009111)| Workqueue: events work_for_cpu_fn
2199383.066174 (    0.009929)|  000000000000028d ffff88eef827bbe8 ffffffff815a542f 000000000000028d
2199383.069545 (    0.003371)|  ffffffff810ea142 ffff88eef827bc28 ffffffff8104365c ffff88eefe4006c8
2199383.076214 (    0.006669)|  0000000000000000 00000000000080d0 0000000000000000 0000000000000004
2199383.079213 (    0.002999)| Call Trace:
2199383.084084 (    0.004871)|  [&lt;ffffffff815a542f&gt;] dump_stack+0x49/0x62
2199383.087283 (    0.003199)|  [&lt;ffffffff810ea142&gt;] ? kmalloc_slab+0x2f/0x89
2199383.091415 (    0.004132)|  [&lt;ffffffff8104365c&gt;] warn_slowpath_common+0x77/0x92
2199383.095197 (    0.003782)|  [&lt;ffffffff8104368c&gt;] warn_slowpath_null+0x15/0x17
2199383.103336 (    0.008139)|  [&lt;ffffffff810ea142&gt;] kmalloc_slab+0x2f/0x89
2199383.107082 (    0.003746)|  [&lt;ffffffff8110fd9e&gt;] __kmalloc+0x13/0x16a
2199383.112531 (    0.005449)|  [&lt;ffffffffa01a8ed9&gt;] lpfc_pci_probe_one_s4+0x105b/0x1644 [lpfc]
2199383.115316 (    0.002785)|  [&lt;ffffffff81302b92&gt;] ? pci_bus_read_config_dword+0x75/0x87
2199383.123431 (    0.008115)|  [&lt;ffffffffa01a951f&gt;] lpfc_pci_probe_one+0x5d/0xcb5 [lpfc]
2199383.127364 (    0.003933)|  [&lt;ffffffff81497119&gt;] ? dbs_check_cpu+0x168/0x177
2199383.136438 (    0.009074)|  [&lt;ffffffff81496fa5&gt;] ? gov_queue_work+0xb4/0xc0
2199383.140407 (    0.003969)|  [&lt;ffffffff8130b2a1&gt;] local_pci_probe+0x1e/0x52
2199383.143105 (    0.002698)|  [&lt;ffffffff81052c47&gt;] work_for_cpu_fn+0x13/0x1b
2199383.147315 (    0.004210)|  [&lt;ffffffff81054965&gt;] process_one_work+0x222/0x35e
2199383.151379 (    0.004064)|  [&lt;ffffffff81054e76&gt;] worker_thread+0x3d5/0x46e
2199383.159402 (    0.008023)|  [&lt;ffffffff81054aa1&gt;] ? process_one_work+0x35e/0x35e
2199383.163097 (    0.003695)|  [&lt;ffffffff810599c6&gt;] kthread+0xc8/0xd2
2199383.167476 (    0.004379)|  [&lt;ffffffff810598fe&gt;] ? kthread_freezable_should_stop+0x5b/0x5b
2199383.176434 (    0.008958)|  [&lt;ffffffff815a8cac&gt;] ret_from_fork+0x7c/0xb0
2199383.180086 (    0.003652)|  [&lt;ffffffff810598fe&gt;] ? kthread_freezable_should_stop+0x5b/0x5b
2199383.192333 (    0.012247)| ehci-pci 0000:00:1a.0: EHCI Host Controller
--------------------------------------------------------------------&gt;8

The proposed solution was approved by James Smart at Emulex and tested
on a UV2 machine with 6144 cores. With the fix, the LPFC module loads
with no unwanted effects on the system.

Signed-off-by: Ian Mitchell &lt;imitchell@sgi.com&gt;
Signed-off-by: Alex Thorlton &lt;athorlton@sgi.com&gt;
Suggested-by: Robert Elliot &lt;elliott@hp.com&gt;
[james.smart: resolve unused variable warning]
Signed-off-by: James Smart &lt;james.smart@avagotech.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Odin.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit c0365c0692d6ea038bb4feda308eec69e11292a3 upstream.

This patch allows the LPFC to start up without a fatal kernel bug based
on an exceeded KMALLOC_MAX_SIZE and a too large NR_CPU-based maskbits
field. The bug was based on the number of CPU cores in a system.
Using the get_cpu_mask() function declared in kernel/cpu.c allows the
driver to load on the community kernel 4.2 RC1.

Below is the kernel bug reproduced:

8&lt;--------------------------------------------------------------------
2199382.828437 (    0.005216)| lpfc 0003:02:00.0: enabling device (0140 -&gt; 0142)
2199382.999272 (    0.170835)| ------------[ cut here ]------------
2199382.999337 (    0.000065)| WARNING: CPU: 84 PID: 404 at mm/slab_common.c:653 kmalloc_slab+0x2f/0x89()
2199383.004534 (    0.005197)| Modules linked in: lpfc(+) usbcore(+) mptctl scsi_transport_fc sg lpc_ich i2c_i801 usb_common tpm_tis mfd_core tpm acpi_cpufreq button scsi_dh_alua scsi_dh_rdacusbcore: registered new device driver usb
2199383.020568 (    0.016034)|
2199383.020581 (    0.000013)|  scsi_dh_hp_sw scsi_dh_emc scsi_dh gru thermal sata_nv processor piix fan thermal_sysehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
2199383.035288 (    0.014707)|
2199383.035306 (    0.000018)|  hwmon ata_piix
2199383.035336 (    0.000030)| CPU: 84 PID: 404 Comm: kworker/84:0 Not tainted 3.18.0-rc2-gat-00106-ga7ca10f-dirty #178
2199383.047077 (    0.011741)| ehci-pci: EHCI PCI platform driver
2199383.047134 (    0.000057)| Hardware name: SGI UV2000/ROMLEY, BIOS SGI UV 2000/3000 series BIOS 01/15/2013
2199383.056245 (    0.009111)| Workqueue: events work_for_cpu_fn
2199383.066174 (    0.009929)|  000000000000028d ffff88eef827bbe8 ffffffff815a542f 000000000000028d
2199383.069545 (    0.003371)|  ffffffff810ea142 ffff88eef827bc28 ffffffff8104365c ffff88eefe4006c8
2199383.076214 (    0.006669)|  0000000000000000 00000000000080d0 0000000000000000 0000000000000004
2199383.079213 (    0.002999)| Call Trace:
2199383.084084 (    0.004871)|  [&lt;ffffffff815a542f&gt;] dump_stack+0x49/0x62
2199383.087283 (    0.003199)|  [&lt;ffffffff810ea142&gt;] ? kmalloc_slab+0x2f/0x89
2199383.091415 (    0.004132)|  [&lt;ffffffff8104365c&gt;] warn_slowpath_common+0x77/0x92
2199383.095197 (    0.003782)|  [&lt;ffffffff8104368c&gt;] warn_slowpath_null+0x15/0x17
2199383.103336 (    0.008139)|  [&lt;ffffffff810ea142&gt;] kmalloc_slab+0x2f/0x89
2199383.107082 (    0.003746)|  [&lt;ffffffff8110fd9e&gt;] __kmalloc+0x13/0x16a
2199383.112531 (    0.005449)|  [&lt;ffffffffa01a8ed9&gt;] lpfc_pci_probe_one_s4+0x105b/0x1644 [lpfc]
2199383.115316 (    0.002785)|  [&lt;ffffffff81302b92&gt;] ? pci_bus_read_config_dword+0x75/0x87
2199383.123431 (    0.008115)|  [&lt;ffffffffa01a951f&gt;] lpfc_pci_probe_one+0x5d/0xcb5 [lpfc]
2199383.127364 (    0.003933)|  [&lt;ffffffff81497119&gt;] ? dbs_check_cpu+0x168/0x177
2199383.136438 (    0.009074)|  [&lt;ffffffff81496fa5&gt;] ? gov_queue_work+0xb4/0xc0
2199383.140407 (    0.003969)|  [&lt;ffffffff8130b2a1&gt;] local_pci_probe+0x1e/0x52
2199383.143105 (    0.002698)|  [&lt;ffffffff81052c47&gt;] work_for_cpu_fn+0x13/0x1b
2199383.147315 (    0.004210)|  [&lt;ffffffff81054965&gt;] process_one_work+0x222/0x35e
2199383.151379 (    0.004064)|  [&lt;ffffffff81054e76&gt;] worker_thread+0x3d5/0x46e
2199383.159402 (    0.008023)|  [&lt;ffffffff81054aa1&gt;] ? process_one_work+0x35e/0x35e
2199383.163097 (    0.003695)|  [&lt;ffffffff810599c6&gt;] kthread+0xc8/0xd2
2199383.167476 (    0.004379)|  [&lt;ffffffff810598fe&gt;] ? kthread_freezable_should_stop+0x5b/0x5b
2199383.176434 (    0.008958)|  [&lt;ffffffff815a8cac&gt;] ret_from_fork+0x7c/0xb0
2199383.180086 (    0.003652)|  [&lt;ffffffff810598fe&gt;] ? kthread_freezable_should_stop+0x5b/0x5b
2199383.192333 (    0.012247)| ehci-pci 0000:00:1a.0: EHCI Host Controller
--------------------------------------------------------------------&gt;8

The proposed solution was approved by James Smart at Emulex and tested
on a UV2 machine with 6144 cores. With the fix, the LPFC module loads
with no unwanted effects on the system.

Signed-off-by: Ian Mitchell &lt;imitchell@sgi.com&gt;
Signed-off-by: Alex Thorlton &lt;athorlton@sgi.com&gt;
Suggested-by: Robert Elliot &lt;elliott@hp.com&gt;
[james.smart: resolve unused variable warning]
Signed-off-by: James Smart &lt;james.smart@avagotech.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Odin.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipr: Fix regression when loading firmware</title>
<updated>2016-03-30T14:14:13+00:00</updated>
<author>
<name>Gabriel Krisman Bertazi</name>
<email>krisman@linux.vnet.ibm.com</email>
</author>
<published>2016-02-25T16:54:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7514ee10d606566daaf42df8fedc0e450249d69e'/>
<id>7514ee10d606566daaf42df8fedc0e450249d69e</id>
<content type='text'>
commit 21b81716c6bff24cda52dc75588455f879ddbfe9 upstream.

Commit d63c7dd5bcb9 ("ipr: Fix out-of-bounds null overwrite") removed
the end of line handling when storing the update_fw sysfs attribute.
This changed the userpace API because it started refusing writes
terminated by a line feed, which broke the update tools we already have.

This patch re-adds that handling, so both a write terminated by a line
feed or not can make it through with the update.

Fixes: d63c7dd5bcb9 ("ipr: Fix out-of-bounds null overwrite")
Signed-off-by: Gabriel Krisman Bertazi &lt;krisman@linux.vnet.ibm.com&gt;
Cc: Insu Yun &lt;wuninsu@gmail.com&gt;
Acked-by: Brian King &lt;brking@linux.vnet.ibm.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Cc: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 21b81716c6bff24cda52dc75588455f879ddbfe9 upstream.

Commit d63c7dd5bcb9 ("ipr: Fix out-of-bounds null overwrite") removed
the end of line handling when storing the update_fw sysfs attribute.
This changed the userpace API because it started refusing writes
terminated by a line feed, which broke the update tools we already have.

This patch re-adds that handling, so both a write terminated by a line
feed or not can make it through with the update.

Fixes: d63c7dd5bcb9 ("ipr: Fix out-of-bounds null overwrite")
Signed-off-by: Gabriel Krisman Bertazi &lt;krisman@linux.vnet.ibm.com&gt;
Cc: Insu Yun &lt;wuninsu@gmail.com&gt;
Acked-by: Brian King &lt;brking@linux.vnet.ibm.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Cc: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipr: Fix out-of-bounds null overwrite</title>
<updated>2016-03-30T14:14:12+00:00</updated>
<author>
<name>Insu Yun</name>
<email>wuninsu@gmail.com</email>
</author>
<published>2016-01-06T17:44:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=def91dea48a3acb14c2379b9461ae659d95616a2'/>
<id>def91dea48a3acb14c2379b9461ae659d95616a2</id>
<content type='text'>
commit d63c7dd5bcb9441af0526d370c43a65ca2c980d9 upstream.

Return value of snprintf is not bound by size value, 2nd argument.
(https://www.kernel.org/doc/htmldocs/kernel-api/API-snprintf.html).
Return value is number of printed chars, can be larger than 2nd
argument.  Therefore, it can write null byte out of bounds ofbuffer.
Since snprintf puts null, it does not need to put additional null byte.

Signed-off-by: Insu Yun &lt;wuninsu@gmail.com&gt;
Reviewed-by: Shane Seymour &lt;shane.seymour@hpe.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Cc: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit d63c7dd5bcb9441af0526d370c43a65ca2c980d9 upstream.

Return value of snprintf is not bound by size value, 2nd argument.
(https://www.kernel.org/doc/htmldocs/kernel-api/API-snprintf.html).
Return value is number of printed chars, can be larger than 2nd
argument.  Therefore, it can write null byte out of bounds ofbuffer.
Since snprintf puts null, it does not need to put additional null byte.

Signed-off-by: Insu Yun &lt;wuninsu@gmail.com&gt;
Reviewed-by: Shane Seymour &lt;shane.seymour@hpe.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Cc: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ses: fix additional element traversal bug</title>
<updated>2016-03-03T11:46:00+00:00</updated>
<author>
<name>James Bottomley</name>
<email>James.Bottomley@HansenPartnership.com</email>
</author>
<published>2015-12-11T17:16:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=107626c1d8e73311be1815837b16a2aa0195fdfe'/>
<id>107626c1d8e73311be1815837b16a2aa0195fdfe</id>
<content type='text'>
commit 5e1033561da1152c57b97ee84371dba2b3d64c25 upstream.

KASAN found that our additional element processing scripts drop off
the end of the VPD page into unallocated space.  The reason is that
not every element has additional information but our traversal
routines think they do, leading to them expecting far more additional
information than is present.  Fix this by adding a gate to the
traversal routine so that it only processes elements that are expected
to have additional information (list is in SES-2 section 6.1.13.1:
Additional Element Status diagnostic page overview)

Reported-by: Pavel Tikhomirov &lt;ptikhomirov@virtuozzo.com&gt;
Tested-by: Pavel Tikhomirov &lt;ptikhomirov@virtuozzo.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@HansenPartnership.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 5e1033561da1152c57b97ee84371dba2b3d64c25 upstream.

KASAN found that our additional element processing scripts drop off
the end of the VPD page into unallocated space.  The reason is that
not every element has additional information but our traversal
routines think they do, leading to them expecting far more additional
information than is present.  Fix this by adding a gate to the
traversal routine so that it only processes elements that are expected
to have additional information (list is in SES-2 section 6.1.13.1:
Additional Element Status diagnostic page overview)

Reported-by: Pavel Tikhomirov &lt;ptikhomirov@virtuozzo.com&gt;
Tested-by: Pavel Tikhomirov &lt;ptikhomirov@virtuozzo.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@HansenPartnership.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ses: Fix problems with simple enclosures</title>
<updated>2016-03-03T11:45:59+00:00</updated>
<author>
<name>James Bottomley</name>
<email>James.Bottomley@HansenPartnership.com</email>
</author>
<published>2015-12-08T17:00:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1d4d5a272c06bf2d9cf4cb797b68c8080ee7f972'/>
<id>1d4d5a272c06bf2d9cf4cb797b68c8080ee7f972</id>
<content type='text'>
commit 3417c1b5cb1fdc10261dbed42b05cc93166a78fd upstream.

Simple enclosure implementations (mostly USB) are allowed to return only
page 8 to every diagnostic query.  That really confuses our
implementation because we assume the return is the page we asked for and
end up doing incorrect offsets based on bogus information leading to
accesses outside of allocated ranges.  Fix that by checking the page
code of the return and giving an error if it isn't the one we asked for.
This should fix reported bugs with USB storage by simply refusing to
attach to enclosures that behave like this.  It's also good defensive
practise now that we're starting to see more USB enclosures.

Reported-by: Andrea Gelmini &lt;andrea.gelmini@gelma.net&gt;
Reviewed-by: Ewan D. Milne &lt;emilne@redhat.com&gt;
Reviewed-by: Tomas Henzl &lt;thenzl@redhat.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@HansenPartnership.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 3417c1b5cb1fdc10261dbed42b05cc93166a78fd upstream.

Simple enclosure implementations (mostly USB) are allowed to return only
page 8 to every diagnostic query.  That really confuses our
implementation because we assume the return is the page we asked for and
end up doing incorrect offsets based on bogus information leading to
accesses outside of allocated ranges.  Fix that by checking the page
code of the return and giving an error if it isn't the one we asked for.
This should fix reported bugs with USB storage by simply refusing to
attach to enclosures that behave like this.  It's also good defensive
practise now that we're starting to see more USB enclosures.

Reported-by: Andrea Gelmini &lt;andrea.gelmini@gelma.net&gt;
Reviewed-by: Ewan D. Milne &lt;emilne@redhat.com&gt;
Reviewed-by: Tomas Henzl &lt;thenzl@redhat.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@HansenPartnership.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>storvsc: Don't set the SRB_FLAGS_QUEUE_ACTION_ENABLE flag</title>
<updated>2016-03-03T11:45:57+00:00</updated>
<author>
<name>K. Y. Srinivasan</name>
<email>kys@microsoft.com</email>
</author>
<published>2015-08-31T15:21:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e0aeab837c65d28dd0923ea97ad0ed876bc1e71c'/>
<id>e0aeab837c65d28dd0923ea97ad0ed876bc1e71c</id>
<content type='text'>
commit 8cf308e1225f5f93575f03cc4dbef24516fa81c9 upstream.

Don't set the SRB_FLAGS_QUEUE_ACTION_ENABLE flag since we are not specifying
tags.  Without this, the qlogic driver doesn't work properly with storvsc.

Signed-off-by: K. Y. Srinivasan &lt;kys@microsoft.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Odin.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 8cf308e1225f5f93575f03cc4dbef24516fa81c9 upstream.

Don't set the SRB_FLAGS_QUEUE_ACTION_ENABLE flag since we are not specifying
tags.  Without this, the qlogic driver doesn't work properly with storvsc.

Signed-off-by: K. Y. Srinivasan &lt;kys@microsoft.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Odin.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>megaraid_sas : SMAP restriction--do not access user memory from IOCTL code</title>
<updated>2016-03-03T11:45:56+00:00</updated>
<author>
<name>sumit.saxena@avagotech.com</name>
<email>sumit.saxena@avagotech.com</email>
</author>
<published>2015-10-15T08:10:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8f5e11b31e179c491ac58e2826599deec35cf8f9'/>
<id>8f5e11b31e179c491ac58e2826599deec35cf8f9</id>
<content type='text'>
commit 323c4a02c631d00851d8edc4213c4d184ef83647 upstream.

This is an issue on SMAP enabled CPUs and 32 bit apps running on 64 bit
OS. Do not access user memory from kernel code. The SMAP bit restricts
accessing user memory from kernel code.

Signed-off-by: Sumit Saxena &lt;sumit.saxena@avagotech.com&gt;
Signed-off-by: Kashyap Desai &lt;kashyap.desai@avagotech.com&gt;
Reviewed-by: Tomas Henzl &lt;thenzl@redhat.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 323c4a02c631d00851d8edc4213c4d184ef83647 upstream.

This is an issue on SMAP enabled CPUs and 32 bit apps running on 64 bit
OS. Do not access user memory from kernel code. The SMAP bit restricts
accessing user memory from kernel code.

Signed-off-by: Sumit Saxena &lt;sumit.saxena@avagotech.com&gt;
Signed-off-by: Kashyap Desai &lt;kashyap.desai@avagotech.com&gt;
Reviewed-by: Tomas Henzl &lt;thenzl@redhat.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
</feed>
