<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/drivers, branch dev-5.7</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-5.7</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-5.7'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2020-08-04T07:58:36+00:00</updated>
<entry>
<title>Merge tag 'v5.7.12' into dev-5.7</title>
<updated>2020-08-04T07:58:36+00:00</updated>
<author>
<name>Joel Stanley</name>
<email>joel@jms.id.au</email>
</author>
<published>2020-08-04T07:58:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=9524588381df213554a10d3661a9200a4b7f6db2'/>
<id>urn:sha1:9524588381df213554a10d3661a9200a4b7f6db2</id>
<content type='text'>
This is the 5.7.12 stable release

Signed-off-by: Joel Stanley &lt;joel@jms.id.au&gt;
</content>
</entry>
<entry>
<title>regmap: debugfs: check count when read regmap file</title>
<updated>2020-07-31T16:47:16+00:00</updated>
<author>
<name>Peng Fan</name>
<email>peng.fan@nxp.com</email>
</author>
<published>2020-03-13T01:58:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=af5b25c4dbbcc33fed592d6640c54bd675d1a3b4'/>
<id>urn:sha1:af5b25c4dbbcc33fed592d6640c54bd675d1a3b4</id>
<content type='text'>
commit 74edd08a4fbf51d65fd8f4c7d8289cd0f392bd91 upstream.

When executing the following command, we met kernel dump.
dmesg -c &gt; /dev/null; cd /sys;
for i in `ls /sys/kernel/debug/regmap/* -d`; do
	echo "Checking regmap in $i";
	cat $i/registers;
done &amp;&amp; grep -ri "0x02d0" *;

It is because the count value is too big, and kmalloc fails. So add an
upper bound check to allow max size `PAGE_SIZE &lt;&lt; (MAX_ORDER - 1)`.

Signed-off-by: Peng Fan &lt;peng.fan@nxp.com&gt;
Link: https://lore.kernel.org/r/1584064687-12964-1-git-send-email-peng.fan@nxp.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drivers/net/wan/x25_asy: Fix to make it work</title>
<updated>2020-07-31T16:47:14+00:00</updated>
<author>
<name>Xie He</name>
<email>xie.he.0141@gmail.com</email>
</author>
<published>2020-07-16T23:44:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=e729ee0b697b4e32ecb9153771aa33e13f0b8a0d'/>
<id>urn:sha1:e729ee0b697b4e32ecb9153771aa33e13f0b8a0d</id>
<content type='text'>
[ Upstream commit 8fdcabeac39824fe67480fd9508d80161c541854 ]

This driver is not working because of problems of its receiving code.
This patch fixes it to make it work.

When the driver receives an LAPB frame, it should first pass the frame
to the LAPB module to process. After processing, the LAPB module passes
the data (the packet) back to the driver, the driver should then add a
one-byte pseudo header and pass the data to upper layers.

The changes to the "x25_asy_bump" function and the
"x25_asy_data_indication" function are to correctly implement this
procedure.

Also, the "x25_asy_unesc" function ignores any frame that is shorter
than 3 bytes. However the shortest frames are 2-byte long. So we need
to change it to allow 2-byte frames to pass.

Cc: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Martin Schiller &lt;ms@dev.tdt.de&gt;
Signed-off-by: Xie He &lt;xie.he.0141@gmail.com&gt;
Reviewed-by: Martin Schiller &lt;ms@dev.tdt.de&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>ath9k: Fix regression with Atheros 9271</title>
<updated>2020-07-29T08:20:01+00:00</updated>
<author>
<name>Mark O'Donovan</name>
<email>shiftee@posteo.net</email>
</author>
<published>2020-07-11T04:33:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=dcb80ffe3825fb551a293491424695198b2e397d'/>
<id>urn:sha1:dcb80ffe3825fb551a293491424695198b2e397d</id>
<content type='text'>
commit 92f53e2fda8bb9a559ad61d57bfb397ce67ed0ab upstream.

This fix allows ath9k_htc modules to connect to WLAN once again.

Fixes: 2bbcaaee1fcb ("ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=208251
Signed-off-by: Mark O'Donovan &lt;shiftee@posteo.net&gt;
Reported-by: Roman Mamedov &lt;rm@romanrm.net&gt;
Tested-by: Viktor Jägersküpper &lt;viktor_jaegerskuepper@freenet.de&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/20200711043324.8079-1-shiftee@posteo.net
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb</title>
<updated>2020-07-29T08:20:00+00:00</updated>
<author>
<name>Qiujun Huang</name>
<email>hqjagain@gmail.com</email>
</author>
<published>2020-04-04T04:18:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=b43063ff55858f73cbd44fc4496b3489c8bdfba4'/>
<id>urn:sha1:b43063ff55858f73cbd44fc4496b3489c8bdfba4</id>
<content type='text'>
commit 2bbcaaee1fcbd83272e29f31e2bb7e70d8c49e05 upstream.

In ath9k_hif_usb_rx_cb interface number is assumed to be 0.
usb_ifnum_to_if(urb-&gt;dev, 0)
But it isn't always true.

The case reported by syzbot:
https://lore.kernel.org/linux-usb/000000000000666c9c05a1c05d12@google.com
usb 2-1: new high-speed USB device number 2 using dummy_hcd
usb 2-1: config 1 has an invalid interface number: 2 but max is 0
usb 2-1: config 1 has no interface number 0
usb 2-1: New USB device found, idVendor=0cf3, idProduct=9271, bcdDevice=
1.08
usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
general protection fault, probably for non-canonical address
0xdffffc0000000015: 0000 [#1] SMP KASAN
KASAN: null-ptr-deref in range [0x00000000000000a8-0x00000000000000af]
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.6.0-rc5-syzkaller #0

Call Trace
__usb_hcd_giveback_urb+0x29a/0x550 drivers/usb/core/hcd.c:1650
usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1716
dummy_timer+0x1258/0x32ae drivers/usb/gadget/udc/dummy_hcd.c:1966
call_timer_fn+0x195/0x6f0 kernel/time/timer.c:1404
expire_timers kernel/time/timer.c:1449 [inline]
__run_timers kernel/time/timer.c:1773 [inline]
__run_timers kernel/time/timer.c:1740 [inline]
run_timer_softirq+0x5f9/0x1500 kernel/time/timer.c:1786
__do_softirq+0x21e/0x950 kernel/softirq.c:292
invoke_softirq kernel/softirq.c:373 [inline]
irq_exit+0x178/0x1a0 kernel/softirq.c:413
exiting_irq arch/x86/include/asm/apic.h:546 [inline]
smp_apic_timer_interrupt+0x141/0x540 arch/x86/kernel/apic/apic.c:1146
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829

Reported-and-tested-by: syzbot+40d5d2e8a4680952f042@syzkaller.appspotmail.com
Signed-off-by: Qiujun Huang &lt;hqjagain@gmail.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/20200404041838.10426-6-hqjagain@gmail.com
Cc: Viktor Jägersküpper &lt;viktor_jaegerskuepper@freenet.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>dm integrity: fix integrity recalculation that is improperly skipped</title>
<updated>2020-07-29T08:20:00+00:00</updated>
<author>
<name>Mikulas Patocka</name>
<email>mpatocka@redhat.com</email>
</author>
<published>2020-07-23T14:42:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=a3ec4725ddedf2ffacfee233c90ad0c34dfce27c'/>
<id>urn:sha1:a3ec4725ddedf2ffacfee233c90ad0c34dfce27c</id>
<content type='text'>
commit 5df96f2b9f58a5d2dc1f30fe7de75e197f2c25f2 upstream.

Commit adc0daad366b62ca1bce3e2958a40b0b71a8b8b3 ("dm: report suspended
device during destroy") broke integrity recalculation.

The problem is dm_suspended() returns true not only during suspend,
but also during resume. So this race condition could occur:
1. dm_integrity_resume calls queue_work(ic-&gt;recalc_wq, &amp;ic-&gt;recalc_work)
2. integrity_recalc (&amp;ic-&gt;recalc_work) preempts the current thread
3. integrity_recalc calls if (unlikely(dm_suspended(ic-&gt;ti))) goto unlock_ret;
4. integrity_recalc exits and no recalculating is done.

To fix this race condition, add a function dm_post_suspending that is
only true during the postsuspend phase and use it instead of
dm_suspended().

Signed-off-by: Mikulas Patocka &lt;mpatocka redhat com&gt;
Fixes: adc0daad366b ("dm: report suspended device during destroy")
Cc: stable vger kernel org # v4.18+
Signed-off-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/amd/powerplay: fix a crash when overclocking Vega M</title>
<updated>2020-07-29T08:19:59+00:00</updated>
<author>
<name>Qiu Wenbo</name>
<email>qiuwenbo@phytium.com.cn</email>
</author>
<published>2020-07-17T07:09:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=b00f624573229df95e68308162da6c419ef0b2b2'/>
<id>urn:sha1:b00f624573229df95e68308162da6c419ef0b2b2</id>
<content type='text'>
commit 88bb16ad998a0395fe4b346b7d3f621aaa0a2324 upstream.

Avoid kernel crash when vddci_control is SMU7_VOLTAGE_CONTROL_NONE and
vddci_voltage_table is empty. It has been tested on Intel Hades Canyon
(i7-8809G).

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=208489
Fixes: ac7822b0026f ("drm/amd/powerplay: add smumgr support for VEGAM (v2)")
Reviewed-by: Evan Quan &lt;evan.quan@amd.com&gt;
Signed-off-by: Qiu Wenbo &lt;qiuwenbo@phytium.com.cn&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/amdgpu: Fix NULL dereference in dpm sysfs handlers</title>
<updated>2020-07-29T08:19:59+00:00</updated>
<author>
<name>Paweł Gronowski</name>
<email>me@woland.xyz</email>
</author>
<published>2020-07-19T15:54:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=f69137b000ffcfc726e8f3d567e0b69b34a49649'/>
<id>urn:sha1:f69137b000ffcfc726e8f3d567e0b69b34a49649</id>
<content type='text'>
commit 38e0c89a19fd13f28d2b4721035160a3e66e270b upstream.

NULL dereference occurs when string that is not ended with space or
newline is written to some dpm sysfs interface (for example pp_dpm_sclk).
This happens because strsep replaces the tmp with NULL if the delimiter
is not present in string, which is then dereferenced by tmp[0].

Reproduction example:
sudo sh -c 'echo -n 1 &gt; /sys/class/drm/card0/device/pp_dpm_sclk'

Signed-off-by: Paweł Gronowski &lt;me@woland.xyz&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mmc: sdhci-of-aspeed: Fix clock divider calculation</title>
<updated>2020-07-29T08:19:59+00:00</updated>
<author>
<name>Eddie James</name>
<email>eajames@linux.ibm.com</email>
</author>
<published>2020-07-09T19:57:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=04e469ed6c5ed4f2f8d0aa7e1fcb91360a33c907'/>
<id>urn:sha1:04e469ed6c5ed4f2f8d0aa7e1fcb91360a33c907</id>
<content type='text'>
commit ebd4050c6144b38098d8eed34df461e5e3fa82a9 upstream.

When calculating the clock divider, start dividing at 2 instead of 1.
The divider is divided by two at the end of the calculation, so starting
at 1 may result in a divider of 0, which shouldn't happen.

Signed-off-by: Eddie James &lt;eajames@linux.ibm.com&gt;
Reviewed-by: Andrew Jeffery &lt;andrew@aj.id.au&gt;
Acked-by: Joel Stanley &lt;joel@jms.id.au&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Link: https://lore.kernel.org/r/20200709195706.12741-3-eajames@linux.ibm.com
Cc: stable@vger.kernel.org # v5.4+
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>vt: Reject zero-sized screen buffer size.</title>
<updated>2020-07-29T08:19:57+00:00</updated>
<author>
<name>Tetsuo Handa</name>
<email>penguin-kernel@I-love.SAKURA.ne.jp</email>
</author>
<published>2020-07-12T11:10:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=02abdb610a09f8bac8251fff5f9cd5d39eb35b12'/>
<id>urn:sha1:02abdb610a09f8bac8251fff5f9cd5d39eb35b12</id>
<content type='text'>
commit ce684552a266cb1c7cc2f7e623f38567adec6653 upstream.

syzbot is reporting general protection fault in do_con_write() [1] caused
by vc-&gt;vc_screenbuf == ZERO_SIZE_PTR caused by vc-&gt;vc_screenbuf_size == 0
caused by vc-&gt;vc_cols == vc-&gt;vc_rows == vc-&gt;vc_size_row == 0 caused by
fb_set_var() from ioctl(FBIOPUT_VSCREENINFO) on /dev/fb0 , for
gotoxy(vc, 0, 0) from reset_terminal() from vc_init() from vc_allocate()
 from con_install() from tty_init_dev() from tty_open() on such console
causes vc-&gt;vc_pos == 0x10000000e due to
((unsigned long) ZERO_SIZE_PTR) + -1U * 0 + (-1U &lt;&lt; 1).

I don't think that a console with 0 column or 0 row makes sense. And it
seems that vc_do_resize() does not intend to allow resizing a console to
0 column or 0 row due to

  new_cols = (cols ? cols : vc-&gt;vc_cols);
  new_rows = (lines ? lines : vc-&gt;vc_rows);

exception.

Theoretically, cols and rows can be any range as long as
0 &lt; cols * rows * 2 &lt;= KMALLOC_MAX_SIZE is satisfied (e.g.
cols == 1048576 &amp;&amp; rows == 2 is possible) because of

  vc-&gt;vc_size_row = vc-&gt;vc_cols &lt;&lt; 1;
  vc-&gt;vc_screenbuf_size = vc-&gt;vc_rows * vc-&gt;vc_size_row;

in visual_init() and kzalloc(vc-&gt;vc_screenbuf_size) in vc_allocate().

Since we can detect cols == 0 or rows == 0 via screenbuf_size = 0 in
visual_init(), we can reject kzalloc(0). Then, vc_allocate() will return
an error, and con_write() will not be called on a console with 0 column
or 0 row.

We need to make sure that integer overflow in visual_init() won't happen.
Since vc_do_resize() restricts cols &lt;= 32767 and rows &lt;= 32767, applying
1 &lt;= cols &lt;= 32767 and 1 &lt;= rows &lt;= 32767 restrictions to vc_allocate()
will be practically fine.

This patch does not touch con_init(), for returning -EINVAL there
does not help when we are not returning -ENOMEM.

[1] https://syzkaller.appspot.com/bug?extid=017265e8553724e514e8

Reported-and-tested-by: syzbot &lt;syzbot+017265e8553724e514e8@syzkaller.appspotmail.com&gt;
Signed-off-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Link: https://lore.kernel.org/r/20200712111013.11881-1-penguin-kernel@I-love.SAKURA.ne.jp
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
