* [PATCH 5.3 01/21] USB: usbcore: Fix slab-out-of-bounds bug during device reset
2019-09-19 22:03 [PATCH 5.3 00/21] 5.3.1-stable review Greg Kroah-Hartman
@ 2019-09-19 22:03 ` Greg Kroah-Hartman
2019-09-19 22:03 ` [PATCH 5.3 02/21] media: tm6000: double free if usb disconnect while streaming Greg Kroah-Hartman
` (23 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-19 22:03 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alan Stern, syzbot+35f4d916c623118d576e
From: Alan Stern <stern@rowland.harvard.edu>
commit 3dd550a2d36596a1b0ee7955da3b611c031d3873 upstream.
The syzbot fuzzer provoked a slab-out-of-bounds error in the USB core:
BUG: KASAN: slab-out-of-bounds in memcmp+0xa6/0xb0 lib/string.c:904
Read of size 1 at addr ffff8881d175bed6 by task kworker/0:3/2746
CPU: 0 PID: 2746 Comm: kworker/0:3 Not tainted 5.3.0-rc5+ #28
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xca/0x13e lib/dump_stack.c:113
print_address_description+0x6a/0x32c mm/kasan/report.c:351
__kasan_report.cold+0x1a/0x33 mm/kasan/report.c:482
kasan_report+0xe/0x12 mm/kasan/common.c:612
memcmp+0xa6/0xb0 lib/string.c:904
memcmp include/linux/string.h:400 [inline]
descriptors_changed drivers/usb/core/hub.c:5579 [inline]
usb_reset_and_verify_device+0x564/0x1300 drivers/usb/core/hub.c:5729
usb_reset_device+0x4c1/0x920 drivers/usb/core/hub.c:5898
rt2x00usb_probe+0x53/0x7af
drivers/net/wireless/ralink/rt2x00/rt2x00usb.c:806
The error occurs when the descriptors_changed() routine (called during
a device reset) attempts to compare the old and new BOS and capability
descriptors. The length it uses for the comparison is the
wTotalLength value stored in BOS descriptor, but this value is not
necessarily the same as the length actually allocated for the
descriptors. If it is larger the routine will call memcmp() with a
length that is too big, thus reading beyond the end of the allocated
region and leading to this fault.
The kernel reads the BOS descriptor twice: first to get the total
length of all the capability descriptors, and second to read it along
with all those other descriptors. A malicious (or very faulty) device
may send different values for the BOS descriptor fields each time.
The memory area will be allocated using the wTotalLength value read
the first time, but stored within it will be the value read the second
time.
To prevent this possibility from causing any errors, this patch
modifies the BOS descriptor after it has been read the second time:
It sets the wTotalLength field to the actual length of the descriptors
that were read in and validated. Then the memcpy() call, or any other
code using these descriptors, will be able to rely on wTotalLength
being valid.
Reported-and-tested-by: syzbot+35f4d916c623118d576e@syzkaller.appspotmail.com
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.1909041154260.1722-100000@iolanthe.rowland.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/core/config.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -921,7 +921,7 @@ int usb_get_bos_descriptor(struct usb_de
struct usb_bos_descriptor *bos;
struct usb_dev_cap_header *cap;
struct usb_ssp_cap_descriptor *ssp_cap;
- unsigned char *buffer;
+ unsigned char *buffer, *buffer0;
int length, total_len, num, i, ssac;
__u8 cap_type;
int ret;
@@ -966,10 +966,12 @@ int usb_get_bos_descriptor(struct usb_de
ret = -ENOMSG;
goto err;
}
+
+ buffer0 = buffer;
total_len -= length;
+ buffer += length;
for (i = 0; i < num; i++) {
- buffer += length;
cap = (struct usb_dev_cap_header *)buffer;
if (total_len < sizeof(*cap) || total_len < cap->bLength) {
@@ -983,8 +985,6 @@ int usb_get_bos_descriptor(struct usb_de
break;
}
- total_len -= length;
-
if (cap->bDescriptorType != USB_DT_DEVICE_CAPABILITY) {
dev_warn(ddev, "descriptor type invalid, skip\n");
continue;
@@ -1019,7 +1019,11 @@ int usb_get_bos_descriptor(struct usb_de
default:
break;
}
+
+ total_len -= length;
+ buffer += length;
}
+ dev->bos->desc->wTotalLength = cpu_to_le16(buffer - buffer0);
return 0;
^ permalink raw reply [flat|nested] 33+ messages in thread* [PATCH 5.3 02/21] media: tm6000: double free if usb disconnect while streaming
2019-09-19 22:03 [PATCH 5.3 00/21] 5.3.1-stable review Greg Kroah-Hartman
2019-09-19 22:03 ` [PATCH 5.3 01/21] USB: usbcore: Fix slab-out-of-bounds bug during device reset Greg Kroah-Hartman
@ 2019-09-19 22:03 ` Greg Kroah-Hartman
2019-09-19 22:03 ` [PATCH 5.3 03/21] phy: renesas: rcar-gen3-usb2: Disable clearing VBUS in over-current Greg Kroah-Hartman
` (22 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-19 22:03 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sean Young, Mauro Carvalho Chehab
From: Sean Young <sean@mess.org>
commit 699bf94114151aae4dceb2d9dbf1a6312839dcae upstream.
The usb_bulk_urb will kfree'd on disconnect, so ensure the pointer is set
to NULL after each free.
stop stream
urb killing
urb buffer free
tm6000: got start feed request tm6000_start_feed
tm6000: got start stream request tm6000_start_stream
tm6000: pipe reset
tm6000: got start feed request tm6000_start_feed
tm6000: got start feed request tm6000_start_feed
tm6000: got start feed request tm6000_start_feed
tm6000: got start feed request tm6000_start_feed
tm6000: IR URB failure: status: -71, length 0
xhci_hcd 0000:00:14.0: ERROR unknown event type 37
xhci_hcd 0000:00:14.0: ERROR unknown event type 37
tm6000: error tm6000_urb_received
usb 1-2: USB disconnect, device number 5
tm6000: disconnecting tm6000 #0
==================================================================
BUG: KASAN: use-after-free in dvb_fini+0x75/0x140 [tm6000_dvb]
Read of size 8 at addr ffff888241044060 by task kworker/2:0/22
CPU: 2 PID: 22 Comm: kworker/2:0 Tainted: G W 5.3.0-rc4+ #1
Hardware name: LENOVO 20KHCTO1WW/20KHCTO1WW, BIOS N23ET65W (1.40 ) 07/02/2019
Workqueue: usb_hub_wq hub_event
Call Trace:
dump_stack+0x9a/0xf0
print_address_description.cold+0xae/0x34f
__kasan_report.cold+0x75/0x93
? tm6000_fillbuf+0x390/0x3c0 [tm6000_alsa]
? dvb_fini+0x75/0x140 [tm6000_dvb]
kasan_report+0xe/0x12
dvb_fini+0x75/0x140 [tm6000_dvb]
tm6000_close_extension+0x51/0x80 [tm6000]
tm6000_usb_disconnect.cold+0xd4/0x105 [tm6000]
usb_unbind_interface+0xe4/0x390
device_release_driver_internal+0x121/0x250
bus_remove_device+0x197/0x260
device_del+0x268/0x550
? __device_links_no_driver+0xd0/0xd0
? usb_remove_ep_devs+0x30/0x3b
usb_disable_device+0x122/0x400
usb_disconnect+0x153/0x430
hub_event+0x800/0x1e40
? trace_hardirqs_on_thunk+0x1a/0x20
? hub_port_debounce+0x1f0/0x1f0
? retint_kernel+0x10/0x10
? lock_is_held_type+0xf1/0x130
? hub_port_debounce+0x1f0/0x1f0
? process_one_work+0x4ae/0xa00
process_one_work+0x4ba/0xa00
? pwq_dec_nr_in_flight+0x160/0x160
? do_raw_spin_lock+0x10a/0x1d0
worker_thread+0x7a/0x5c0
? process_one_work+0xa00/0xa00
kthread+0x1d5/0x200
? kthread_create_worker_on_cpu+0xd0/0xd0
ret_from_fork+0x3a/0x50
Allocated by task 2682:
save_stack+0x1b/0x80
__kasan_kmalloc.constprop.0+0xc2/0xd0
usb_alloc_urb+0x28/0x60
tm6000_start_feed+0x10a/0x300 [tm6000_dvb]
dmx_ts_feed_start_filtering+0x86/0x120 [dvb_core]
dvb_dmxdev_start_feed+0x121/0x180 [dvb_core]
dvb_dmxdev_filter_start+0xcb/0x540 [dvb_core]
dvb_demux_do_ioctl+0x7ed/0x890 [dvb_core]
dvb_usercopy+0x97/0x1f0 [dvb_core]
dvb_demux_ioctl+0x11/0x20 [dvb_core]
do_vfs_ioctl+0x5d8/0x9d0
ksys_ioctl+0x5e/0x90
__x64_sys_ioctl+0x3d/0x50
do_syscall_64+0x74/0xe0
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 22:
save_stack+0x1b/0x80
__kasan_slab_free+0x12c/0x170
kfree+0xfd/0x3a0
xhci_giveback_urb_in_irq+0xfe/0x230
xhci_td_cleanup+0x276/0x340
xhci_irq+0x1129/0x3720
__handle_irq_event_percpu+0x6e/0x420
handle_irq_event_percpu+0x6f/0x100
handle_irq_event+0x55/0x84
handle_edge_irq+0x108/0x3b0
handle_irq+0x2e/0x40
do_IRQ+0x83/0x1a0
Cc: stable@vger.kernel.org
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/usb/tm6000/tm6000-dvb.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/media/usb/tm6000/tm6000-dvb.c
+++ b/drivers/media/usb/tm6000/tm6000-dvb.c
@@ -97,6 +97,7 @@ static void tm6000_urb_received(struct u
printk(KERN_ERR "tm6000: error %s\n", __func__);
kfree(urb->transfer_buffer);
usb_free_urb(urb);
+ dev->dvb->bulk_urb = NULL;
}
}
}
@@ -127,6 +128,7 @@ static int tm6000_start_stream(struct tm
dvb->bulk_urb->transfer_buffer = kzalloc(size, GFP_KERNEL);
if (!dvb->bulk_urb->transfer_buffer) {
usb_free_urb(dvb->bulk_urb);
+ dvb->bulk_urb = NULL;
return -ENOMEM;
}
@@ -153,6 +155,7 @@ static int tm6000_start_stream(struct tm
kfree(dvb->bulk_urb->transfer_buffer);
usb_free_urb(dvb->bulk_urb);
+ dvb->bulk_urb = NULL;
return ret;
}
^ permalink raw reply [flat|nested] 33+ messages in thread* [PATCH 5.3 03/21] phy: renesas: rcar-gen3-usb2: Disable clearing VBUS in over-current
2019-09-19 22:03 [PATCH 5.3 00/21] 5.3.1-stable review Greg Kroah-Hartman
2019-09-19 22:03 ` [PATCH 5.3 01/21] USB: usbcore: Fix slab-out-of-bounds bug during device reset Greg Kroah-Hartman
2019-09-19 22:03 ` [PATCH 5.3 02/21] media: tm6000: double free if usb disconnect while streaming Greg Kroah-Hartman
@ 2019-09-19 22:03 ` Greg Kroah-Hartman
2019-09-19 22:03 ` [PATCH 5.3 04/21] ip6_gre: fix a dst leak in ip6erspan_tunnel_xmit Greg Kroah-Hartman
` (21 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-19 22:03 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Yoshihiro Shimoda, Kishon Vijay Abraham I
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
commit e6839c31a608e79f2057fab987dd814f5d3477e6 upstream.
The hardware manual should be revised, but the initial value of
VBCTRL.OCCLREN is set to 1 actually. If the bit is set, the hardware
clears VBCTRL.VBOUT and ADPCTRL.DRVVBUS registers automatically
when the hardware detects over-current signal from a USB power switch.
However, since the hardware doesn't have any registers which
indicates over-current, the driver cannot handle it at all. So, if
"is_otg_channel" hardware detects over-current, since ADPCTRL.DRVVBUS
register is cleared automatically, the channel cannot be used after
that.
To resolve this behavior, this patch sets the VBCTRL.OCCLREN to 0
to keep ADPCTRL.DRVVBUS even if the "is_otg_channel" hardware
detects over-current. (We assume a USB power switch itself protects
over-current and turns the VBUS off.)
This patch is inspired by a BSP patch from Kazuya Mizuguchi.
Fixes: 1114e2d31731 ("phy: rcar-gen3-usb2: change the mode to OTG on the combined channel")
Cc: <stable@vger.kernel.org> # v4.5+
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/phy/renesas/phy-rcar-gen3-usb2.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
@@ -61,6 +61,7 @@
USB2_OBINT_IDDIGCHG)
/* VBCTRL */
+#define USB2_VBCTRL_OCCLREN BIT(16)
#define USB2_VBCTRL_DRVVBUSSEL BIT(8)
/* LINECTRL1 */
@@ -374,6 +375,7 @@ static void rcar_gen3_init_otg(struct rc
writel(val, usb2_base + USB2_LINECTRL1);
val = readl(usb2_base + USB2_VBCTRL);
+ val &= ~USB2_VBCTRL_OCCLREN;
writel(val | USB2_VBCTRL_DRVVBUSSEL, usb2_base + USB2_VBCTRL);
val = readl(usb2_base + USB2_ADPCTRL);
writel(val | USB2_ADPCTRL_IDPULLUP, usb2_base + USB2_ADPCTRL);
^ permalink raw reply [flat|nested] 33+ messages in thread* [PATCH 5.3 04/21] ip6_gre: fix a dst leak in ip6erspan_tunnel_xmit
2019-09-19 22:03 [PATCH 5.3 00/21] 5.3.1-stable review Greg Kroah-Hartman
` (2 preceding siblings ...)
2019-09-19 22:03 ` [PATCH 5.3 03/21] phy: renesas: rcar-gen3-usb2: Disable clearing VBUS in over-current Greg Kroah-Hartman
@ 2019-09-19 22:03 ` Greg Kroah-Hartman
2019-09-19 22:03 ` [PATCH 5.3 05/21] net/sched: fix race between deactivation and dequeue for NOLOCK qdisc Greg Kroah-Hartman
` (20 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-19 22:03 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Xin Long, William Tu, David S. Miller
From: Xin Long <lucien.xin@gmail.com>
[ Upstream commit 28e486037747c2180470b77c290d4090ad42f259 ]
In ip6erspan_tunnel_xmit(), if the skb will not be sent out, it has to
be freed on the tx_err path. Otherwise when deleting a netns, it would
cause dst/dev to leak, and dmesg shows:
unregister_netdevice: waiting for lo to become free. Usage count = 1
Fixes: ef7baf5e083c ("ip6_gre: add ip6 erspan collect_md mode")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: William Tu <u9012063@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv6/ip6_gre.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -968,7 +968,7 @@ static netdev_tx_t ip6erspan_tunnel_xmit
if (unlikely(!tun_info ||
!(tun_info->mode & IP_TUNNEL_INFO_TX) ||
ip_tunnel_info_af(tun_info) != AF_INET6))
- return -EINVAL;
+ goto tx_err;
key = &tun_info->key;
memset(&fl6, 0, sizeof(fl6));
^ permalink raw reply [flat|nested] 33+ messages in thread* [PATCH 5.3 05/21] net/sched: fix race between deactivation and dequeue for NOLOCK qdisc
2019-09-19 22:03 [PATCH 5.3 00/21] 5.3.1-stable review Greg Kroah-Hartman
` (3 preceding siblings ...)
2019-09-19 22:03 ` [PATCH 5.3 04/21] ip6_gre: fix a dst leak in ip6erspan_tunnel_xmit Greg Kroah-Hartman
@ 2019-09-19 22:03 ` Greg Kroah-Hartman
2019-09-19 22:03 ` [PATCH 5.3 06/21] net_sched: let qdisc_put() accept NULL pointer Greg Kroah-Hartman
` (19 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-19 22:03 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Li Shuang, Paolo Abeni,
David S. Miller, Davide Caratti
From: Paolo Abeni <pabeni@redhat.com>
[ Upstream commit d518d2ed8640c1cbbbb6f63939e3e65471817367 ]
The test implemented by some_qdisc_is_busy() is somewhat loosy for
NOLOCK qdisc, as we may hit the following scenario:
CPU1 CPU2
// in net_tx_action()
clear_bit(__QDISC_STATE_SCHED...);
// in some_qdisc_is_busy()
val = (qdisc_is_running(q) ||
test_bit(__QDISC_STATE_SCHED,
&q->state));
// here val is 0 but...
qdisc_run(q)
// ... CPU1 is going to run the qdisc next
As a conseguence qdisc_run() in net_tx_action() can race with qdisc_reset()
in dev_qdisc_reset(). Such race is not possible for !NOLOCK qdisc as
both the above bit operations are under the root qdisc lock().
After commit 021a17ed796b ("pfifo_fast: drop unneeded additional lock on dequeue")
the race can cause use after free and/or null ptr dereference, but the root
cause is likely older.
This patch addresses the issue explicitly checking for deactivation under
the seqlock for NOLOCK qdisc, so that the qdisc_run() in the critical
scenario becomes a no-op.
Note that the enqueue() op can still execute concurrently with dev_qdisc_reset(),
but that is safe due to the skb_array() locking, and we can't avoid that
for NOLOCK qdiscs.
Fixes: 021a17ed796b ("pfifo_fast: drop unneeded additional lock on dequeue")
Reported-by: Li Shuang <shuali@redhat.com>
Reported-and-tested-by: Davide Caratti <dcaratti@redhat.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/net/pkt_sched.h | 7 ++++++-
net/core/dev.c | 16 ++++++++++------
2 files changed, 16 insertions(+), 7 deletions(-)
--- a/include/net/pkt_sched.h
+++ b/include/net/pkt_sched.h
@@ -118,7 +118,12 @@ void __qdisc_run(struct Qdisc *q);
static inline void qdisc_run(struct Qdisc *q)
{
if (qdisc_run_begin(q)) {
- __qdisc_run(q);
+ /* NOLOCK qdisc must check 'state' under the qdisc seqlock
+ * to avoid racing with dev_qdisc_reset()
+ */
+ if (!(q->flags & TCQ_F_NOLOCK) ||
+ likely(!test_bit(__QDISC_STATE_DEACTIVATED, &q->state)))
+ __qdisc_run(q);
qdisc_run_end(q);
}
}
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3467,18 +3467,22 @@ static inline int __dev_xmit_skb(struct
qdisc_calculate_pkt_len(skb, q);
if (q->flags & TCQ_F_NOLOCK) {
- if (unlikely(test_bit(__QDISC_STATE_DEACTIVATED, &q->state))) {
- __qdisc_drop(skb, &to_free);
- rc = NET_XMIT_DROP;
- } else if ((q->flags & TCQ_F_CAN_BYPASS) && q->empty &&
- qdisc_run_begin(q)) {
+ if ((q->flags & TCQ_F_CAN_BYPASS) && q->empty &&
+ qdisc_run_begin(q)) {
+ if (unlikely(test_bit(__QDISC_STATE_DEACTIVATED,
+ &q->state))) {
+ __qdisc_drop(skb, &to_free);
+ rc = NET_XMIT_DROP;
+ goto end_run;
+ }
qdisc_bstats_cpu_update(q, skb);
+ rc = NET_XMIT_SUCCESS;
if (sch_direct_xmit(skb, q, dev, txq, NULL, true))
__qdisc_run(q);
+end_run:
qdisc_run_end(q);
- rc = NET_XMIT_SUCCESS;
} else {
rc = q->enqueue(skb, q, &to_free) & NET_XMIT_MASK;
qdisc_run(q);
^ permalink raw reply [flat|nested] 33+ messages in thread* [PATCH 5.3 06/21] net_sched: let qdisc_put() accept NULL pointer
2019-09-19 22:03 [PATCH 5.3 00/21] 5.3.1-stable review Greg Kroah-Hartman
` (4 preceding siblings ...)
2019-09-19 22:03 ` [PATCH 5.3 05/21] net/sched: fix race between deactivation and dequeue for NOLOCK qdisc Greg Kroah-Hartman
@ 2019-09-19 22:03 ` Greg Kroah-Hartman
2019-09-19 22:03 ` [PATCH 5.3 07/21] udp: correct reuseport selection with connected sockets Greg Kroah-Hartman
` (18 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-19 22:03 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, syzbot+d5870a903591faaca4ae,
Linus Torvalds, Jamal Hadi Salim, Jiri Pirko, Cong Wang,
Jiri Pirko, David S. Miller
From: Cong Wang <xiyou.wangcong@gmail.com>
[ Upstream commit 6efb971ba8edfbd80b666f29de12882852f095ae ]
When tcf_block_get() fails in sfb_init(), q->qdisc is still a NULL
pointer which leads to a crash in sfb_destroy(). Similar for
sch_dsmark.
Instead of fixing each separately, Linus suggested to just accept
NULL pointer in qdisc_put(), which would make callers easier.
(For sch_dsmark, the bug probably exists long before commit
6529eaba33f0.)
Fixes: 6529eaba33f0 ("net: sched: introduce tcf block infractructure")
Reported-by: syzbot+d5870a903591faaca4ae@syzkaller.appspotmail.com
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/sched/sch_generic.c | 3 +++
1 file changed, 3 insertions(+)
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -985,6 +985,9 @@ static void qdisc_destroy(struct Qdisc *
void qdisc_put(struct Qdisc *qdisc)
{
+ if (!qdisc)
+ return;
+
if (qdisc->flags & TCQ_F_BUILTIN ||
!refcount_dec_and_test(&qdisc->refcnt))
return;
^ permalink raw reply [flat|nested] 33+ messages in thread* [PATCH 5.3 07/21] udp: correct reuseport selection with connected sockets
2019-09-19 22:03 [PATCH 5.3 00/21] 5.3.1-stable review Greg Kroah-Hartman
` (5 preceding siblings ...)
2019-09-19 22:03 ` [PATCH 5.3 06/21] net_sched: let qdisc_put() accept NULL pointer Greg Kroah-Hartman
@ 2019-09-19 22:03 ` Greg Kroah-Hartman
2019-09-19 22:03 ` [PATCH 5.3 08/21] xen-netfront: do not assume sk_buff_head list is empty in error handling Greg Kroah-Hartman
` (17 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-19 22:03 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Willem de Bruijn, Paolo Abeni,
Craig Gallek, David S. Miller
From: Willem de Bruijn <willemb@google.com>
[ Upstream commit acdcecc61285faed359f1a3568c32089cc3a8329 ]
UDP reuseport groups can hold a mix unconnected and connected sockets.
Ensure that connections only receive all traffic to their 4-tuple.
Fast reuseport returns on the first reuseport match on the assumption
that all matches are equal. Only if connections are present, return to
the previous behavior of scoring all sockets.
Record if connections are present and if so (1) treat such connected
sockets as an independent match from the group, (2) only return
2-tuple matches from reuseport and (3) do not return on the first
2-tuple reuseport match to allow for a higher scoring match later.
New field has_conns is set without locks. No other fields in the
bitmap are modified at runtime and the field is only ever set
unconditionally, so an RMW cannot miss a change.
Fixes: e32ea7e74727 ("soreuseport: fast reuseport UDP socket selection")
Link: http://lkml.kernel.org/r/CA+FuTSfRP09aJNYRt04SS6qj22ViiOEWaWmLAwX0psk8-PGNxw@mail.gmail.com
Signed-off-by: Willem de Bruijn <willemb@google.com>
Acked-by: Paolo Abeni <pabeni@redhat.com>
Acked-by: Craig Gallek <kraig@google.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/net/sock_reuseport.h | 20 +++++++++++++++++++-
net/core/sock_reuseport.c | 15 +++++++++++++--
net/ipv4/datagram.c | 2 ++
net/ipv4/udp.c | 5 +++--
net/ipv6/datagram.c | 2 ++
net/ipv6/udp.c | 5 +++--
6 files changed, 42 insertions(+), 7 deletions(-)
--- a/include/net/sock_reuseport.h
+++ b/include/net/sock_reuseport.h
@@ -21,7 +21,8 @@ struct sock_reuseport {
unsigned int synq_overflow_ts;
/* ID stays the same even after the size of socks[] grows. */
unsigned int reuseport_id;
- bool bind_inany;
+ unsigned int bind_inany:1;
+ unsigned int has_conns:1;
struct bpf_prog __rcu *prog; /* optional BPF sock selector */
struct sock *socks[0]; /* array of sock pointers */
};
@@ -37,6 +38,23 @@ extern struct sock *reuseport_select_soc
extern int reuseport_attach_prog(struct sock *sk, struct bpf_prog *prog);
extern int reuseport_detach_prog(struct sock *sk);
+static inline bool reuseport_has_conns(struct sock *sk, bool set)
+{
+ struct sock_reuseport *reuse;
+ bool ret = false;
+
+ rcu_read_lock();
+ reuse = rcu_dereference(sk->sk_reuseport_cb);
+ if (reuse) {
+ if (set)
+ reuse->has_conns = 1;
+ ret = reuse->has_conns;
+ }
+ rcu_read_unlock();
+
+ return ret;
+}
+
int reuseport_get_id(struct sock_reuseport *reuse);
#endif /* _SOCK_REUSEPORT_H */
--- a/net/core/sock_reuseport.c
+++ b/net/core/sock_reuseport.c
@@ -295,8 +295,19 @@ struct sock *reuseport_select_sock(struc
select_by_hash:
/* no bpf or invalid bpf result: fall back to hash usage */
- if (!sk2)
- sk2 = reuse->socks[reciprocal_scale(hash, socks)];
+ if (!sk2) {
+ int i, j;
+
+ i = j = reciprocal_scale(hash, socks);
+ while (reuse->socks[i]->sk_state == TCP_ESTABLISHED) {
+ i++;
+ if (i >= reuse->num_socks)
+ i = 0;
+ if (i == j)
+ goto out;
+ }
+ sk2 = reuse->socks[i];
+ }
}
out:
--- a/net/ipv4/datagram.c
+++ b/net/ipv4/datagram.c
@@ -15,6 +15,7 @@
#include <net/sock.h>
#include <net/route.h>
#include <net/tcp_states.h>
+#include <net/sock_reuseport.h>
int __ip4_datagram_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
{
@@ -69,6 +70,7 @@ int __ip4_datagram_connect(struct sock *
}
inet->inet_daddr = fl4->daddr;
inet->inet_dport = usin->sin_port;
+ reuseport_has_conns(sk, true);
sk->sk_state = TCP_ESTABLISHED;
sk_set_txhash(sk);
inet->inet_id = jiffies;
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -423,12 +423,13 @@ static struct sock *udp4_lib_lookup2(str
score = compute_score(sk, net, saddr, sport,
daddr, hnum, dif, sdif);
if (score > badness) {
- if (sk->sk_reuseport) {
+ if (sk->sk_reuseport &&
+ sk->sk_state != TCP_ESTABLISHED) {
hash = udp_ehashfn(net, daddr, hnum,
saddr, sport);
result = reuseport_select_sock(sk, hash, skb,
sizeof(struct udphdr));
- if (result)
+ if (result && !reuseport_has_conns(sk, false))
return result;
}
badness = score;
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -27,6 +27,7 @@
#include <net/ip6_route.h>
#include <net/tcp_states.h>
#include <net/dsfield.h>
+#include <net/sock_reuseport.h>
#include <linux/errqueue.h>
#include <linux/uaccess.h>
@@ -254,6 +255,7 @@ ipv4_connected:
goto out;
}
+ reuseport_has_conns(sk, true);
sk->sk_state = TCP_ESTABLISHED;
sk_set_txhash(sk);
out:
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -158,13 +158,14 @@ static struct sock *udp6_lib_lookup2(str
score = compute_score(sk, net, saddr, sport,
daddr, hnum, dif, sdif);
if (score > badness) {
- if (sk->sk_reuseport) {
+ if (sk->sk_reuseport &&
+ sk->sk_state != TCP_ESTABLISHED) {
hash = udp6_ehashfn(net, daddr, hnum,
saddr, sport);
result = reuseport_select_sock(sk, hash, skb,
sizeof(struct udphdr));
- if (result)
+ if (result && !reuseport_has_conns(sk, false))
return result;
}
result = sk;
^ permalink raw reply [flat|nested] 33+ messages in thread* [PATCH 5.3 08/21] xen-netfront: do not assume sk_buff_head list is empty in error handling
2019-09-19 22:03 [PATCH 5.3 00/21] 5.3.1-stable review Greg Kroah-Hartman
` (6 preceding siblings ...)
2019-09-19 22:03 ` [PATCH 5.3 07/21] udp: correct reuseport selection with connected sockets Greg Kroah-Hartman
@ 2019-09-19 22:03 ` Greg Kroah-Hartman
2019-09-19 22:03 ` [PATCH 5.3 09/21] net: dsa: Fix load order between DSA drivers and taggers Greg Kroah-Hartman
` (16 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-19 22:03 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Dongli Zhang, David S. Miller
From: Dongli Zhang <dongli.zhang@oracle.com>
[ Upstream commit 00b368502d18f790ab715e055869fd4bb7484a9b ]
When skb_shinfo(skb) is not able to cache extra fragment (that is,
skb_shinfo(skb)->nr_frags >= MAX_SKB_FRAGS), xennet_fill_frags() assumes
the sk_buff_head list is already empty. As a result, cons is increased only
by 1 and returns to error handling path in xennet_poll().
However, if the sk_buff_head list is not empty, queue->rx.rsp_cons may be
set incorrectly. That is, queue->rx.rsp_cons would point to the rx ring
buffer entries whose queue->rx_skbs[i] and queue->grant_rx_ref[i] are
already cleared to NULL. This leads to NULL pointer access in the next
iteration to process rx ring buffer entries.
Below is how xennet_poll() does error handling. All remaining entries in
tmpq are accounted to queue->rx.rsp_cons without assuming how many
outstanding skbs are remained in the list.
985 static int xennet_poll(struct napi_struct *napi, int budget)
... ...
1032 if (unlikely(xennet_set_skb_gso(skb, gso))) {
1033 __skb_queue_head(&tmpq, skb);
1034 queue->rx.rsp_cons += skb_queue_len(&tmpq);
1035 goto err;
1036 }
It is better to always have the error handling in the same way.
Fixes: ad4f15dc2c70 ("xen/netfront: don't bug in case of too many frags")
Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/xen-netfront.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -906,7 +906,7 @@ static RING_IDX xennet_fill_frags(struct
__pskb_pull_tail(skb, pull_to - skb_headlen(skb));
}
if (unlikely(skb_shinfo(skb)->nr_frags >= MAX_SKB_FRAGS)) {
- queue->rx.rsp_cons = ++cons;
+ queue->rx.rsp_cons = ++cons + skb_queue_len(list);
kfree_skb(nskb);
return ~0U;
}
^ permalink raw reply [flat|nested] 33+ messages in thread* [PATCH 5.3 09/21] net: dsa: Fix load order between DSA drivers and taggers
2019-09-19 22:03 [PATCH 5.3 00/21] 5.3.1-stable review Greg Kroah-Hartman
` (7 preceding siblings ...)
2019-09-19 22:03 ` [PATCH 5.3 08/21] xen-netfront: do not assume sk_buff_head list is empty in error handling Greg Kroah-Hartman
@ 2019-09-19 22:03 ` Greg Kroah-Hartman
2019-09-19 22:03 ` [PATCH 5.3 10/21] net: stmmac: Hold rtnl lock in suspend/resume callbacks Greg Kroah-Hartman
` (15 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-19 22:03 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Andrew Lunn, David S. Miller
From: Andrew Lunn <andrew@lunn.ch>
[ Upstream commit 23426a25e55a417dc104df08781b6eff95e65f3f ]
The DSA core, DSA taggers and DSA drivers all make use of
module_init(). Hence they get initialised at device_initcall() time.
The ordering is non-deterministic. It can be a DSA driver is bound to
a device before the needed tag driver has been initialised, resulting
in the message:
No tagger for this switch
Rather than have this be fatal, return -EPROBE_DEFER so that it is
tried again later once all the needed drivers have been loaded.
Fixes: d3b8c04988ca ("dsa: Add boilerplate helper to register DSA tag driver modules")
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/dsa/dsa2.c | 2 ++
1 file changed, 2 insertions(+)
--- a/net/dsa/dsa2.c
+++ b/net/dsa/dsa2.c
@@ -623,6 +623,8 @@ static int dsa_port_parse_cpu(struct dsa
tag_protocol = ds->ops->get_tag_protocol(ds, dp->index);
tag_ops = dsa_tag_driver_get(tag_protocol);
if (IS_ERR(tag_ops)) {
+ if (PTR_ERR(tag_ops) == -ENOPROTOOPT)
+ return -EPROBE_DEFER;
dev_warn(ds->dev, "No tagger for this switch\n");
return PTR_ERR(tag_ops);
}
^ permalink raw reply [flat|nested] 33+ messages in thread* [PATCH 5.3 10/21] net: stmmac: Hold rtnl lock in suspend/resume callbacks
2019-09-19 22:03 [PATCH 5.3 00/21] 5.3.1-stable review Greg Kroah-Hartman
` (8 preceding siblings ...)
2019-09-19 22:03 ` [PATCH 5.3 09/21] net: dsa: Fix load order between DSA drivers and taggers Greg Kroah-Hartman
@ 2019-09-19 22:03 ` Greg Kroah-Hartman
2019-09-19 22:03 ` [PATCH 5.3 11/21] KVM: coalesced_mmio: add bounds checking Greg Kroah-Hartman
` (14 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-19 22:03 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Christophe ROULLIER, Jose Abreu,
David S. Miller
From: Jose Abreu <Jose.Abreu@synopsys.com>
[ Upstream commit 19e13cb27b998ff49f07e399b5871bfe5ba7e3f0 ]
We need to hold rnl lock in suspend and resume callbacks because phylink
requires it. Otherwise we will get a WARN() in suspend and resume.
Also, move phylink start and stop callbacks to inside device's internal
lock so that we prevent concurrent HW accesses.
Fixes: 74371272f97f ("net: stmmac: Convert to phylink and remove phylib logic")
Reported-by: Christophe ROULLIER <christophe.roullier@st.com>
Tested-by: Christophe ROULLIER <christophe.roullier@st.com>
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4451,10 +4451,12 @@ int stmmac_suspend(struct device *dev)
if (!ndev || !netif_running(ndev))
return 0;
- phylink_stop(priv->phylink);
-
mutex_lock(&priv->lock);
+ rtnl_lock();
+ phylink_stop(priv->phylink);
+ rtnl_unlock();
+
netif_device_detach(ndev);
stmmac_stop_all_queues(priv);
@@ -4558,9 +4560,11 @@ int stmmac_resume(struct device *dev)
stmmac_start_all_queues(priv);
- mutex_unlock(&priv->lock);
-
+ rtnl_lock();
phylink_start(priv->phylink);
+ rtnl_unlock();
+
+ mutex_unlock(&priv->lock);
return 0;
}
^ permalink raw reply [flat|nested] 33+ messages in thread* [PATCH 5.3 11/21] KVM: coalesced_mmio: add bounds checking
2019-09-19 22:03 [PATCH 5.3 00/21] 5.3.1-stable review Greg Kroah-Hartman
` (9 preceding siblings ...)
2019-09-19 22:03 ` [PATCH 5.3 10/21] net: stmmac: Hold rtnl lock in suspend/resume callbacks Greg Kroah-Hartman
@ 2019-09-19 22:03 ` Greg Kroah-Hartman
2019-09-19 22:03 ` [PATCH 5.3 12/21] Documentation: sphinx: Add missing comma to list of strings Greg Kroah-Hartman
` (13 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-19 22:03 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Matt Delco, Jim Mattson,
syzbot+983c866c3dd6efa3662a, Paolo Bonzini
From: Matt Delco <delco@chromium.org>
commit b60fe990c6b07ef6d4df67bc0530c7c90a62623a upstream.
The first/last indexes are typically shared with a user app.
The app can change the 'last' index that the kernel uses
to store the next result. This change sanity checks the index
before using it for writing to a potentially arbitrary address.
This fixes CVE-2019-14821.
Cc: stable@vger.kernel.org
Fixes: 5f94c1741bdc ("KVM: Add coalesced MMIO support (common part)")
Signed-off-by: Matt Delco <delco@chromium.org>
Signed-off-by: Jim Mattson <jmattson@google.com>
Reported-by: syzbot+983c866c3dd6efa3662a@syzkaller.appspotmail.com
[Use READ_ONCE. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
virt/kvm/coalesced_mmio.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
--- a/virt/kvm/coalesced_mmio.c
+++ b/virt/kvm/coalesced_mmio.c
@@ -40,7 +40,7 @@ static int coalesced_mmio_in_range(struc
return 1;
}
-static int coalesced_mmio_has_room(struct kvm_coalesced_mmio_dev *dev)
+static int coalesced_mmio_has_room(struct kvm_coalesced_mmio_dev *dev, u32 last)
{
struct kvm_coalesced_mmio_ring *ring;
unsigned avail;
@@ -52,7 +52,7 @@ static int coalesced_mmio_has_room(struc
* there is always one unused entry in the buffer
*/
ring = dev->kvm->coalesced_mmio_ring;
- avail = (ring->first - ring->last - 1) % KVM_COALESCED_MMIO_MAX;
+ avail = (ring->first - last - 1) % KVM_COALESCED_MMIO_MAX;
if (avail == 0) {
/* full */
return 0;
@@ -67,25 +67,28 @@ static int coalesced_mmio_write(struct k
{
struct kvm_coalesced_mmio_dev *dev = to_mmio(this);
struct kvm_coalesced_mmio_ring *ring = dev->kvm->coalesced_mmio_ring;
+ __u32 insert;
if (!coalesced_mmio_in_range(dev, addr, len))
return -EOPNOTSUPP;
spin_lock(&dev->kvm->ring_lock);
- if (!coalesced_mmio_has_room(dev)) {
+ insert = READ_ONCE(ring->last);
+ if (!coalesced_mmio_has_room(dev, insert) ||
+ insert >= KVM_COALESCED_MMIO_MAX) {
spin_unlock(&dev->kvm->ring_lock);
return -EOPNOTSUPP;
}
/* copy data in first free entry of the ring */
- ring->coalesced_mmio[ring->last].phys_addr = addr;
- ring->coalesced_mmio[ring->last].len = len;
- memcpy(ring->coalesced_mmio[ring->last].data, val, len);
- ring->coalesced_mmio[ring->last].pio = dev->zone.pio;
+ ring->coalesced_mmio[insert].phys_addr = addr;
+ ring->coalesced_mmio[insert].len = len;
+ memcpy(ring->coalesced_mmio[insert].data, val, len);
+ ring->coalesced_mmio[insert].pio = dev->zone.pio;
smp_wmb();
- ring->last = (ring->last + 1) % KVM_COALESCED_MMIO_MAX;
+ ring->last = (insert + 1) % KVM_COALESCED_MMIO_MAX;
spin_unlock(&dev->kvm->ring_lock);
return 0;
}
^ permalink raw reply [flat|nested] 33+ messages in thread* [PATCH 5.3 12/21] Documentation: sphinx: Add missing comma to list of strings
2019-09-19 22:03 [PATCH 5.3 00/21] 5.3.1-stable review Greg Kroah-Hartman
` (10 preceding siblings ...)
2019-09-19 22:03 ` [PATCH 5.3 11/21] KVM: coalesced_mmio: add bounds checking Greg Kroah-Hartman
@ 2019-09-19 22:03 ` Greg Kroah-Hartman
2019-09-19 22:03 ` [PATCH 5.3 13/21] firmware: google: check if size is valid when decoding VPD data Greg Kroah-Hartman
` (12 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-19 22:03 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jonathan Neuschäfer,
Mauro Carvalho Chehab, Jonathan Corbet
From: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
commit 11fec009d97e5bd2329ef7d52d71e9f6763f1048 upstream.
In Python, like in C, when a comma is omitted in a list of strings, the
two strings around the missing comma are concatenated.
Cc: stable@vger.kernel.org # v5.2 only
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Documentation/sphinx/automarkup.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/Documentation/sphinx/automarkup.py
+++ b/Documentation/sphinx/automarkup.py
@@ -25,7 +25,7 @@ RE_function = re.compile(r'([\w_][\w\d_]
# to the creation of incorrect and confusing cross references. So
# just don't even try with these names.
#
-Skipfuncs = [ 'open', 'close', 'read', 'write', 'fcntl', 'mmap'
+Skipfuncs = [ 'open', 'close', 'read', 'write', 'fcntl', 'mmap',
'select', 'poll', 'fork', 'execve', 'clone', 'ioctl']
#
^ permalink raw reply [flat|nested] 33+ messages in thread* [PATCH 5.3 13/21] firmware: google: check if size is valid when decoding VPD data
2019-09-19 22:03 [PATCH 5.3 00/21] 5.3.1-stable review Greg Kroah-Hartman
` (11 preceding siblings ...)
2019-09-19 22:03 ` [PATCH 5.3 12/21] Documentation: sphinx: Add missing comma to list of strings Greg Kroah-Hartman
@ 2019-09-19 22:03 ` Greg Kroah-Hartman
2019-09-19 22:03 ` [PATCH 5.3 14/21] serial: sprd: correct the wrong sequence of arguments Greg Kroah-Hartman
` (11 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-19 22:03 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hung-Te Lin, Guenter Roeck, Stephen Boyd
From: Hung-Te Lin <hungte@chromium.org>
commit 4b708b7b1a2c09fbdfff6b942ebe3a160213aacd upstream.
The VPD implementation from Chromium Vital Product Data project used to
parse data from untrusted input without checking if the meta data is
invalid or corrupted. For example, the size from decoded content may
be negative value, or larger than whole input buffer. Such invalid data
may cause buffer overflow.
To fix that, the size parameters passed to vpd_decode functions should
be changed to unsigned integer (u32) type, and the parsing of entry
header should be refactored so every size field is correctly verified
before starting to decode.
Fixes: ad2ac9d5c5e0 ("firmware: Google VPD: import lib_vpd source files")
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20190830022402.214442-1-hungte@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/firmware/google/vpd.c | 4 +-
drivers/firmware/google/vpd_decode.c | 55 ++++++++++++++++++++---------------
drivers/firmware/google/vpd_decode.h | 6 +--
3 files changed, 37 insertions(+), 28 deletions(-)
--- a/drivers/firmware/google/vpd.c
+++ b/drivers/firmware/google/vpd.c
@@ -92,8 +92,8 @@ static int vpd_section_check_key_name(co
return VPD_OK;
}
-static int vpd_section_attrib_add(const u8 *key, s32 key_len,
- const u8 *value, s32 value_len,
+static int vpd_section_attrib_add(const u8 *key, u32 key_len,
+ const u8 *value, u32 value_len,
void *arg)
{
int ret;
--- a/drivers/firmware/google/vpd_decode.c
+++ b/drivers/firmware/google/vpd_decode.c
@@ -9,8 +9,8 @@
#include "vpd_decode.h"
-static int vpd_decode_len(const s32 max_len, const u8 *in,
- s32 *length, s32 *decoded_len)
+static int vpd_decode_len(const u32 max_len, const u8 *in,
+ u32 *length, u32 *decoded_len)
{
u8 more;
int i = 0;
@@ -30,18 +30,39 @@ static int vpd_decode_len(const s32 max_
} while (more);
*decoded_len = i;
+ return VPD_OK;
+}
+
+static int vpd_decode_entry(const u32 max_len, const u8 *input_buf,
+ u32 *_consumed, const u8 **entry, u32 *entry_len)
+{
+ u32 decoded_len;
+ u32 consumed = *_consumed;
+ if (vpd_decode_len(max_len - consumed, &input_buf[consumed],
+ entry_len, &decoded_len) != VPD_OK)
+ return VPD_FAIL;
+ if (max_len - consumed < decoded_len)
+ return VPD_FAIL;
+
+ consumed += decoded_len;
+ *entry = input_buf + consumed;
+
+ /* entry_len is untrusted data and must be checked again. */
+ if (max_len - consumed < *entry_len)
+ return VPD_FAIL;
+
+ consumed += decoded_len;
+ *_consumed = consumed;
return VPD_OK;
}
-int vpd_decode_string(const s32 max_len, const u8 *input_buf, s32 *consumed,
+int vpd_decode_string(const u32 max_len, const u8 *input_buf, u32 *consumed,
vpd_decode_callback callback, void *callback_arg)
{
int type;
- int res;
- s32 key_len;
- s32 value_len;
- s32 decoded_len;
+ u32 key_len;
+ u32 value_len;
const u8 *key;
const u8 *value;
@@ -56,26 +77,14 @@ int vpd_decode_string(const s32 max_len,
case VPD_TYPE_STRING:
(*consumed)++;
- /* key */
- res = vpd_decode_len(max_len - *consumed, &input_buf[*consumed],
- &key_len, &decoded_len);
- if (res != VPD_OK || *consumed + decoded_len >= max_len)
+ if (vpd_decode_entry(max_len, input_buf, consumed, &key,
+ &key_len) != VPD_OK)
return VPD_FAIL;
- *consumed += decoded_len;
- key = &input_buf[*consumed];
- *consumed += key_len;
-
- /* value */
- res = vpd_decode_len(max_len - *consumed, &input_buf[*consumed],
- &value_len, &decoded_len);
- if (res != VPD_OK || *consumed + decoded_len > max_len)
+ if (vpd_decode_entry(max_len, input_buf, consumed, &value,
+ &value_len) != VPD_OK)
return VPD_FAIL;
- *consumed += decoded_len;
- value = &input_buf[*consumed];
- *consumed += value_len;
-
if (type == VPD_TYPE_STRING)
return callback(key, key_len, value, value_len,
callback_arg);
--- a/drivers/firmware/google/vpd_decode.h
+++ b/drivers/firmware/google/vpd_decode.h
@@ -25,8 +25,8 @@ enum {
};
/* Callback for vpd_decode_string to invoke. */
-typedef int vpd_decode_callback(const u8 *key, s32 key_len,
- const u8 *value, s32 value_len,
+typedef int vpd_decode_callback(const u8 *key, u32 key_len,
+ const u8 *value, u32 value_len,
void *arg);
/*
@@ -44,7 +44,7 @@ typedef int vpd_decode_callback(const u8
* If one entry is successfully decoded, sends it to callback and returns the
* result.
*/
-int vpd_decode_string(const s32 max_len, const u8 *input_buf, s32 *consumed,
+int vpd_decode_string(const u32 max_len, const u8 *input_buf, u32 *consumed,
vpd_decode_callback callback, void *callback_arg);
#endif /* __VPD_DECODE_H */
^ permalink raw reply [flat|nested] 33+ messages in thread* [PATCH 5.3 14/21] serial: sprd: correct the wrong sequence of arguments
2019-09-19 22:03 [PATCH 5.3 00/21] 5.3.1-stable review Greg Kroah-Hartman
` (12 preceding siblings ...)
2019-09-19 22:03 ` [PATCH 5.3 13/21] firmware: google: check if size is valid when decoding VPD data Greg Kroah-Hartman
@ 2019-09-19 22:03 ` Greg Kroah-Hartman
2019-09-19 22:03 ` [PATCH 5.3 15/21] tty/serial: atmel: reschedule TX after RX was started Greg Kroah-Hartman
` (10 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-19 22:03 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Chunyan Zhang, Chunyan Zhang
From: Chunyan Zhang <chunyan.zhang@unisoc.com>
commit 9c801e313195addaf11c16e155f50789d6ebfd19 upstream.
The sequence of arguments which was passed to handle_lsr_errors() didn't
match the parameters defined in that function, &lsr was passed to flag
and &flag was passed to lsr, this patch fixed that.
Fixes: b7396a38fb28 ("tty/serial: Add Spreadtrum sc9836-uart driver support")
Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com>
Signed-off-by: Chunyan Zhang <zhang.lyra@gmail.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20190905074151.5268-1-zhang.lyra@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/serial/sprd_serial.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/tty/serial/sprd_serial.c
+++ b/drivers/tty/serial/sprd_serial.c
@@ -609,7 +609,7 @@ static inline void sprd_rx(struct uart_p
if (lsr & (SPRD_LSR_BI | SPRD_LSR_PE |
SPRD_LSR_FE | SPRD_LSR_OE))
- if (handle_lsr_errors(port, &lsr, &flag))
+ if (handle_lsr_errors(port, &flag, &lsr))
continue;
if (uart_handle_sysrq_char(port, ch))
continue;
^ permalink raw reply [flat|nested] 33+ messages in thread* [PATCH 5.3 15/21] tty/serial: atmel: reschedule TX after RX was started
2019-09-19 22:03 [PATCH 5.3 00/21] 5.3.1-stable review Greg Kroah-Hartman
` (13 preceding siblings ...)
2019-09-19 22:03 ` [PATCH 5.3 14/21] serial: sprd: correct the wrong sequence of arguments Greg Kroah-Hartman
@ 2019-09-19 22:03 ` Greg Kroah-Hartman
2019-09-19 22:03 ` [PATCH 5.3 16/21] nl80211: Fix possible Spectre-v1 for CQM RSSI thresholds Greg Kroah-Hartman
` (9 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-19 22:03 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Razvan Stefanescu
From: Razvan Stefanescu <razvan.stefanescu@microchip.com>
commit d2ace81bf902a9f11d52e59e5d232d2255a0e353 upstream.
When half-duplex RS485 communication is used, after RX is started, TX
tasklet still needs to be scheduled tasklet. This avoids console freezing
when more data is to be transmitted, if the serial communication is not
closed.
Fixes: 69646d7a3689 ("tty/serial: atmel: RS485 HD w/DMA: enable RX after TX is stopped")
Signed-off-by: Razvan Stefanescu <razvan.stefanescu@microchip.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20190813074025.16218-1-razvan.stefanescu@microchip.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/serial/atmel_serial.c | 1 -
1 file changed, 1 deletion(-)
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -1400,7 +1400,6 @@ atmel_handle_transmit(struct uart_port *
atmel_port->hd_start_rx = false;
atmel_start_rx(port);
- return;
}
atmel_tasklet_schedule(atmel_port, &atmel_port->tasklet_tx);
^ permalink raw reply [flat|nested] 33+ messages in thread* [PATCH 5.3 16/21] nl80211: Fix possible Spectre-v1 for CQM RSSI thresholds
2019-09-19 22:03 [PATCH 5.3 00/21] 5.3.1-stable review Greg Kroah-Hartman
` (14 preceding siblings ...)
2019-09-19 22:03 ` [PATCH 5.3 15/21] tty/serial: atmel: reschedule TX after RX was started Greg Kroah-Hartman
@ 2019-09-19 22:03 ` Greg Kroah-Hartman
2019-09-19 22:03 ` [PATCH 5.3 17/21] Revert "arm64: Remove unnecessary ISBs from set_{pte,pmd,pud}" Greg Kroah-Hartman
` (8 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-19 22:03 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dan Carpenter, Masashi Honma, Johannes Berg
From: Masashi Honma <masashi.honma@gmail.com>
commit 4b2c5a14cd8005a900075f7dfec87473c6ee66fb upstream.
commit 1222a1601488 ("nl80211: Fix possible Spectre-v1 for CQM
RSSI thresholds") was incomplete and requires one more fix to
prevent accessing to rssi_thresholds[n] because user can control
rssi_thresholds[i] values to make i reach to n. For example,
rssi_thresholds = {-400, -300, -200, -100} when last is -34.
Cc: stable@vger.kernel.org
Fixes: 1222a1601488 ("nl80211: Fix possible Spectre-v1 for CQM RSSI thresholds")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
Link: https://lore.kernel.org/r/20190908005653.17433-1-masashi.honma@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/wireless/nl80211.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -10659,9 +10659,11 @@ static int cfg80211_cqm_rssi_update(stru
hyst = wdev->cqm_config->rssi_hyst;
n = wdev->cqm_config->n_rssi_thresholds;
- for (i = 0; i < n; i++)
+ for (i = 0; i < n; i++) {
+ i = array_index_nospec(i, n);
if (last < wdev->cqm_config->rssi_thresholds[i])
break;
+ }
low_index = i - 1;
if (low_index >= 0) {
^ permalink raw reply [flat|nested] 33+ messages in thread* [PATCH 5.3 17/21] Revert "arm64: Remove unnecessary ISBs from set_{pte,pmd,pud}"
2019-09-19 22:03 [PATCH 5.3 00/21] 5.3.1-stable review Greg Kroah-Hartman
` (15 preceding siblings ...)
2019-09-19 22:03 ` [PATCH 5.3 16/21] nl80211: Fix possible Spectre-v1 for CQM RSSI thresholds Greg Kroah-Hartman
@ 2019-09-19 22:03 ` Greg Kroah-Hartman
2019-09-19 22:03 ` [PATCH 5.3 18/21] ovl: fix regression caused by overlapping layers detection Greg Kroah-Hartman
` (7 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-19 22:03 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Mark Rutland, Will Deacon
From: Will Deacon <will@kernel.org>
commit d0b7a302d58abe24ed0f32a0672dd4c356bb73db upstream.
This reverts commit 24fe1b0efad4fcdd32ce46cffeab297f22581707.
Commit 24fe1b0efad4fcdd ("arm64: Remove unnecessary ISBs from
set_{pte,pmd,pud}") removed ISB instructions immediately following updates
to the page table, on the grounds that they are not required by the
architecture and a DSB alone is sufficient to ensure that subsequent data
accesses use the new translation:
DDI0487E_a, B2-128:
| ... no instruction that appears in program order after the DSB
| instruction can alter any state of the system or perform any part of
| its functionality until the DSB completes other than:
|
| * Being fetched from memory and decoded
| * Reading the general-purpose, SIMD and floating-point,
| Special-purpose, or System registers that are directly or indirectly
| read without causing side-effects.
However, the same document also states the following:
DDI0487E_a, B2-125:
| DMB and DSB instructions affect reads and writes to the memory system
| generated by Load/Store instructions and data or unified cache
| maintenance instructions being executed by the PE. Instruction fetches
| or accesses caused by a hardware translation table access are not
| explicit accesses.
which appears to claim that the DSB alone is insufficient. Unfortunately,
some CPU designers have followed the second clause above, whereas in Linux
we've been relying on the first. This means that our mapping sequence:
MOV X0, <valid pte>
STR X0, [Xptep] // Store new PTE to page table
DSB ISHST
LDR X1, [X2] // Translates using the new PTE
can actually raise a translation fault on the load instruction because the
translation can be performed speculatively before the page table update and
then marked as "faulting" by the CPU. For user PTEs, this is ok because we
can handle the spurious fault, but for kernel PTEs and intermediate table
entries this results in a panic().
Revert the offending commit to reintroduce the missing barriers.
Cc: <stable@vger.kernel.org>
Fixes: 24fe1b0efad4fcdd ("arm64: Remove unnecessary ISBs from set_{pte,pmd,pud}")
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/include/asm/pgtable.h | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -220,8 +220,10 @@ static inline void set_pte(pte_t *ptep,
* Only if the new pte is valid and kernel, otherwise TLB maintenance
* or update_mmu_cache() have the necessary barriers.
*/
- if (pte_valid_not_user(pte))
+ if (pte_valid_not_user(pte)) {
dsb(ishst);
+ isb();
+ }
}
extern void __sync_icache_dcache(pte_t pteval);
@@ -484,8 +486,10 @@ static inline void set_pmd(pmd_t *pmdp,
WRITE_ONCE(*pmdp, pmd);
- if (pmd_valid(pmd))
+ if (pmd_valid(pmd)) {
dsb(ishst);
+ isb();
+ }
}
static inline void pmd_clear(pmd_t *pmdp)
@@ -543,8 +547,10 @@ static inline void set_pud(pud_t *pudp,
WRITE_ONCE(*pudp, pud);
- if (pud_valid(pud))
+ if (pud_valid(pud)) {
dsb(ishst);
+ isb();
+ }
}
static inline void pud_clear(pud_t *pudp)
^ permalink raw reply [flat|nested] 33+ messages in thread* [PATCH 5.3 18/21] ovl: fix regression caused by overlapping layers detection
2019-09-19 22:03 [PATCH 5.3 00/21] 5.3.1-stable review Greg Kroah-Hartman
` (16 preceding siblings ...)
2019-09-19 22:03 ` [PATCH 5.3 17/21] Revert "arm64: Remove unnecessary ISBs from set_{pte,pmd,pud}" Greg Kroah-Hartman
@ 2019-09-19 22:03 ` Greg Kroah-Hartman
2019-09-19 22:03 ` [PATCH 5.3 19/21] phy: qcom-qmp: Correct ready status, again Greg Kroah-Hartman
` (6 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-19 22:03 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Amir Goldstein, Colin Walters,
Miklos Szeredi
From: Amir Goldstein <amir73il@gmail.com>
commit 0be0bfd2de9dfdd2098a9c5b14bdd8f739c9165d upstream.
Once upon a time, commit 2cac0c00a6cd ("ovl: get exclusive ownership on
upper/work dirs") in v4.13 added some sanity checks on overlayfs layers.
This change caused a docker regression. The root cause was mount leaks
by docker, which as far as I know, still exist.
To mitigate the regression, commit 85fdee1eef1a ("ovl: fix regression
caused by exclusive upper/work dir protection") in v4.14 turned the
mount errors into warnings for the default index=off configuration.
Recently, commit 146d62e5a586 ("ovl: detect overlapping layers") in
v5.2, re-introduced exclusive upper/work dir checks regardless of
index=off configuration.
This changes the status quo and mount leak related bug reports have
started to re-surface. Restore the status quo to fix the regressions.
To clarify, index=off does NOT relax overlapping layers check for this
ovelayfs mount. index=off only relaxes exclusive upper/work dir checks
with another overlayfs mount.
To cover the part of overlapping layers detection that used the
exclusive upper/work dir checks to detect overlap with self upper/work
dir, add a trap also on the work base dir.
Link: https://github.com/moby/moby/issues/34672
Link: https://lore.kernel.org/linux-fsdevel/20171006121405.GA32700@veci.piliscsaba.szeredi.hu/
Link: https://github.com/containers/libpod/issues/3540
Fixes: 146d62e5a586 ("ovl: detect overlapping layers")
Cc: <stable@vger.kernel.org> # v4.19+
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Tested-by: Colin Walters <walters@verbum.org>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Documentation/filesystems/overlayfs.txt | 2
fs/overlayfs/ovl_entry.h | 1
fs/overlayfs/super.c | 73 ++++++++++++++++++++------------
3 files changed, 49 insertions(+), 27 deletions(-)
--- a/Documentation/filesystems/overlayfs.txt
+++ b/Documentation/filesystems/overlayfs.txt
@@ -302,7 +302,7 @@ beneath or above the path of another ove
Using an upper layer path and/or a workdir path that are already used by
another overlay mount is not allowed and may fail with EBUSY. Using
-partially overlapping paths is not allowed but will not fail with EBUSY.
+partially overlapping paths is not allowed and may fail with EBUSY.
If files are accessed from two overlayfs mounts which share or overlap the
upper layer and/or workdir path the behavior of the overlay is undefined,
though it will not result in a crash or deadlock.
--- a/fs/overlayfs/ovl_entry.h
+++ b/fs/overlayfs/ovl_entry.h
@@ -66,6 +66,7 @@ struct ovl_fs {
bool workdir_locked;
/* Traps in ovl inode cache */
struct inode *upperdir_trap;
+ struct inode *workbasedir_trap;
struct inode *workdir_trap;
struct inode *indexdir_trap;
/* Inode numbers in all layers do not use the high xino_bits */
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c
@@ -212,6 +212,7 @@ static void ovl_free_fs(struct ovl_fs *o
{
unsigned i;
+ iput(ofs->workbasedir_trap);
iput(ofs->indexdir_trap);
iput(ofs->workdir_trap);
iput(ofs->upperdir_trap);
@@ -1003,6 +1004,25 @@ static int ovl_setup_trap(struct super_b
return 0;
}
+/*
+ * Determine how we treat concurrent use of upperdir/workdir based on the
+ * index feature. This is papering over mount leaks of container runtimes,
+ * for example, an old overlay mount is leaked and now its upperdir is
+ * attempted to be used as a lower layer in a new overlay mount.
+ */
+static int ovl_report_in_use(struct ovl_fs *ofs, const char *name)
+{
+ if (ofs->config.index) {
+ pr_err("overlayfs: %s is in-use as upperdir/workdir of another mount, mount with '-o index=off' to override exclusive upperdir protection.\n",
+ name);
+ return -EBUSY;
+ } else {
+ pr_warn("overlayfs: %s is in-use as upperdir/workdir of another mount, accessing files from both mounts will result in undefined behavior.\n",
+ name);
+ return 0;
+ }
+}
+
static int ovl_get_upper(struct super_block *sb, struct ovl_fs *ofs,
struct path *upperpath)
{
@@ -1040,14 +1060,12 @@ static int ovl_get_upper(struct super_bl
upper_mnt->mnt_flags &= ~(MNT_NOATIME | MNT_NODIRATIME | MNT_RELATIME);
ofs->upper_mnt = upper_mnt;
- err = -EBUSY;
if (ovl_inuse_trylock(ofs->upper_mnt->mnt_root)) {
ofs->upperdir_locked = true;
- } else if (ofs->config.index) {
- pr_err("overlayfs: upperdir is in-use by another mount, mount with '-o index=off' to override exclusive upperdir protection.\n");
- goto out;
} else {
- pr_warn("overlayfs: upperdir is in-use by another mount, accessing files from both mounts will result in undefined behavior.\n");
+ err = ovl_report_in_use(ofs, "upperdir");
+ if (err)
+ goto out;
}
err = 0;
@@ -1157,16 +1175,19 @@ static int ovl_get_workdir(struct super_
ofs->workbasedir = dget(workpath.dentry);
- err = -EBUSY;
if (ovl_inuse_trylock(ofs->workbasedir)) {
ofs->workdir_locked = true;
- } else if (ofs->config.index) {
- pr_err("overlayfs: workdir is in-use by another mount, mount with '-o index=off' to override exclusive workdir protection.\n");
- goto out;
} else {
- pr_warn("overlayfs: workdir is in-use by another mount, accessing files from both mounts will result in undefined behavior.\n");
+ err = ovl_report_in_use(ofs, "workdir");
+ if (err)
+ goto out;
}
+ err = ovl_setup_trap(sb, ofs->workbasedir, &ofs->workbasedir_trap,
+ "workdir");
+ if (err)
+ goto out;
+
err = ovl_make_workdir(sb, ofs, &workpath);
out:
@@ -1313,16 +1334,16 @@ static int ovl_get_lower_layers(struct s
if (err < 0)
goto out;
- err = -EBUSY;
- if (ovl_is_inuse(stack[i].dentry)) {
- pr_err("overlayfs: lowerdir is in-use as upperdir/workdir\n");
- goto out;
- }
-
err = ovl_setup_trap(sb, stack[i].dentry, &trap, "lowerdir");
if (err)
goto out;
+ if (ovl_is_inuse(stack[i].dentry)) {
+ err = ovl_report_in_use(ofs, "lowerdir");
+ if (err)
+ goto out;
+ }
+
mnt = clone_private_mount(&stack[i]);
err = PTR_ERR(mnt);
if (IS_ERR(mnt)) {
@@ -1469,8 +1490,8 @@ out_err:
* - another layer of this overlayfs instance
* - upper/work dir of any overlayfs instance
*/
-static int ovl_check_layer(struct super_block *sb, struct dentry *dentry,
- const char *name)
+static int ovl_check_layer(struct super_block *sb, struct ovl_fs *ofs,
+ struct dentry *dentry, const char *name)
{
struct dentry *next = dentry, *parent;
int err = 0;
@@ -1482,13 +1503,11 @@ static int ovl_check_layer(struct super_
/* Walk back ancestors to root (inclusive) looking for traps */
while (!err && parent != next) {
- if (ovl_is_inuse(parent)) {
- err = -EBUSY;
- pr_err("overlayfs: %s path overlapping in-use upperdir/workdir\n",
- name);
- } else if (ovl_lookup_trap_inode(sb, parent)) {
+ if (ovl_lookup_trap_inode(sb, parent)) {
err = -ELOOP;
pr_err("overlayfs: overlapping %s path\n", name);
+ } else if (ovl_is_inuse(parent)) {
+ err = ovl_report_in_use(ofs, name);
}
next = parent;
parent = dget_parent(next);
@@ -1509,7 +1528,8 @@ static int ovl_check_overlapping_layers(
int i, err;
if (ofs->upper_mnt) {
- err = ovl_check_layer(sb, ofs->upper_mnt->mnt_root, "upperdir");
+ err = ovl_check_layer(sb, ofs, ofs->upper_mnt->mnt_root,
+ "upperdir");
if (err)
return err;
@@ -1520,13 +1540,14 @@ static int ovl_check_overlapping_layers(
* workbasedir. In that case, we already have their traps in
* inode cache and we will catch that case on lookup.
*/
- err = ovl_check_layer(sb, ofs->workbasedir, "workdir");
+ err = ovl_check_layer(sb, ofs, ofs->workbasedir, "workdir");
if (err)
return err;
}
for (i = 0; i < ofs->numlower; i++) {
- err = ovl_check_layer(sb, ofs->lower_layers[i].mnt->mnt_root,
+ err = ovl_check_layer(sb, ofs,
+ ofs->lower_layers[i].mnt->mnt_root,
"lowerdir");
if (err)
return err;
^ permalink raw reply [flat|nested] 33+ messages in thread* [PATCH 5.3 19/21] phy: qcom-qmp: Correct ready status, again
2019-09-19 22:03 [PATCH 5.3 00/21] 5.3.1-stable review Greg Kroah-Hartman
` (17 preceding siblings ...)
2019-09-19 22:03 ` [PATCH 5.3 18/21] ovl: fix regression caused by overlapping layers detection Greg Kroah-Hartman
@ 2019-09-19 22:03 ` Greg Kroah-Hartman
2019-09-19 22:03 ` [PATCH 5.3 20/21] floppy: fix usercopy direction Greg Kroah-Hartman
` (5 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-19 22:03 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Vivek Gautam, Evan Green,
Niklas Cassel, Marc Gonzalez, Bjorn Andersson,
Kishon Vijay Abraham I
From: Bjorn Andersson <bjorn.andersson@linaro.org>
commit 14ced7e3a1ae9bed7051df3718c8c7b583854a5c upstream.
Despite extensive testing of commit 885bd765963b ("phy: qcom-qmp: Correct
READY_STATUS poll break condition") I failed to conclude that the
PHYSTATUS bit of the PCS_STATUS register used in PCIe and USB3 falls as
the PHY gets ready. Similar to the prior bug with UFS the code will
generally get past the check before the transition and thereby
"succeed".
Correct the name of the register used PCIe and USB3 PHYs, replace
mask_pcs_ready with a constant expression depending on the type of the
PHY and check for the appropriate ready state.
Cc: stable@vger.kernel.org
Cc: Vivek Gautam <vivek.gautam@codeaurora.org>
Cc: Evan Green <evgreen@chromium.org>
Cc: Niklas Cassel <niklas.cassel@linaro.org>
Reported-by: Marc Gonzalez <marc.w.gonzalez@free.fr>
Fixes: 885bd765963b ("phy: qcom-qmp: Correct READY_STATUS poll break condition")
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Tested-by: Marc Gonzalez <marc.w.gonzalez@free.fr>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 33 ++++++++++++++++-----------------
1 file changed, 16 insertions(+), 17 deletions(-)
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -35,7 +35,7 @@
#define PLL_READY_GATE_EN BIT(3)
/* QPHY_PCS_STATUS bit */
#define PHYSTATUS BIT(6)
-/* QPHY_COM_PCS_READY_STATUS bit */
+/* QPHY_PCS_READY_STATUS & QPHY_COM_PCS_READY_STATUS bit */
#define PCS_READY BIT(0)
/* QPHY_V3_DP_COM_RESET_OVRD_CTRL register bits */
@@ -115,6 +115,7 @@ enum qphy_reg_layout {
QPHY_SW_RESET,
QPHY_START_CTRL,
QPHY_PCS_READY_STATUS,
+ QPHY_PCS_STATUS,
QPHY_PCS_AUTONOMOUS_MODE_CTRL,
QPHY_PCS_LFPS_RXTERM_IRQ_CLEAR,
QPHY_PCS_LFPS_RXTERM_IRQ_STATUS,
@@ -133,7 +134,7 @@ static const unsigned int pciephy_regs_l
[QPHY_FLL_MAN_CODE] = 0xd4,
[QPHY_SW_RESET] = 0x00,
[QPHY_START_CTRL] = 0x08,
- [QPHY_PCS_READY_STATUS] = 0x174,
+ [QPHY_PCS_STATUS] = 0x174,
};
static const unsigned int usb3phy_regs_layout[] = {
@@ -144,7 +145,7 @@ static const unsigned int usb3phy_regs_l
[QPHY_FLL_MAN_CODE] = 0xd0,
[QPHY_SW_RESET] = 0x00,
[QPHY_START_CTRL] = 0x08,
- [QPHY_PCS_READY_STATUS] = 0x17c,
+ [QPHY_PCS_STATUS] = 0x17c,
[QPHY_PCS_AUTONOMOUS_MODE_CTRL] = 0x0d4,
[QPHY_PCS_LFPS_RXTERM_IRQ_CLEAR] = 0x0d8,
[QPHY_PCS_LFPS_RXTERM_IRQ_STATUS] = 0x178,
@@ -153,7 +154,7 @@ static const unsigned int usb3phy_regs_l
static const unsigned int qmp_v3_usb3phy_regs_layout[] = {
[QPHY_SW_RESET] = 0x00,
[QPHY_START_CTRL] = 0x08,
- [QPHY_PCS_READY_STATUS] = 0x174,
+ [QPHY_PCS_STATUS] = 0x174,
[QPHY_PCS_AUTONOMOUS_MODE_CTRL] = 0x0d8,
[QPHY_PCS_LFPS_RXTERM_IRQ_CLEAR] = 0x0dc,
[QPHY_PCS_LFPS_RXTERM_IRQ_STATUS] = 0x170,
@@ -911,7 +912,6 @@ struct qmp_phy_cfg {
unsigned int start_ctrl;
unsigned int pwrdn_ctrl;
- unsigned int mask_pcs_ready;
unsigned int mask_com_pcs_ready;
/* true, if PHY has a separate PHY_COM control block */
@@ -1074,7 +1074,6 @@ static const struct qmp_phy_cfg msm8996_
.start_ctrl = PCS_START | PLL_READY_GATE_EN,
.pwrdn_ctrl = SW_PWRDN | REFCLK_DRV_DSBL,
- .mask_pcs_ready = PHYSTATUS,
.mask_com_pcs_ready = PCS_READY,
.has_phy_com_ctrl = true,
@@ -1106,7 +1105,6 @@ static const struct qmp_phy_cfg msm8996_
.start_ctrl = SERDES_START | PCS_START,
.pwrdn_ctrl = SW_PWRDN,
- .mask_pcs_ready = PHYSTATUS,
};
/* list of resets */
@@ -1136,7 +1134,6 @@ static const struct qmp_phy_cfg ipq8074_
.start_ctrl = SERDES_START | PCS_START,
.pwrdn_ctrl = SW_PWRDN | REFCLK_DRV_DSBL,
- .mask_pcs_ready = PHYSTATUS,
.has_phy_com_ctrl = false,
.has_lane_rst = false,
@@ -1167,7 +1164,6 @@ static const struct qmp_phy_cfg qmp_v3_u
.start_ctrl = SERDES_START | PCS_START,
.pwrdn_ctrl = SW_PWRDN,
- .mask_pcs_ready = PHYSTATUS,
.has_pwrdn_delay = true,
.pwrdn_delay_min = POWER_DOWN_DELAY_US_MIN,
@@ -1199,7 +1195,6 @@ static const struct qmp_phy_cfg qmp_v3_u
.start_ctrl = SERDES_START | PCS_START,
.pwrdn_ctrl = SW_PWRDN,
- .mask_pcs_ready = PHYSTATUS,
.has_pwrdn_delay = true,
.pwrdn_delay_min = POWER_DOWN_DELAY_US_MIN,
@@ -1226,7 +1221,6 @@ static const struct qmp_phy_cfg sdm845_u
.start_ctrl = SERDES_START,
.pwrdn_ctrl = SW_PWRDN,
- .mask_pcs_ready = PCS_READY,
.is_dual_lane_phy = true,
.no_pcs_sw_reset = true,
@@ -1254,7 +1248,6 @@ static const struct qmp_phy_cfg msm8998_
.start_ctrl = SERDES_START | PCS_START,
.pwrdn_ctrl = SW_PWRDN | REFCLK_DRV_DSBL,
- .mask_pcs_ready = PHYSTATUS,
};
static const struct qmp_phy_cfg msm8998_usb3phy_cfg = {
@@ -1279,7 +1272,6 @@ static const struct qmp_phy_cfg msm8998_
.start_ctrl = SERDES_START | PCS_START,
.pwrdn_ctrl = SW_PWRDN,
- .mask_pcs_ready = PHYSTATUS,
.is_dual_lane_phy = true,
};
@@ -1457,7 +1449,7 @@ static int qcom_qmp_phy_enable(struct ph
void __iomem *pcs = qphy->pcs;
void __iomem *dp_com = qmp->dp_com;
void __iomem *status;
- unsigned int mask, val;
+ unsigned int mask, val, ready;
int ret;
dev_vdbg(qmp->dev, "Initializing QMP phy\n");
@@ -1545,10 +1537,17 @@ static int qcom_qmp_phy_enable(struct ph
/* start SerDes and Phy-Coding-Sublayer */
qphy_setbits(pcs, cfg->regs[QPHY_START_CTRL], cfg->start_ctrl);
- status = pcs + cfg->regs[QPHY_PCS_READY_STATUS];
- mask = cfg->mask_pcs_ready;
+ if (cfg->type == PHY_TYPE_UFS) {
+ status = pcs + cfg->regs[QPHY_PCS_READY_STATUS];
+ mask = PCS_READY;
+ ready = PCS_READY;
+ } else {
+ status = pcs + cfg->regs[QPHY_PCS_STATUS];
+ mask = PHYSTATUS;
+ ready = 0;
+ }
- ret = readl_poll_timeout(status, val, val & mask, 10,
+ ret = readl_poll_timeout(status, val, (val & mask) == ready, 10,
PHY_INIT_COMPLETE_TIMEOUT);
if (ret) {
dev_err(qmp->dev, "phy initialization timed-out\n");
^ permalink raw reply [flat|nested] 33+ messages in thread* [PATCH 5.3 20/21] floppy: fix usercopy direction
2019-09-19 22:03 [PATCH 5.3 00/21] 5.3.1-stable review Greg Kroah-Hartman
` (18 preceding siblings ...)
2019-09-19 22:03 ` [PATCH 5.3 19/21] phy: qcom-qmp: Correct ready status, again Greg Kroah-Hartman
@ 2019-09-19 22:03 ` Greg Kroah-Hartman
2019-09-19 22:03 ` [PATCH 5.3 21/21] media: technisat-usb2: break out of loop at end of buffer Greg Kroah-Hartman
` (4 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-19 22:03 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alexander Popov, Mukesh Ojha,
Jann Horn, Jens Axboe
From: Jann Horn <jannh@google.com>
commit 52f6f9d74f31078964ca1574f7bb612da7877ac8 upstream.
As sparse points out, these two copy_from_user() should actually be
copy_to_user().
Fixes: 229b53c9bf4e ("take floppy compat ioctls to sodding floppy.c")
Cc: stable@vger.kernel.org
Acked-by: Alexander Popov <alex.popov@linux.com>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/block/floppy.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/block/floppy.c
+++ b/drivers/block/floppy.c
@@ -3780,7 +3780,7 @@ static int compat_getdrvprm(int drive,
v.native_format = UDP->native_format;
mutex_unlock(&floppy_mutex);
- if (copy_from_user(arg, &v, sizeof(struct compat_floppy_drive_params)))
+ if (copy_to_user(arg, &v, sizeof(struct compat_floppy_drive_params)))
return -EFAULT;
return 0;
}
@@ -3816,7 +3816,7 @@ static int compat_getdrvstat(int drive,
v.bufblocks = UDRS->bufblocks;
mutex_unlock(&floppy_mutex);
- if (copy_from_user(arg, &v, sizeof(struct compat_floppy_drive_struct)))
+ if (copy_to_user(arg, &v, sizeof(struct compat_floppy_drive_struct)))
return -EFAULT;
return 0;
Eintr:
^ permalink raw reply [flat|nested] 33+ messages in thread* [PATCH 5.3 21/21] media: technisat-usb2: break out of loop at end of buffer
2019-09-19 22:03 [PATCH 5.3 00/21] 5.3.1-stable review Greg Kroah-Hartman
` (19 preceding siblings ...)
2019-09-19 22:03 ` [PATCH 5.3 20/21] floppy: fix usercopy direction Greg Kroah-Hartman
@ 2019-09-19 22:03 ` Greg Kroah-Hartman
2019-09-20 13:45 ` [PATCH 5.3 00/21] 5.3.1-stable review Guenter Roeck
` (3 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-19 22:03 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, syzbot+eaaaf38a95427be88f4b,
Sean Young, Kees Cook, Mauro Carvalho Chehab
From: Sean Young <sean@mess.org>
commit 0c4df39e504bf925ab666132ac3c98d6cbbe380b upstream.
Ensure we do not access the buffer beyond the end if no 0xff byte
is encountered.
Reported-by: syzbot+eaaaf38a95427be88f4b@syzkaller.appspotmail.com
Signed-off-by: Sean Young <sean@mess.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/usb/dvb-usb/technisat-usb2.c | 22 ++++++++++------------
1 file changed, 10 insertions(+), 12 deletions(-)
--- a/drivers/media/usb/dvb-usb/technisat-usb2.c
+++ b/drivers/media/usb/dvb-usb/technisat-usb2.c
@@ -608,10 +608,9 @@ static int technisat_usb2_frontend_attac
static int technisat_usb2_get_ir(struct dvb_usb_device *d)
{
struct technisat_usb2_state *state = d->priv;
- u8 *buf = state->buf;
- u8 *b;
- int ret;
struct ir_raw_event ev;
+ u8 *buf = state->buf;
+ int i, ret;
buf[0] = GET_IR_DATA_VENDOR_REQUEST;
buf[1] = 0x08;
@@ -647,26 +646,25 @@ unlock:
return 0; /* no key pressed */
/* decoding */
- b = buf+1;
#if 0
deb_rc("RC: %d ", ret);
- debug_dump(b, ret, deb_rc);
+ debug_dump(buf + 1, ret, deb_rc);
#endif
ev.pulse = 0;
- while (1) {
- ev.pulse = !ev.pulse;
- ev.duration = (*b * FIRMWARE_CLOCK_DIVISOR * FIRMWARE_CLOCK_TICK) / 1000;
- ir_raw_event_store(d->rc_dev, &ev);
-
- b++;
- if (*b == 0xff) {
+ for (i = 1; i < ARRAY_SIZE(state->buf); i++) {
+ if (buf[i] == 0xff) {
ev.pulse = 0;
ev.duration = 888888*2;
ir_raw_event_store(d->rc_dev, &ev);
break;
}
+
+ ev.pulse = !ev.pulse;
+ ev.duration = (buf[i] * FIRMWARE_CLOCK_DIVISOR *
+ FIRMWARE_CLOCK_TICK) / 1000;
+ ir_raw_event_store(d->rc_dev, &ev);
}
ir_raw_event_handle(d->rc_dev);
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: [PATCH 5.3 00/21] 5.3.1-stable review
2019-09-19 22:03 [PATCH 5.3 00/21] 5.3.1-stable review Greg Kroah-Hartman
` (20 preceding siblings ...)
2019-09-19 22:03 ` [PATCH 5.3 21/21] media: technisat-usb2: break out of loop at end of buffer Greg Kroah-Hartman
@ 2019-09-20 13:45 ` Guenter Roeck
2019-09-20 13:54 ` Jon Hunter
` (2 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: Guenter Roeck @ 2019-09-20 13:45 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, shuah, patches, ben.hutchings, lkft-triage, stable
On 9/19/19 3:03 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.3.1 release.
> There are 21 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat 21 Sep 2019 09:44:25 PM UTC.
> Anything received after that time might be too late.
>
Build results:
total: 158 pass: 158 fail: 0
Qemu test results:
total: 391 pass: 391 fail: 0
Guenter
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: [PATCH 5.3 00/21] 5.3.1-stable review
2019-09-19 22:03 [PATCH 5.3 00/21] 5.3.1-stable review Greg Kroah-Hartman
@ 2019-09-20 13:54 ` Jon Hunter
2019-09-19 22:03 ` [PATCH 5.3 02/21] media: tm6000: double free if usb disconnect while streaming Greg Kroah-Hartman
` (23 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: Jon Hunter @ 2019-09-20 13:54 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, shuah, patches, ben.hutchings,
lkft-triage, stable, linux-tegra
On 19/09/2019 23:03, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.3.1 release.
> There are 21 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat 21 Sep 2019 09:44:25 PM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.3.1-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.3.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
No new regressions* for Tegra ...
Test results for stable-v5.3:
12 builds: 12 pass, 0 fail
22 boots: 22 pass, 0 fail
38 tests: 37 pass, 1 fail
Linux version: 5.3.1-rc1-g0aa7f3d6baae
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04
* Note we had one regression in v5.3 for a warnings test for Tegra194
causing the above test failure. This has since been fixed by the
following commits [0] but given it is just a warning, I have not
bothered CC'ing for stable.
Cheers
Jon
[0] https://lkml.org/lkml/2019/8/21/602
--
nvpublic
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: [PATCH 5.3 00/21] 5.3.1-stable review
@ 2019-09-20 13:54 ` Jon Hunter
0 siblings, 0 replies; 33+ messages in thread
From: Jon Hunter @ 2019-09-20 13:54 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, shuah, patches, ben.hutchings,
lkft-triage, stable, linux-tegra
On 19/09/2019 23:03, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.3.1 release.
> There are 21 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat 21 Sep 2019 09:44:25 PM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.3.1-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.3.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
No new regressions* for Tegra ...
Test results for stable-v5.3:
12 builds: 12 pass, 0 fail
22 boots: 22 pass, 0 fail
38 tests: 37 pass, 1 fail
Linux version: 5.3.1-rc1-g0aa7f3d6baae
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04
* Note we had one regression in v5.3 for a warnings test for Tegra194
causing the above test failure. This has since been fixed by the
following commits [0] but given it is just a warning, I have not
bothered CC'ing for stable.
Cheers
Jon
[0] https://lkml.org/lkml/2019/8/21/602
--
nvpublic
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: [PATCH 5.3 00/21] 5.3.1-stable review
2019-09-20 13:54 ` Jon Hunter
(?)
@ 2019-09-20 14:24 ` Greg Kroah-Hartman
2019-09-20 16:01 ` Jon Hunter
-1 siblings, 1 reply; 33+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-20 14:24 UTC (permalink / raw)
To: Jon Hunter
Cc: linux-kernel, torvalds, akpm, linux, shuah, patches,
ben.hutchings, lkft-triage, stable, linux-tegra
On Fri, Sep 20, 2019 at 02:54:26PM +0100, Jon Hunter wrote:
>
> On 19/09/2019 23:03, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.3.1 release.
> > There are 21 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sat 21 Sep 2019 09:44:25 PM UTC.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.3.1-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.3.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> No new regressions* for Tegra ...
>
> Test results for stable-v5.3:
> 12 builds: 12 pass, 0 fail
> 22 boots: 22 pass, 0 fail
> 38 tests: 37 pass, 1 fail
>
> Linux version: 5.3.1-rc1-g0aa7f3d6baae
> Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
> tegra194-p2972-0000, tegra20-ventana,
> tegra210-p2371-2180, tegra30-cardhu-a04
>
> * Note we had one regression in v5.3 for a warnings test for Tegra194
> causing the above test failure. This has since been fixed by the
> following commits [0] but given it is just a warning, I have not
> bothered CC'ing for stable.
>
> Cheers
> Jon
>
> [0] https://lkml.org/lkml/2019/8/21/602
I'll be glad to take this in stable for 5.3.y, what is the git commit
id?
Also, thanks for testing all of these and letting me know.
greg k-h
>
> --
> nvpublic
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 5.3 00/21] 5.3.1-stable review
2019-09-20 14:24 ` Greg Kroah-Hartman
@ 2019-09-20 16:01 ` Jon Hunter
0 siblings, 0 replies; 33+ messages in thread
From: Jon Hunter @ 2019-09-20 16:01 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, linux, shuah, patches,
ben.hutchings, lkft-triage, stable, linux-tegra
On 20/09/2019 15:24, Greg Kroah-Hartman wrote:
> On Fri, Sep 20, 2019 at 02:54:26PM +0100, Jon Hunter wrote:
>>
>> On 19/09/2019 23:03, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 5.3.1 release.
>>> There are 21 patches in this series, all will be posted as a response
>>> to this one. If anyone has any issues with these being applied, please
>>> let me know.
>>>
>>> Responses should be made by Sat 21 Sep 2019 09:44:25 PM UTC.
>>> Anything received after that time might be too late.
>>>
>>> The whole patch series can be found in one patch at:
>>> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.3.1-rc1.gz
>>> or in the git tree and branch at:
>>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.3.y
>>> and the diffstat can be found below.
>>>
>>> thanks,
>>>
>>> greg k-h
>>
>> No new regressions* for Tegra ...
>>
>> Test results for stable-v5.3:
>> 12 builds: 12 pass, 0 fail
>> 22 boots: 22 pass, 0 fail
>> 38 tests: 37 pass, 1 fail
>>
>> Linux version: 5.3.1-rc1-g0aa7f3d6baae
>> Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
>> tegra194-p2972-0000, tegra20-ventana,
>> tegra210-p2371-2180, tegra30-cardhu-a04
>>
>> * Note we had one regression in v5.3 for a warnings test for Tegra194
>> causing the above test failure. This has since been fixed by the
>> following commits [0] but given it is just a warning, I have not
>> bothered CC'ing for stable.
>>
>> Cheers
>> Jon
>>
>> [0] https://lkml.org/lkml/2019/8/21/602
>
> I'll be glad to take this in stable for 5.3.y, what is the git commit
> id?
OK, that would be great. The IDs are ...
commit 763719771e84b8c8c2f53af668cdc905faa608de
Author: Jon Hunter <jonathanh@nvidia.com>
Date: Wed Aug 21 16:02:40 2019 +0100
clocksource/drivers/timer-of: Do not warn on deferred probe
commit 14e019df1e64c8b19ce8e0b3da25b6f40c8716be
Author: Jon Hunter <jonathanh@nvidia.com>
Date: Wed Aug 21 16:02:41 2019 +0100
clocksource/drivers: Do not warn on probe defer
> Also, thanks for testing all of these and letting me know.
No problem!
Cheers
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: [PATCH 5.3 00/21] 5.3.1-stable review
@ 2019-09-20 16:01 ` Jon Hunter
0 siblings, 0 replies; 33+ messages in thread
From: Jon Hunter @ 2019-09-20 16:01 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, linux, shuah, patches,
ben.hutchings, lkft-triage, stable, linux-tegra
On 20/09/2019 15:24, Greg Kroah-Hartman wrote:
> On Fri, Sep 20, 2019 at 02:54:26PM +0100, Jon Hunter wrote:
>>
>> On 19/09/2019 23:03, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 5.3.1 release.
>>> There are 21 patches in this series, all will be posted as a response
>>> to this one. If anyone has any issues with these being applied, please
>>> let me know.
>>>
>>> Responses should be made by Sat 21 Sep 2019 09:44:25 PM UTC.
>>> Anything received after that time might be too late.
>>>
>>> The whole patch series can be found in one patch at:
>>> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.3.1-rc1.gz
>>> or in the git tree and branch at:
>>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.3.y
>>> and the diffstat can be found below.
>>>
>>> thanks,
>>>
>>> greg k-h
>>
>> No new regressions* for Tegra ...
>>
>> Test results for stable-v5.3:
>> 12 builds: 12 pass, 0 fail
>> 22 boots: 22 pass, 0 fail
>> 38 tests: 37 pass, 1 fail
>>
>> Linux version: 5.3.1-rc1-g0aa7f3d6baae
>> Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
>> tegra194-p2972-0000, tegra20-ventana,
>> tegra210-p2371-2180, tegra30-cardhu-a04
>>
>> * Note we had one regression in v5.3 for a warnings test for Tegra194
>> causing the above test failure. This has since been fixed by the
>> following commits [0] but given it is just a warning, I have not
>> bothered CC'ing for stable.
>>
>> Cheers
>> Jon
>>
>> [0] https://lkml.org/lkml/2019/8/21/602
>
> I'll be glad to take this in stable for 5.3.y, what is the git commit
> id?
OK, that would be great. The IDs are ...
commit 763719771e84b8c8c2f53af668cdc905faa608de
Author: Jon Hunter <jonathanh@nvidia.com>
Date: Wed Aug 21 16:02:40 2019 +0100
clocksource/drivers/timer-of: Do not warn on deferred probe
commit 14e019df1e64c8b19ce8e0b3da25b6f40c8716be
Author: Jon Hunter <jonathanh@nvidia.com>
Date: Wed Aug 21 16:02:41 2019 +0100
clocksource/drivers: Do not warn on probe defer
> Also, thanks for testing all of these and letting me know.
No problem!
Cheers
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: [PATCH 5.3 00/21] 5.3.1-stable review
2019-09-20 16:01 ` Jon Hunter
(?)
@ 2019-09-22 8:13 ` Greg Kroah-Hartman
-1 siblings, 0 replies; 33+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-22 8:13 UTC (permalink / raw)
To: Jon Hunter
Cc: linux-kernel, torvalds, akpm, linux, shuah, patches,
ben.hutchings, lkft-triage, stable, linux-tegra
On Fri, Sep 20, 2019 at 05:01:35PM +0100, Jon Hunter wrote:
>
> On 20/09/2019 15:24, Greg Kroah-Hartman wrote:
> > On Fri, Sep 20, 2019 at 02:54:26PM +0100, Jon Hunter wrote:
> >>
> >> On 19/09/2019 23:03, Greg Kroah-Hartman wrote:
> >>> This is the start of the stable review cycle for the 5.3.1 release.
> >>> There are 21 patches in this series, all will be posted as a response
> >>> to this one. If anyone has any issues with these being applied, please
> >>> let me know.
> >>>
> >>> Responses should be made by Sat 21 Sep 2019 09:44:25 PM UTC.
> >>> Anything received after that time might be too late.
> >>>
> >>> The whole patch series can be found in one patch at:
> >>> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.3.1-rc1.gz
> >>> or in the git tree and branch at:
> >>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.3.y
> >>> and the diffstat can be found below.
> >>>
> >>> thanks,
> >>>
> >>> greg k-h
> >>
> >> No new regressions* for Tegra ...
> >>
> >> Test results for stable-v5.3:
> >> 12 builds: 12 pass, 0 fail
> >> 22 boots: 22 pass, 0 fail
> >> 38 tests: 37 pass, 1 fail
> >>
> >> Linux version: 5.3.1-rc1-g0aa7f3d6baae
> >> Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
> >> tegra194-p2972-0000, tegra20-ventana,
> >> tegra210-p2371-2180, tegra30-cardhu-a04
> >>
> >> * Note we had one regression in v5.3 for a warnings test for Tegra194
> >> causing the above test failure. This has since been fixed by the
> >> following commits [0] but given it is just a warning, I have not
> >> bothered CC'ing for stable.
> >>
> >> Cheers
> >> Jon
> >>
> >> [0] https://lkml.org/lkml/2019/8/21/602
> >
> > I'll be glad to take this in stable for 5.3.y, what is the git commit
> > id?
>
> OK, that would be great. The IDs are ...
>
> commit 763719771e84b8c8c2f53af668cdc905faa608de
> Author: Jon Hunter <jonathanh@nvidia.com>
> Date: Wed Aug 21 16:02:40 2019 +0100
>
> clocksource/drivers/timer-of: Do not warn on deferred probe
>
>
> commit 14e019df1e64c8b19ce8e0b3da25b6f40c8716be
> Author: Jon Hunter <jonathanh@nvidia.com>
> Date: Wed Aug 21 16:02:41 2019 +0100
>
> clocksource/drivers: Do not warn on probe defer
>
>
Now queued up, thanks!
greg k-h
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 5.3 00/21] 5.3.1-stable review
2019-09-19 22:03 [PATCH 5.3 00/21] 5.3.1-stable review Greg Kroah-Hartman
` (22 preceding siblings ...)
2019-09-20 13:54 ` Jon Hunter
@ 2019-09-20 14:41 ` Naresh Kamboju
2019-09-21 5:06 ` Greg Kroah-Hartman
2019-09-20 21:17 ` shuah
24 siblings, 1 reply; 33+ messages in thread
From: Naresh Kamboju @ 2019-09-20 14:41 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: open list, Linus Torvalds, Andrew Morton, Guenter Roeck,
Shuah Khan, patches, Ben Hutchings, lkft-triage, linux- stable
On Fri, 20 Sep 2019 at 03:36, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 5.3.1 release.
> There are 21 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat 21 Sep 2019 09:44:25 PM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.3.1-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.3.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Summary
------------------------------------------------------------------------
kernel: 5.3.0
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git branch: master
git commit: 574cc4539762561d96b456dbc0544d8898bd4c6e
git describe: v5.3-10169-g574cc4539762
Test details: https://qa-reports.linaro.org/lkft/linux-mainline-oe/build/v5.3-10169-g574cc4539762
No regressions (compared to build v5.3-3662-g04cbfba62085)
No fixes (compared to build v5.3-3662-g04cbfba62085)
Ran 19661 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64
Test Suites
-----------
* build
* install-android-platform-tools-r2600
* perf
* kselftest
* libgpiod
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* network-basic-tests
* spectre-meltdown-checker-test
* v4l2-compliance
* kvm-unit-tests
* ssuite
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: [PATCH 5.3 00/21] 5.3.1-stable review
2019-09-20 14:41 ` Naresh Kamboju
@ 2019-09-21 5:06 ` Greg Kroah-Hartman
0 siblings, 0 replies; 33+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-21 5:06 UTC (permalink / raw)
To: Naresh Kamboju
Cc: open list, Linus Torvalds, Andrew Morton, Guenter Roeck,
Shuah Khan, patches, Ben Hutchings, lkft-triage, linux- stable
On Fri, Sep 20, 2019 at 08:11:35PM +0530, Naresh Kamboju wrote:
> On Fri, 20 Sep 2019 at 03:36, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > This is the start of the stable review cycle for the 5.3.1 release.
> > There are 21 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sat 21 Sep 2019 09:44:25 PM UTC.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.3.1-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.3.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Results from Linaro’s test farm.
> No regressions on arm64, arm, x86_64, and i386.
Nice to see 5.3.0 pass everything :)
Thanks for testing all of these and letting me know.
greg k-h
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 5.3 00/21] 5.3.1-stable review
2019-09-19 22:03 [PATCH 5.3 00/21] 5.3.1-stable review Greg Kroah-Hartman
` (23 preceding siblings ...)
2019-09-20 14:41 ` Naresh Kamboju
@ 2019-09-20 21:17 ` shuah
2019-09-21 5:04 ` Greg Kroah-Hartman
24 siblings, 1 reply; 33+ messages in thread
From: shuah @ 2019-09-20 21:17 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, patches, ben.hutchings, lkft-triage,
stable, shuah
On 9/19/19 4:03 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.3.1 release.
> There are 21 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat 21 Sep 2019 09:44:25 PM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.3.1-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.3.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: [PATCH 5.3 00/21] 5.3.1-stable review
2019-09-20 21:17 ` shuah
@ 2019-09-21 5:04 ` Greg Kroah-Hartman
0 siblings, 0 replies; 33+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-21 5:04 UTC (permalink / raw)
To: shuah
Cc: linux-kernel, torvalds, akpm, linux, patches, ben.hutchings,
lkft-triage, stable
On Fri, Sep 20, 2019 at 03:17:48PM -0600, shuah wrote:
> On 9/19/19 4:03 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.3.1 release.
> > There are 21 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sat 21 Sep 2019 09:44:25 PM UTC.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.3.1-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.3.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Compiled and booted on my test system. No dmesg regressions.
Thanks for testing all of these and letting me know.
greg k-h
^ permalink raw reply [flat|nested] 33+ messages in thread