This is the start of the stable review cycle for the 5.3.18 release.
There are 25 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.
Note, this is the LAST 5.3.y kernel to be released, after this one, it
will be end-of-life. You should have moved to the 5.4.y series already
by now.
Responses should be made by Thu, 19 Dec 2019 20:08:42 +0000.
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.18-rc1…
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
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 5.3.18-rc1
Jonathan Lemon <jonathan.lemon(a)gmail.com>
xdp: obtain the mem_id mutex before trying to remove an entry.
Jonathan Lemon <jonathan.lemon(a)gmail.com>
page_pool: do not release pool until inflight == 0.
Eran Ben Elisha <eranbe(a)mellanox.com>
net/mlx5e: Fix TXQ indices to be sequential
Martin Varghese <martin.varghese(a)nokia.com>
net: Fixed updating of ethertype in skb_mpls_push()
Taehee Yoo <ap420073(a)gmail.com>
hsr: fix a NULL pointer dereference in hsr_dev_xmit()
Martin Varghese <martin.varghese(a)nokia.com>
Fixed updating of ethertype in function skb_mpls_pop
Cong Wang <xiyou.wangcong(a)gmail.com>
gre: refetch erspan header from skb->data after pskb_may_pull()
Guillaume Nault <gnault(a)redhat.com>
tcp: Protect accesses to .ts_recent_stamp with {READ,WRITE}_ONCE()
Guillaume Nault <gnault(a)redhat.com>
tcp: tighten acceptance of ACKs not matching a child socket
Guillaume Nault <gnault(a)redhat.com>
tcp: fix rejected syncookies due to stale timestamps
Sabrina Dubroca <sd(a)queasysnail.net>
net: ipv6_stub: use ip6_dst_lookup_flow instead of ip6_dst_lookup
Sabrina Dubroca <sd(a)queasysnail.net>
net: ipv6: add net argument to ip6_dst_lookup_flow
Huy Nguyen <huyn(a)mellanox.com>
net/mlx5e: Query global pause state before setting prio2buffer
Taehee Yoo <ap420073(a)gmail.com>
tipc: fix ordering of tipc module init and exit routine
Eric Dumazet <edumazet(a)google.com>
tcp: md5: fix potential overestimation of TCP option space
Aaron Conole <aconole(a)redhat.com>
openvswitch: support asymmetric conntrack
Valentin Vidic <vvidic(a)valentin-vidic.from.hr>
net/tls: Fix return values to avoid ENOTSUPP
Mian Yousaf Kaukab <ykaukab(a)suse.de>
net: thunderx: start phy before starting autonegotiation
Jouni Hogander <jouni.hogander(a)unikie.com>
net-sysfs: Call dev_hold always in netdev_queue_add_kobject
Dust Li <dust.li(a)linux.alibaba.com>
net: sched: fix dump qlen for sch_mq/sch_mqprio with NOLOCK subqueues
Grygorii Strashko <grygorii.strashko(a)ti.com>
net: ethernet: ti: cpsw: fix extra rx interrupt
Alexander Lobakin <alobakin(a)dlink.ru>
net: dsa: fix flow dissection on Tx path
Nikolay Aleksandrov <nikolay(a)cumulusnetworks.com>
net: bridge: deny dev_set_mac_address() when unregistering
Vladyslav Tarasiuk <vladyslavt(a)mellanox.com>
mqprio: Fix out-of-bounds access in mqprio_dump
Eric Dumazet <edumazet(a)google.com>
inet: protect against too small mtu values.
-------------
Diffstat:
Makefile | 4 +-
drivers/infiniband/core/addr.c | 7 +-
drivers/infiniband/sw/rxe/rxe_net.c | 8 +-
drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/en.h | 2 +-
.../ethernet/mellanox/mlx5/core/en/port_buffer.c | 27 ++++-
.../net/ethernet/mellanox/mlx5/core/en/tc_tun.c | 8 +-
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 31 ++----
drivers/net/ethernet/mellanox/mlx5/core/en_stats.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/en_tx.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +-
drivers/net/ethernet/ti/cpsw.c | 2 +-
drivers/net/geneve.c | 4 +-
drivers/net/vxlan.c | 8 +-
include/linux/netdevice.h | 5 +
include/linux/skbuff.h | 5 +-
include/linux/time.h | 13 +++
include/net/ip.h | 5 +
include/net/ipv6.h | 2 +-
include/net/ipv6_stubs.h | 6 +-
include/net/page_pool.h | 52 +++------
include/net/tcp.h | 27 +++--
include/net/xdp_priv.h | 4 -
include/trace/events/xdp.h | 19 +---
net/bridge/br_device.c | 6 +
net/core/dev.c | 3 +-
net/core/flow_dissector.c | 5 +-
net/core/lwt_bpf.c | 4 +-
net/core/net-sysfs.c | 7 +-
net/core/page_pool.c | 122 +++++++++++++--------
net/core/skbuff.c | 10 +-
net/core/xdp.c | 117 +++++++-------------
net/dccp/ipv6.c | 6 +-
net/hsr/hsr_device.c | 9 +-
net/ipv4/devinet.c | 5 -
net/ipv4/gre_demux.c | 2 +-
net/ipv4/ip_output.c | 13 ++-
net/ipv4/tcp_output.c | 5 +-
net/ipv6/addrconf_core.c | 11 +-
net/ipv6/af_inet6.c | 4 +-
net/ipv6/datagram.c | 2 +-
net/ipv6/inet6_connection_sock.c | 4 +-
net/ipv6/ip6_output.c | 8 +-
net/ipv6/raw.c | 2 +-
net/ipv6/syncookies.c | 2 +-
net/ipv6/tcp_ipv6.c | 4 +-
net/l2tp/l2tp_ip6.c | 2 +-
net/mpls/af_mpls.c | 7 +-
net/openvswitch/actions.c | 6 +-
net/openvswitch/conntrack.c | 11 ++
net/sched/act_mpls.c | 7 +-
net/sched/sch_mq.c | 1 +
net/sched/sch_mqprio.c | 3 +-
net/sctp/ipv6.c | 4 +-
net/tipc/core.c | 29 ++---
net/tipc/udp_media.c | 9 +-
net/tls/tls_device.c | 8 +-
net/tls/tls_main.c | 4 +-
net/tls/tls_sw.c | 8 +-
tools/testing/selftests/net/tls.c | 8 +-
60 files changed, 375 insertions(+), 332 deletions(-)
Make sure to use the current alternate setting when verifying the
storage interface descriptors to avoid submitting an URB to an invalid
endpoint.
Failing to do so could cause the driver to misbehave or trigger a WARN()
in usb_submit_urb() that kernels with panic_on_warn set would choke on.
Fixes: 36bcce430657 ("ath9k_htc: Handle storage devices")
Cc: stable <stable(a)vger.kernel.org> # 2.6.39
Signed-off-by: Johan Hovold <johan(a)kernel.org>
---
drivers/net/wireless/ath/ath9k/hif_usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
index fb649d85b8fc..dd0c32379375 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -1216,7 +1216,7 @@ static void ath9k_hif_usb_firmware_cb(const struct firmware *fw, void *context)
static int send_eject_command(struct usb_interface *interface)
{
struct usb_device *udev = interface_to_usbdev(interface);
- struct usb_host_interface *iface_desc = &interface->altsetting[0];
+ struct usb_host_interface *iface_desc = interface->cur_altsetting;
struct usb_endpoint_descriptor *endpoint;
unsigned char *cmd;
u8 bulk_out_ep;
--
2.24.0
On Tue, Dec 17, 2019 at 11:51:55PM +0800, Siddharth Kapoor wrote:
> I would like to share a concern with the regulator patch which is part of
> 4.9.196 LTS kernel.
That's an *extremely* old kernel.
> https://lore.kernel.org/lkml/20190904124250.25844-1-broonie@kernel.org/
That's the patch "[PATCH] regulator: Defer init completion for a while
after late_initcall" which defers disabling of idle regulators for a
while.
Please include human readable descriptions of things like commits and
issues being discussed in e-mail in your mails, this makes them much
easier for humans to read especially when they have no internet access.
I do frequently catch up on my mail on flights or while otherwise
travelling so this is even more pressing for me than just being about
making things a bit easier to read.
> We have reverted the patch in Pixel kernels and would like you to look into
> this and consider reverting it upstream as well.
I've got nothing to do with the stable kernels so there's nothing I can
do here, sorry. However if this is triggering anything it's almost
certainly some kind of timing issue (this code isn't new, it's just
being run a bit later) and is only currently working through luck so I
do strongly recommend trying to figure out the actual problem since it's
liable to come back and bite you later - we did find one buggy driver in
mainline as a result of this change, it's possible you've got another
one.
Possibly your GPU supplies need to be flagged as always on, possibly
your GPU driver is forgetting to enable some supplies it needs, or
possibly there's a missing always-on constraint on one of the regulators
depending on how the driver expects this to work (if it's a proprietary
driver it shouldn't be using the regulator API itself). I'm quite
surprised you've not seen any issue before given that the supplies would
still be being disabled earlier.
Way back in 2017, fuzzing the 4.14-rc2 USB stack with syzkaller kicked
up the following WARNING from the UVC chain scanning code:
| list_add double add: new=ffff880069084010, prev=ffff880069084010,
| next=ffff880067d22298.
| ------------[ cut here ]------------
| WARNING: CPU: 1 PID: 1846 at lib/list_debug.c:31 __list_add_valid+0xbd/0xf0
| Modules linked in:
| CPU: 1 PID: 1846 Comm: kworker/1:2 Not tainted
| 4.14.0-rc2-42613-g1488251d1a98 #238
| Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
| Workqueue: usb_hub_wq hub_event
| task: ffff88006b01ca40 task.stack: ffff880064358000
| RIP: 0010:__list_add_valid+0xbd/0xf0 lib/list_debug.c:29
| RSP: 0018:ffff88006435ddd0 EFLAGS: 00010286
| RAX: 0000000000000058 RBX: ffff880067d22298 RCX: 0000000000000000
| RDX: 0000000000000058 RSI: ffffffff85a58800 RDI: ffffed000c86bbac
| RBP: ffff88006435dde8 R08: 1ffff1000c86ba52 R09: 0000000000000000
| R10: 0000000000000002 R11: 0000000000000000 R12: ffff880069084010
| R13: ffff880067d22298 R14: ffff880069084010 R15: ffff880067d222a0
| FS: 0000000000000000(0000) GS:ffff88006c900000(0000) knlGS:0000000000000000
| CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
| CR2: 0000000020004ff2 CR3: 000000006b447000 CR4: 00000000000006e0
| Call Trace:
| __list_add ./include/linux/list.h:59
| list_add_tail+0x8c/0x1b0 ./include/linux/list.h:92
| uvc_scan_chain_forward.isra.8+0x373/0x416
| drivers/media/usb/uvc/uvc_driver.c:1471
| uvc_scan_chain drivers/media/usb/uvc/uvc_driver.c:1585
| uvc_scan_device drivers/media/usb/uvc/uvc_driver.c:1769
| uvc_probe+0x77f2/0x8f00 drivers/media/usb/uvc/uvc_driver.c:2104
Looking into the output from usbmon, the interesting part is the
following data packet:
ffff880069c63e00 30710169 C Ci:1:002:0 0 143 = 09028f00 01030080
00090403 00000e01 00000924 03000103 7c003328 010204db
If we drop the lead configuration and interface descriptors, we're left
with an output terminal descriptor describing a generic display:
/* Output terminal descriptor */
buf[0] 09
buf[1] 24
buf[2] 03 /* UVC_VC_OUTPUT_TERMINAL */
buf[3] 00 /* ID */
buf[4] 01 /* type == 0x0301 (UVC_OTT_DISPLAY) */
buf[5] 03
buf[6] 7c
buf[7] 00 /* source ID refers to self! */
buf[8] 33
The problem with this descriptor is that it is self-referential: the
source ID of 0 matches itself! This causes the 'struct uvc_entity'
representing the display to be added to its chain list twice during
'uvc_scan_chain()': once via 'uvc_scan_chain_entity()' when it is
processed directly from the 'dev->entities' list and then again
immediately afterwards when trying to follow the source ID in
'uvc_scan_chain_forward()'
Add a check before adding an entity to a chain list to ensure that the
entity is not already part of a chain.
Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Cc: Mauro Carvalho Chehab <mchehab(a)kernel.org>
Cc: Dmitry Vyukov <dvyukov(a)google.com>
Cc: Kostya Serebryany <kcc(a)google.com>
Cc: <stable(a)vger.kernel.org>
Fixes: c0efd232929c ("V4L/DVB (8145a): USB Video Class driver")
Reported-by: Andrey Konovalov <andreyknvl(a)google.com>
Link: https://lore.kernel.org/linux-media/CAAeHK+z+Si69jUR+N-SjN9q4O+o5KFiNManqEa…
Signed-off-by: Will Deacon <will(a)kernel.org>
---
I don't have a way to reproduce the original issue, so this change is
based purely on inspection. Considering I'm not familiar with USB nor
UVC, I may well have missed something!
drivers/media/usb/uvc/uvc_driver.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c
index 66ee168ddc7e..e24420b1750a 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -1493,6 +1493,11 @@ static int uvc_scan_chain_forward(struct uvc_video_chain *chain,
break;
if (forward == prev)
continue;
+ if (forward->chain.next || forward->chain.prev) {
+ uvc_trace(UVC_TRACE_DESCR, "Found reference to "
+ "entity %d already in chain.\n", forward->id);
+ return -EINVAL;
+ }
switch (UVC_ENTITY_TYPE(forward)) {
case UVC_VC_EXTENSION_UNIT:
@@ -1574,6 +1579,13 @@ static int uvc_scan_chain_backward(struct uvc_video_chain *chain,
return -1;
}
+ if (term->chain.next || term->chain.prev) {
+ uvc_trace(UVC_TRACE_DESCR, "Found reference to "
+ "entity %d already in chain.\n",
+ term->id);
+ return -EINVAL;
+ }
+
if (uvc_trace_param & UVC_TRACE_PROBE)
printk(KERN_CONT " %d", term->id);
--
2.23.0.444.g18eeb5a265-goog