4.9.315-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainercover 4.9.315-rc1 review
This is the start of the stable review cycle for the 4.9.315 release. There are 19 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 Wed, 18 May 2022 19:36:02 +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/v4.x/stable-review/patch-4.9.315-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-4.9.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 4.9.315-rc1
Yang Yingliang <[email protected]>
tty/serial: digicolor: fix possible null-ptr-deref in digicolor_uart_probe()
Nicolas Dichtel <[email protected]>
ping: fix address binding wrt vrf
Sven Schwermer <[email protected]>
USB: serial: option: add Fibocom MA510 modem
Sven Schwermer <[email protected]>
USB: serial: option: add Fibocom L610 modem
Ethan Yang <[email protected]>
USB: serial: qcserial: add support for Sierra Wireless EM7590
Scott Chen <[email protected]>
USB: serial: pl2303: add device id for HP LM930 Display
Sergey Ryazanov <[email protected]>
usb: cdc-wdm: fix reading stuck on device close
Mark Brown <[email protected]>
ASoC: ops: Validate input values in snd_soc_put_volsw_range()
Mark Brown <[email protected]>
ASoC: max98090: Generate notifications on changes for custom control
Mark Brown <[email protected]>
ASoC: max98090: Reject invalid values in custom control put()
Ji-Ze Hong (Peter Hong) <[email protected]>
hwmon: (f71882fg) Fix negative temperature
Taehee Yoo <[email protected]>
net: sfc: ef10: fix memory leak in efx_ef10_mtd_probe()
Alexandra Winter <[email protected]>
s390/lcs: fix variable dereferenced before check
Alexandra Winter <[email protected]>
s390/ctcm: fix potential memory leak
Alexandra Winter <[email protected]>
s390/ctcm: fix variable dereferenced before check
Johannes Berg <[email protected]>
mac80211_hwsim: call ieee80211_tx_prepare_skb under RCU protection
Eric Dumazet <[email protected]>
netlink: do not reset transport header in netlink_recvmsg()
Lokesh Dhoundiyal <[email protected]>
ipv4: drop dst in multicast routing path
Tariq Toukan <[email protected]>
net: Fix features skip in for_each_netdev_feature()
-------------
Diffstat:
Makefile | 4 ++-- drivers/hwmon/f71882fg.c | 5 +++-- drivers/net/ethernet/sfc/ef10.c | 5 +++++ drivers/net/wireless/mac80211_hwsim.c | 3 +++ drivers/s390/net/ctcm_mpc.c | 6 +----- drivers/s390/net/ctcm_sysfs.c | 5 +++-- drivers/s390/net/lcs.c | 7 ++++--- drivers/tty/serial/digicolor-usart.c | 2 +- drivers/usb/class/cdc-wdm.c | 1 + drivers/usb/serial/option.c | 4 ++++ drivers/usb/serial/pl2303.c | 1 + drivers/usb/serial/pl2303.h | 1 + drivers/usb/serial/qcserial.c | 2 ++ include/linux/netdev_features.h | 4 ++-- net/ipv4/ping.c | 12 +++++++++++- net/ipv4/route.c | 1 + net/netlink/af_netlink.c | 1 - sound/soc/codecs/max98090.c | 5 ++++- sound/soc/soc-ops.c | 18 +++++++++++++++++- 19 files changed, 66 insertions(+), 21 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/19 net: Fix features skip in for_each_netdev_feature()
From: Tariq Toukan <[email protected]>
[ Upstream commit 85db6352fc8a158a893151baa1716463d34a20d0 ]
The find_next_netdev_feature() macro gets the "remaining length", not bit index.
Passing "bit - 1" for the following iteration is wrong as it skips the adjacent bit. Pass "bit" instead.
--- include/linux/netdev_features.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
include/linux/netdev_features.h +2 -2
@@ -139,7 +139,7 @@ enum {#define NETIF_F_BUSY_POLL __NETIF_F(BUSY_POLL)#define NETIF_F_HW_TC __NETIF_F(HW_TC) -/* Finds the next feature with the highest number of the range of start till 0. +/* Finds the next feature with the highest number of the range of start-1 till 0. */ static inline int find_next_netdev_feature (u64 feature,unsigned long start) {
@@ -158,7 +158,7 @@ static inline int find_next_netdev_feature(u64 feature, unsigned long start)for ((bit) =find_next_netdev_feature ((mask_addr), \NETDEV_FEATURE_COUNT ); \ (bit) >=0 ; \ - (bit) =find_next_netdev_feature ((mask_addr), (bit) -1 )) + (bit) =find_next_netdev_feature ((mask_addr), (bit)))/* Features valid for ethtool to change */ /* = all defined minus driver/device-class-related */
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 2/19 ipv4: drop dst in multicast routing path
In reply to Greg Kroah-HartmanFrom: Lokesh Dhoundiyal <[email protected]>
[ Upstream commit 9e6c6d17d1d6a3f1515ce399f9a011629ec79aa0 ]
kmemleak reports the following when routing multicast traffic over an ipsec tunnel.
Kmemleak output:
unreferenced object 0x8000000044bebb00 (size 256):
comm "softirq", pid 0, jiffies 4294985356 (age 126.810s) hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 80 00 00 00 05 13 74 80 ..............t.
80 00 00 00 04 9b bf f9 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000f83947e0>] __kmalloc+0x1e8/0x300
[<00000000b7ed8dca>] metadata_dst_alloc+0x24/0x58
[<0000000081d32c20>] __ipgre_rcv+0x100/0x2b8
[<00000000824f6cf1>] gre_rcv+0x178/0x540
[<00000000ccd4e162>] gre_rcv+0x7c/0xd8
[<00000000c024b148>] ip_protocol_deliver_rcu+0x124/0x350
[<000000006a483377>] ip_local_deliver_finish+0x54/0x68
[<00000000d9271b3a>] ip_local_deliver+0x128/0x168
[<00000000bd4968ae>] xfrm_trans_reinject+0xb8/0xf8
[<0000000071672a19>] tasklet_action_common.isra.16+0xc4/0x1b0
[<0000000062e9c336>] __do_softirq+0x1fc/0x3e0
[<00000000013d7914>] irq_exit+0xc4/0xe0
[<00000000a4d73e90>] plat_irq_dispatch+0x7c/0x108
[<000000000751eb8e>] handle_int+0x16c/0x178
[<000000001668023b>] _raw_spin_unlock_irqrestore+0x1c/0x28The metadata dst is leaked when ip_route_input_mc() updates the dst for the skb. Commit f38a9eb1f77b ("dst: Metadata destinations") correctly handled dropping the dst in ip_route_input_slow() but missed the multicast case which is handled by ip_route_input_mc(). Drop the dst in ip_route_input_mc() avoiding the leak.
--- net/ipv4/route.c | 1 + 1 file changed, 1 insertion(+)
net/ipv4/route.c +1 -0
@@ -1606,6 +1606,7 @@ static int ip_route_input_mc(struct sk_buff *skb, __be32 daddr, __be32 saddr,#endif RT_CACHE_STAT_INC (in_slow_mc); +skb_dst_drop (skb);skb_dst_set (skb, &rth->dst);return 0 ;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 3/19 netlink: do not reset transport header in netlink_recvmsg()
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
[ Upstream commit d5076fe4049cadef1f040eda4aaa001bb5424225 ]
netlink_recvmsg() does not need to change transport header.
If transport header was needed, it should have been reset by the producer (netlink_dump()), not the consumer(s).
The following trace probably happened when multiple threads were using MSG_PEEK.
BUG: KCSAN: data-race in netlink_recvmsg / netlink_recvmsg
write to 0xffff88811e9f15b2 of 2 bytes by task 32012 on cpu 1:
skb_reset_transport_header include/linux/skbuff.h:2760 [inline] netlink_recvmsg+0x1de/0x790 net/netlink/af_netlink.c:1978 sock_recvmsg_nosec net/socket.c:948 [inline] sock_recvmsg net/socket.c:966 [inline] __sys_recvfrom+0x204/0x2c0 net/socket.c:2097 __do_sys_recvfrom net/socket.c:2115 [inline] __se_sys_recvfrom net/socket.c:2111 [inline] __x64_sys_recvfrom+0x74/0x90 net/socket.c:2111 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae
write to 0xffff88811e9f15b2 of 2 bytes by task 32005 on cpu 0:
skb_reset_transport_header include/linux/skbuff.h:2760 [inline] netlink_recvmsg+0x1de/0x790 net/netlink/af_netlink.c:1978 ____sys_recvmsg+0x162/0x2f0 ___sys_recvmsg net/socket.c:2674 [inline] __sys_recvmsg+0x209/0x3f0 net/socket.c:2704 __do_sys_recvmsg net/socket.c:2714 [inline] __se_sys_recvmsg net/socket.c:2711 [inline] __x64_sys_recvmsg+0x42/0x50 net/socket.c:2711 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae
value changed: 0xffff -> 0x0000
Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 32005 Comm: syz-executor.4 Not tainted 5.18.0-rc1-syzkaller-00328-ge1f700ebd6be-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
--- net/netlink/af_netlink.c | 1 - 1 file changed, 1 deletion(-)
net/netlink/af_netlink.c +0 -1
@@ -1929,7 +1929,6 @@ static int netlink_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, copied = len; } -skb_reset_transport_header (data_skb); err =skb_copy_datagram_msg (data_skb,0 , msg, copied);if (msg->msg_name) {
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 4/19 mac80211_hwsim: call ieee80211_tx_prepare_skb under RCU protection
In reply to Greg Kroah-HartmanFrom: Johannes Berg <[email protected]>
[ Upstream commit 9e2db50f1ef2238fc2f71c5de1c0418b7a5b0ea2 ]
This is needed since it might use (and pass out) pointers to e.g. keys protected by RCU. Can't really happen here as the frames aren't encrypted, but we need to still adhere to the rules.
--- drivers/net/wireless/mac80211_hwsim.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/net/wireless/mac80211_hwsim.c +3 -0
@@ -1987,11 +1987,13 @@ static void hw_scan_work(struct work_struct *work)memcpy (skb_put (probe, req->ie_len), req->ie, req->ie_len); +rcu_read_lock ();if (!ieee80211_tx_prepare_skb (hwsim->hw, hwsim->hw_scan_vif, probe, hwsim->tmp_chan->band,NULL )) { +rcu_read_unlock ();kfree_skb (probe);continue ; }
@@ -1999,6 +2001,7 @@ static void hw_scan_work(struct work_struct *work)local_bh_disable ();mac80211_hwsim_tx_frame (hwsim->hw, probe, hwsim->tmp_chan); +rcu_read_unlock ();local_bh_enable (); } }
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 5/19 s390/ctcm: fix variable dereferenced before check
In reply to Greg Kroah-HartmanFrom: Alexandra Winter <[email protected]>
[ Upstream commit 2c50c6867c85afee6f2b3bcbc50fc9d0083d1343 ]
Found by cppcheck and smatch.
smatch complains aboutdrivers/s390/net/ctcm_sysfs.c:43 ctcm_buffer_write() warn: variable dereferenced before check 'priv' (see line 42)
--- drivers/s390/net/ctcm_sysfs.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/s390/net/ctcm_sysfs.c +3 -2
@@ -38,11 +38,12 @@ static ssize_t ctcm_buffer_write(struct device *dev,struct ctcm_priv *priv =dev_get_drvdata (dev);int rc; - ndev = priv->channel[CTCM_READ ]->netdev; -if (!(priv && priv->channel[CTCM_READ ] && ndev)) { +if (!(priv && priv->channel[CTCM_READ ] && + priv->channel[CTCM_READ ]->netdev)) {CTCM_DBF_TEXT (SETUP ,CTC_DBF_ERROR ,"bfnondev" );return -ENODEV ; } + ndev = priv->channel[CTCM_READ ]->netdev; rc =kstrtouint (buf,0 , &bs1);if (rc)
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 6/19 s390/ctcm: fix potential memory leak
In reply to Greg Kroah-HartmanFrom: Alexandra Winter <[email protected]>
[ Upstream commit 0c0b20587b9f25a2ad14db7f80ebe49bdf29920a ]
smatch complains aboutdrivers/s390/net/ctcm_mpc.c:1210 ctcmpc_unpack_skb() warn: possible memory leak of 'mpcginfo'
mpc_action_discontact() did not free mpcginfo. Consolidate the freeing in ctcmpc_unpack_skb().
--- drivers/s390/net/ctcm_mpc.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-)
drivers/s390/net/ctcm_mpc.c +1 -5
@@ -624,8 +624,6 @@ static void mpc_rcvd_sweep_resp(struct mpcg_info *mpcginfo)ctcm_clear_busy_do (dev); } -kfree (mpcginfo); -return ; }
@@ -1205,10 +1203,10 @@ static void ctcmpc_unpack_skb(struct channel *ch, struct sk_buff *pskb) CTCM_FUNTAIL, dev->name); priv->stats.rx_dropped++;/* mpcginfo only used for non-data transfers */ -kfree (mpcginfo);if (do_debug_data)ctcmpc_dump_skb (pskb,-8 ); } +kfree (mpcginfo); } done:
@@ -1998,7 +1996,6 @@ static void mpc_action_rcvd_xid0(fsm_instance *fsm, int event, void *arg) }break ; } -kfree (mpcginfo); CTCM_PR_DEBUG("ctcmpc:%s() %s xid2:%i xid7:%i xidt_p2:%i \n", __func__, ch->id, grp->outstanding_xid2,
@@ -2059,7 +2056,6 @@ static void mpc_action_rcvd_xid7(fsm_instance *fsm, int event, void *arg)mpc_validate_xid (mpcginfo);break ; } -kfree (mpcginfo);return ; }
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 7/19 s390/lcs: fix variable dereferenced before check
In reply to Greg Kroah-HartmanFrom: Alexandra Winter <[email protected]>
[ Upstream commit 671bb35c8e746439f0ed70815968f9a4f20a8deb ]
smatch complains aboutdrivers/s390/net/lcs.c:1741 lcs_get_control() warn: variable dereferenced before check 'card->dev' (see line 1739)
--- drivers/s390/net/lcs.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/s390/net/lcs.c +4 -3
@@ -1761,10 +1761,11 @@ lcs_get_control(struct lcs_card *card, struct lcs_cmd *cmd)lcs_schedule_recovery (card);break ;case LCS_CMD_STOPLAN : -pr_warn ("Stoplan for %s initiated by LGW\n" , - card->dev->name); -if (card->dev) +if (card->dev) { +pr_warn ("Stoplan for %s initiated by LGW\n" , + card->dev->name);netif_carrier_off (card->dev); + }break ;default :LCS_DBF_TEXT (5 , trace,"noLGWcmd" );
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 8/19 net: sfc: ef10: fix memory leak in efx_ef10_mtd_probe()
In reply to Greg Kroah-HartmanFrom: Taehee Yoo <[email protected]>
[ Upstream commit 1fa89ffbc04545b7582518e57f4b63e2a062870f ]
In the NIC ->probe() callback, ->mtd_probe() callback is called. If NIC has 2 ports, ->probe() is called twice and ->mtd_probe() too. In the ->mtd_probe(), which is efx_ef10_mtd_probe() it allocates and initializes mtd partiion.
But mtd partition for sfc is shared data.
So that allocated mtd partition data from last called efx_ef10_mtd_probe() will not be used.
Therefore it must be freed.
But it doesn't free a not used mtd partition data in efx_ef10_mtd_probe().
kmemleak reports:
unreferenced object 0xffff88811ddb0000 (size 63168):
comm "systemd-udevd", pid 265, jiffies 4294681048 (age 348.586s) hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffffa3767749>] kmalloc_order_trace+0x19/0x120
[<ffffffffa3873f0e>] __kmalloc+0x20e/0x250
[<ffffffffc041389f>] efx_ef10_mtd_probe+0x11f/0x270 [sfc]
[<ffffffffc0484c8a>] efx_pci_probe.cold.17+0x3df/0x53d [sfc]
[<ffffffffa414192c>] local_pci_probe+0xdc/0x170
[<ffffffffa4145df5>] pci_device_probe+0x235/0x680
[<ffffffffa443dd52>] really_probe+0x1c2/0x8f0
[<ffffffffa443e72b>] __driver_probe_device+0x2ab/0x460
[<ffffffffa443e92a>] driver_probe_device+0x4a/0x120
[<ffffffffa443f2ae>] __driver_attach+0x16e/0x320
[<ffffffffa4437a90>] bus_for_each_dev+0x110/0x190
[<ffffffffa443b75e>] bus_add_driver+0x39e/0x560
[<ffffffffa4440b1e>] driver_register+0x18e/0x310
[<ffffffffc02e2055>] 0xffffffffc02e2055
[<ffffffffa3001af3>] do_one_initcall+0xc3/0x450
[<ffffffffa33ca574>] do_init_module+0x1b4/0x700--- drivers/net/ethernet/sfc/ef10.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/net/ethernet/sfc/ef10.c +5 -0
@@ -5197,6 +5197,11 @@ static int efx_ef10_mtd_probe(struct efx_nic *efx) n_parts++; } +if (!n_parts) { +kfree (parts); +return 0 ; + } + rc =efx_mtd_add (efx, &parts[0 ].common, n_parts,sizeof (*parts)); fail:if (rc)
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 9/19 hwmon: (f71882fg) Fix negative temperature
In reply to Greg Kroah-HartmanFrom: Ji-Ze Hong (Peter Hong) <[email protected]>
[ Upstream commit 4aaaaf0f279836f06d3b9d0ffeec7a1e1a04ceef ]
All temperature of Fintek superio hwmonitor that using 1-byte reg will use 2's complement.
In show_temp()
temp = data->temp[nr] * 1000;
When data->temp[nr] read as 255, it indicate -1C, but this code will report 255C to userspace. It'll be ok when change to:
temp = ((s8)data->temp[nr]) * 1000;
--- drivers/hwmon/f71882fg.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/hwmon/f71882fg.c +3 -2
@@ -1590,8 +1590,9 @@ static ssize_t show_temp(struct device *dev, struct device_attribute *devattr, temp *=125 ;if (sign) temp -=128000 ; - }else - temp = data->temp[nr] *1000 ; + }else { + temp = ((s8 )data->temp[nr]) *1000 ; + }return sprintf (buf,"%d\n" , temp); }
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 10/19 ASoC: max98090: Reject invalid values in custom control put()
In reply to Greg Kroah-HartmanFrom: Mark Brown <[email protected]>
[ Upstream commit 2fbe467bcbfc760a08f08475eea6bbd4c2874319 ]
The max98090 driver has a custom put function for some controls which can only be updated in certain circumstances which makes no effort to validate that input is suitable for the control, allowing out of spec values to be written to the hardware and presented to userspace. Fix this by returning an error when invalid values are written.
--- sound/soc/codecs/max98090.c | 3 +++ 1 file changed, 3 insertions(+)
sound/soc/codecs/max98090.c +3 -0
@@ -419,6 +419,9 @@ static int max98090_put_enab_tlv(struct snd_kcontrol *kcontrol, val = (val >> mc->shift) & mask; +if (sel <0 || sel > mc->max) +return -EINVAL ; + *select = sel;/* Setting a volume is only valid if it is already On */
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 11/19 ASoC: max98090: Generate notifications on changes for custom control
In reply to Greg Kroah-HartmanFrom: Mark Brown <[email protected]>
[ Upstream commit 13fcf676d9e102594effc686d98521ff5c90b925 ]
The max98090 driver has some custom controls which share a put() function which returns 0 unconditionally, meaning that events are not generated when the value changes. Fix that.
--- sound/soc/codecs/max98090.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/soc/codecs/max98090.c +1 -1
@@ -436,7 +436,7 @@ static int max98090_put_enab_tlv(struct snd_kcontrol *kcontrol, mask << mc->shift, sel << mc->shift); -return 0 ; +return *select != val; } static const char *max98090_perf_pwr_text[] =
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 12/19 ASoC: ops: Validate input values in snd_soc_put_volsw_range()
In reply to Greg Kroah-HartmanFrom: Mark Brown <[email protected]>
[ Upstream commit aa22125c57f9e577f0a667e4fa07fc3fa8ca1e60 ]
Check that values written via snd_soc_put_volsw_range() are within the range advertised by the control, ensuring that we don't write out of spec values to the hardware.
--- sound/soc/soc-ops.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-)
sound/soc/soc-ops.c +17 -1
@@ -528,7 +528,15 @@ int snd_soc_put_volsw_range(struct snd_kcontrol *kcontrol,unsigned int mask = (1 <<fls (max)) -1 ;unsigned int invert = mc->invert;unsigned int val, val_mask; -int err, ret; +int err, ret, tmp; + + tmp = ucontrol->value.integer.value[0 ]; +if (tmp <0 ) +return -EINVAL ; +if (mc->platform_max && tmp > mc->platform_max) +return -EINVAL ; +if (tmp > mc->max - mc->min +1 ) +return -EINVAL ;if (invert) val = (max - ucontrol->value.integer.value[0 ]) & mask;
@@ -543,6 +551,14 @@ int snd_soc_put_volsw_range(struct snd_kcontrol *kcontrol, ret = err;if (snd_soc_volsw_is_stereo (mc)) { + tmp = ucontrol->value.integer.value[1 ]; +if (tmp <0 ) +return -EINVAL ; +if (mc->platform_max && tmp > mc->platform_max) +return -EINVAL ; +if (tmp > mc->max - mc->min +1 ) +return -EINVAL ; +if (invert) val = (max - ucontrol->value.integer.value[1 ]) & mask;else
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 13/19 usb: cdc-wdm: fix reading stuck on device close
In reply to Greg Kroah-HartmanFrom: Sergey Ryazanov <[email protected]>
commit 01e01f5c89773c600a9f0b32c888de0146066c3a upstream.
cdc-wdm tracks whether a response reading request is in-progress and blocks the next request from being sent until the previous request is completed. As soon as last user closes the cdc-wdm device file, the driver cancels any ongoing requests, resets the pending response counter, but leaves the response reading in-progress flag (WDM_RESPONDING) untouched.
So if the user closes the device file during the response receive request is being performed, no more data will be obtained from the modem. The request will be cancelled, effectively preventing the WDM_RESPONDING flag from being reseted. Keeping the flag set will prevent a new response receive request from being sent, permanently blocking the read path. The read path will staying blocked until the module will be reloaded or till the modem will be re-attached.
This stuck has been observed with a Huawei E3372 modem attached to an OpenWrt router and using the comgt utility to set up a network connection.
Fix this issue by clearing the WDM_RESPONDING flag on the device file close.
Without this fix, the device reading stuck can be easily reproduced in a few connection establishing attempts. With this fix, a load test for modem connection re-establishing worked for several hours without any issues.
--- drivers/usb/class/cdc-wdm.c | 1 + 1 file changed, 1 insertion(+)
drivers/usb/class/cdc-wdm.c +1 -0
@@ -744,6 +744,7 @@ static int wdm_release(struct inode *inokill_urbs (desc);spin_lock_irq (&desc->iuspin); desc->resp_count =0 ; +clear_bit (WDM_RESPONDING , &desc->flags);spin_unlock_irq (&desc->iuspin); desc->manage_power (desc->intf,0 ); }else {
Greg Kroah-Hartman
maintainerPATCH 14/19 USB: serial: pl2303: add device id for HP LM930 Display
In reply to Greg Kroah-HartmanFrom: Scott Chen <[email protected]>
commit 26a08f8bad3e1f98d3153f939fb8cd330da4cb26 upstream.
Add the device id for the HPLM930Display which is a PL2303GC based device.
--- drivers/usb/serial/pl2303.c | 1 + drivers/usb/serial/pl2303.h | 1 + 2 files changed, 2 insertions(+)
drivers/usb/serial/pl2303.c +1 -0
@@ -95,6 +95,7 @@ static const struct usb_device_id id_tab { USB_DEVICE(HP_VENDOR_ID, HP_LCM220_PRODUCT_ID) }, { USB_DEVICE(HP_VENDOR_ID, HP_LCM960_PRODUCT_ID) }, { USB_DEVICE(HP_VENDOR_ID, HP_LM920_PRODUCT_ID) }, + { USB_DEVICE(HP_VENDOR_ID, HP_LM930_PRODUCT_ID) }, { USB_DEVICE(HP_VENDOR_ID, HP_LM940_PRODUCT_ID) }, { USB_DEVICE(HP_VENDOR_ID, HP_TD620_PRODUCT_ID) }, { USB_DEVICE(CRESSI_VENDOR_ID, CRESSI_EDY_PRODUCT_ID) },
drivers/usb/serial/pl2303.h +1 -0
@@ -133,6 +133,7 @@#define HP_TD620_PRODUCT_ID 0x0956#define HP_LD960_PRODUCT_ID 0x0b39#define HP_LD381_PRODUCT_ID 0x0f7f +#define HP_LM930_PRODUCT_ID 0x0f9b#define HP_LCM220_PRODUCT_ID 0x3139#define HP_LCM960_PRODUCT_ID 0x3239#define HP_LD220_PRODUCT_ID 0x3524
Greg Kroah-Hartman
maintainerPATCH 15/19 USB: serial: qcserial: add support for Sierra Wireless EM7590
In reply to Greg Kroah-HartmanFrom: Ethan Yang <[email protected]>
commit 870b1eee2d844727b06e238c121d260bc5645580 upstream.
Add support for Sierra Wireless EM7590 0xc080/0xc081 compositions.
--- drivers/usb/serial/qcserial.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/usb/serial/qcserial.c +2 -0
@@ -170,6 +170,8 @@ static const struct usb_device_id id_tab {DEVICE_SWI(0x1199, 0x9090)}, /* Sierra Wireless EM7565 QDL */ {DEVICE_SWI(0x1199, 0x9091)}, /* Sierra Wireless EM7565 */ {DEVICE_SWI(0x1199, 0x90d2)}, /* Sierra Wireless EM9191 QDL */ + {DEVICE_SWI(0x1199, 0xc080)}, /* Sierra Wireless EM7590 QDL */ + {DEVICE_SWI(0x1199, 0xc081)}, /* Sierra Wireless EM7590 */ {DEVICE_SWI(0x413c, 0x81a2)}, /* Dell Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card */ {DEVICE_SWI(0x413c, 0x81a3)}, /* Dell Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card */ {DEVICE_SWI(0x413c, 0x81a4)}, /* Dell Wireless 5570e HSPA+ (42Mbps) Mobile Broadband Card */
Greg Kroah-Hartman
maintainerPATCH 16/19 USB: serial: option: add Fibocom L610 modem
In reply to Greg Kroah-HartmanFrom: Sven Schwermer <[email protected]>
commit 714adff9a6271b5f1664b04c944b598141ebfe73 upstream.
The L610 modem has 3 USB configurations that are configurable via the AT command AT+GTUSBMODE={31,32,33} which make the modem enumerate with the following interfaces, respectively:
31: Modem + NV + MOS + Diag + LOG + AT + AT 32: ECM + Modem + NV + MOS + Diag + LOG + AT + AT 33: RNDIS + Modem + NV + MOS + Diag + LOG + AT + AT
A detailed description of the USB configuration for each mode follows:
+GTUSBMODE: 31
--------------
T: Bus=03 Lev=01 Prnt=01 Port=06 Cnt=04 Dev#=124 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1782 ProdID=4d10 Rev= 0.00 S: Manufacturer=FIBOCOM S: Product=L610 C:* #Ifs= 7 Cfg#= 1 Atr=e0 MxPwr=400mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
+GTUSBMODE: 32
--------------
T: Bus=03 Lev=01 Prnt=01 Port=06 Cnt=04 Dev#=122 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1782 ProdID=4d11 Rev= 0.00 S: Manufacturer=FIBOCOM S: Product=L610 C:* #Ifs= 9 Cfg#= 1 Atr=e0 MxPwr=400mA A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=06 Prot=00 I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=cdc_ether E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 7 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 8 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=08(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
+GTUSBMODE: 33
--------------
T: Bus=03 Lev=01 Prnt=01 Port=06 Cnt=04 Dev#=126 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1782 ProdID=4d11 Rev= 0.00 S: Manufacturer=FIBOCOM S: Product=L610
C:* #Ifs= 9 Cfg#= 1 Atr=e0 MxPwr=400mA
A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=03
I:* If#= 0 Alt= 0 #EPs= 1 Cls=e0(wlcon) Sub=01 Prot=03 Driver=rndis_host
E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=4096ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 7 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 8 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=08(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
--- drivers/usb/serial/option.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/usb/serial/option.c +2 -0
@@ -2101,6 +2101,8 @@ static const struct usb_device_id option .driver_info = RSVD(3) }, { USB_DEVICE(0x1508, 0x1001), /* Fibocom NL668 (IOT version) */ .driver_info = RSVD(4) | RSVD(5) | RSVD(6) }, + { USB_DEVICE(0x1782, 0x4d10) }, /* Fibocom L610 (AT mode) */ + { USB_DEVICE_INTERFACE_CLASS(0x1782, 0x4d11, 0xff) }, /* Fibocom L610 (ECM/RNDIS mode) */ { USB_DEVICE(0x2cb7, 0x0104), /* Fibocom NL678 series */ .driver_info = RSVD(4) | RSVD(5) }, { USB_DEVICE_INTERFACE_CLASS(0x2cb7, 0x0105, 0xff), /* Fibocom NL678 series */
Greg Kroah-Hartman
maintainerPATCH 17/19 USB: serial: option: add Fibocom MA510 modem
In reply to Greg Kroah-HartmanFrom: Sven Schwermer <[email protected]>
commit 07989eb981d862f7f2be68d233d753f2e7ccc119 upstream.
The MA510 modem has 3 USB configurations that are configurable via the AT command AT+GTUSBMODE={30,31,32} which make the modem enumerate with the following interfaces, respectively:
30: Diag + QDSS + Modem + RMNET
31: Diag + Modem + AT + ECM
32: Modem + AT + ECM
The first configuration (30) reuses u-blox R410M's VID/PID with identical interface configuration.
A detailed description of the USB configuration for each mode follows:
+GTUSBMODE: 30
--------------
T: Bus=03 Lev=01 Prnt=01 Port=06 Cnt=04 Dev#= 19 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=05c6 ProdID=90b2 Rev= 0.00 S: Manufacturer=Fibocom MA510 Modem S: Product=Fibocom MA510 Modem S: SerialNumber=55e2695b C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=2ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan E: Ad=85(I) Atr=03(Int.) MxPS= 64 Ivl=2ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
+GTUSBMODE: 31
--------------
T: Bus=03 Lev=01 Prnt=01 Port=06 Cnt=04 Dev#= 99 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2cb7 ProdID=0106 Rev= 0.00 S: Manufacturer=Fibocom MA510 Modem S: Product=Fibocom MA510 Modem S: SerialNumber=55e2695b C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA A: FirstIf#= 3 IfCount= 2 Cls=02(comm.) Sub=00 Prot=00 I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=82(I) Atr=03(Int.) MxPS= 64 Ivl=2ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fe Prot=ff Driver=option E: Ad=84(I) Atr=03(Int.) MxPS= 64 Ivl=2ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=cdc_ether E: Ad=86(I) Atr=03(Int.) MxPS= 64 Ivl=2ms I: If#= 4 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether I:* If#= 4 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
+GTUSBMODE: 32
--------------
T: Bus=03 Lev=01 Prnt=01 Port=06 Cnt=04 Dev#=100 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2cb7 ProdID=010a Rev= 0.00 S: Manufacturer=Fibocom MA510 Modem S: Product=Fibocom MA510 Modem S: SerialNumber=55e2695b C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=500mA A: FirstIf#= 2 IfCount= 2 Cls=02(comm.) Sub=00 Prot=00 I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=2ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fe Prot=ff Driver=option E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=2ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=cdc_ether E: Ad=85(I) Atr=03(Int.) MxPS= 64 Ivl=2ms I: If#= 3 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether I:* If#= 3 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
--- drivers/usb/serial/option.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/usb/serial/option.c +2 -0
@@ -2107,6 +2107,8 @@ static const struct usb_device_id option .driver_info = RSVD(4) | RSVD(5) }, { USB_DEVICE_INTERFACE_CLASS(0x2cb7, 0x0105, 0xff), /* Fibocom NL678 series */ .driver_info = RSVD(6) }, + { USB_DEVICE_INTERFACE_CLASS(0x2cb7, 0x0106, 0xff) }, /* Fibocom MA510 (ECM mode w/ diag intf.) */ + { USB_DEVICE_INTERFACE_CLASS(0x2cb7, 0x010a, 0xff) }, /* Fibocom MA510 (ECM mode) */ { USB_DEVICE_AND_INTERFACE_INFO(0x2cb7, 0x010b, 0xff, 0xff, 0x30) }, /* Fibocom FG150 Diag */ { USB_DEVICE_AND_INTERFACE_INFO(0x2cb7, 0x010b, 0xff, 0, 0) }, /* Fibocom FG150 AT */ { USB_DEVICE_INTERFACE_CLASS(0x2cb7, 0x01a0, 0xff) }, /* Fibocom NL668-AM/NL652-EU (laptop MBIM) */
Greg Kroah-Hartman
maintainerPATCH 18/19 ping: fix address binding wrt vrf
In reply to Greg Kroah-HartmanFrom: Nicolas Dichtel <[email protected]>
commit e1a7ac6f3ba6e157adcd0ca94d92a401f1943f56 upstream.
When ping_group_range is updated, 'ping' uses the DGRAM ICMP socket, instead of an IP raw socket. In this case, 'ping' is unable to bind its socket to a local address owned by a vrflite.
Before the patch:
$ sysctl -w net.ipv4.ping_group_range='0 2147483647' $ ip link add blue type vrf table 10 $ ip link add foo type dummy $ ip link set foo master blue $ ip link set foo up $ ip addr add 192.168.1.1/24 dev foo $ ip addr add 2001::1/64 dev foo $ ip vrf exec blue ping -c1 -I 192.168.1.1 192.168.1.2 ping: bind: Cannot assign requested address $ ip vrf exec blue ping6 -c1 -I 2001::1 2001::2 ping6: bind icmp socket: Cannot assign requested address
--- net/ipv4/ping.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
net/ipv4/ping.c +11 -1
@@ -302,6 +302,7 @@ static int ping_check_bind_addr(struct sstruct net *net =sock_net (sk);if (sk->sk_family ==AF_INET ) {struct sockaddr_in *addr = (struct sockaddr_in *) uaddr; +u32 tb_id =RT_TABLE_LOCAL ;int chk_addr_ret;if (addr_len <sizeof (*addr))
@@ -315,7 +316,8 @@ static int ping_check_bind_addr(struct spr_debug ("ping_check_bind_addr(sk=%p,addr=%pI4,port=%d)\n" , sk, &addr->sin_addr.s_addr,ntohs (addr->sin_port)); - chk_addr_ret =inet_addr_type (net, addr->sin_addr.s_addr); + tb_id =l3mdev_fib_table_by_index (net, sk->sk_bound_dev_if) ? : tb_id; + chk_addr_ret =inet_addr_type_table (net, addr->sin_addr.s_addr, tb_id);if (addr->sin_addr.s_addr ==htonl (INADDR_ANY )) chk_addr_ret =RTN_LOCAL ;
@@ -355,6 +357,14 @@ static int ping_check_bind_addr(struct sif (!dev) {rcu_read_unlock ();return -ENODEV ; + } + } + +if (!dev && sk->sk_bound_dev_if) { + dev =dev_get_by_index_rcu (net, sk->sk_bound_dev_if); +if (!dev) { +rcu_read_unlock (); +return -ENODEV ; } } has_addr = pingv6_ops.ipv6_chk_addr(net, &addr->sin6_addr, dev,
Greg Kroah-Hartman
maintainerPATCH 19/19 tty/serial: digicolor: fix possible null-ptr-deref in digicolor_uart_probe()
In reply to Greg Kroah-HartmanFrom: Yang Yingliang <[email protected]>
commit 447ee1516f19f534a228dda237eddb202f23e163 upstream.
It will cause null-ptr-deref when using 'res', if platform_get_resource() returns NULL, so move using 'res' after devm_ioremap_resource() that will check it to avoid null-ptr-deref.
And use devm_platform_get_and_ioremap_resource() to simplify code.
--- drivers/tty/serial/digicolor-usart.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/tty/serial/digicolor-usart.c +1 -1
@@ -476,10 +476,10 @@ static int digicolor_uart_probe(struct preturn PTR_ERR (uart_clk); res =platform_get_resource (pdev,IORESOURCE_MEM ,0 ); - dp->port.mapbase = res->start; dp->port.membase =devm_ioremap_resource (&pdev->dev, res);if (IS_ERR (dp->port.membase))return PTR_ERR (dp->port.membase); + dp->port.mapbase = res->start; irq =platform_get_irq (pdev,0 );if (irq <0 )
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.315 release. There are 19 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 Wed, 18 May 2022 19:36:02 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.315-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.9.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels:
Signature · 1 line
Florian
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.315 release. There are 19 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 Wed, 18 May 2022 19:36:02 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.315-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.9.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.315 release. There are 19 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 Wed, 18 May 2022 19:36:02 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.315-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.9.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v4.9:
8 builds: 8 pass, 0 fail
16 boots: 16 pass, 0 fail
32 tests: 32 pass, 0 failLinux version: 4.9.315-rc1-gf71a7b332169
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04
Jon
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.315 release. There are 19 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 Wed, 18 May 2022 19:36:02 +0000. Anything received after that time might be too late.
Build results:
total: 163 pass: 163 fail: 0 Qemu test results: total: 397 pass: 397 fail: 0
Guenter
Hi!
Quoted 4 lines
This is the start of the stable review cycle for the 4.9.315 release. There are 19 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.
CIP testing did not find any problems here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-4.9.y
Best regards,
Pavel
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.315 release. There are 19 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 Wed, 18 May 2022 19:36:02 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.315-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.9.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.
## Build
* kernel: 4.9.315-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git branch: linux-4.9.y
* git commit: f71a7b3321693ff2eb8f97a521ad23ca53934428
* git describe: v4.9.314-20-gf71a7b332169
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.9.y/build/v4.9.314-20-gf71a7b332169
## Test Regressions (compared to v4.9.313-8-g0d0d580b3778) No test regressions found.
## Metric Regressions (compared to v4.9.313-8-g0d0d580b3778) No metric regressions found.
## Test Fixes (compared to v4.9.313-8-g0d0d580b3778) No test fixes found.
## Metric Fixes (compared to v4.9.313-8-g0d0d580b3778) No metric fixes found.
## Test result summary
total: 80137, pass: 63338, fail: 858, skip: 13732, xfail: 2209
## Build Summary
* arm: 238 total, 238 passed, 0 failed
* arm64: 32 total, 32 passed, 0 failed
* dragonboard-410c: 1 total, 1 passed, 0 failed
* hi6220-hikey: 1 total, 1 passed, 0 failed
* i386: 19 total, 19 passed, 0 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 22 total, 22 passed, 0 failed
* sparc: 12 total, 12 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 31 total, 31 passed, 0 failed
## Test suites summary
* fwts
* igt-gpu-tools
* kselftest-android
* kselftest-arm64
* kselftest-bpf
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-inte[
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-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-tracing-tests
* network-basic-tests
* packetdrill
* perf
* ssuite
* v4l2-compliance
* vdso
--
Linaro LKFT
https://lkft.linaro.org