4.9.300-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainercover 4.9.300-rc1 review
This is the start of the stable review cycle for the 4.9.300 release. There are 48 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, 09 Feb 2022 10:37: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/v4.x/stable-review/patch-4.9.300-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.300-rc1
Ritesh Harjani <[email protected]>
ext4: fix error handling in ext4_restore_inline_data()
Sergey Shtylyov <[email protected]>
EDAC/xgene: Fix deferred probing
Sergey Shtylyov <[email protected]>
EDAC/altera: Fix deferred probing
Riwen Lu <[email protected]>
rtc: cmos: Evaluate century appropriate
Dai Ngo <[email protected]>
nfsd: nfsd4_setclientid_confirm mistakenly expires confirmed client.
John Meneghini <[email protected]>
scsi: bnx2fc: Make bnx2fc_recv_frame() mp safe
Miaoqian Lin <[email protected]>
ASoC: fsl: Add missing error handling in pcm030_fabric_probe
Lior Nahmanson <[email protected]>
net: macsec: Verify that send_sci is on when setting Tx sci explicitly
Miquel Raynal <[email protected]>
net: ieee802154: Return meaningful error codes from the netlink helpers
Benjamin Gaignard <[email protected]>
spi: mediatek: Avoid NULL pointer crash in interrupt
Kamal Dasu <[email protected]>
spi: bcm-qspi: check for valid cs before applying chip select
Joerg Roedel <[email protected]>
iommu/amd: Fix loop timeout issue in iommu_ga_log_enable()
Nick Lopez <[email protected]>
drm/nouveau: fix off by one in BIOS boundary checking
Mark Brown <[email protected]>
ASoC: ops: Reject out of bounds values in snd_soc_put_xr_sx()
Mark Brown <[email protected]>
ASoC: ops: Reject out of bounds values in snd_soc_put_volsw_sx()
Mark Brown <[email protected]>
ASoC: ops: Reject out of bounds values in snd_soc_put_volsw()
Eric Dumazet <[email protected]>
af_packet: fix data-race in packet_setsockopt / packet_setsockopt
Eric Dumazet <[email protected]>
rtnetlink: make sure to refresh master_dev/m_ops in __rtnl_newlink()
Shyam Sundar S K <[email protected]>
net: amd-xgbe: Fix skb data length underflow
Raju Rangoju <[email protected]>
net: amd-xgbe: ensure to reset the tx_timer_active flag
Georgi Valkov <[email protected]>
ipheth: fix EOVERFLOW in ipheth_rcvbulk_callback
Florian Westphal <[email protected]>
netfilter: nat: limit port clash resolution attempts
Florian Westphal <[email protected]>
netfilter: nat: remove l4 protocol port rovers
Eric Dumazet <[email protected]>
ipv4: tcp: send zero IPID in SYNACK messages
Eric Dumazet <[email protected]>
ipv4: raw: lock the socket in raw_bind()
Guenter Roeck <[email protected]>
hwmon: (lm90) Reduce maximum conversion rate for G781
Xianting Tian <[email protected]>
drm/msm: Fix wrong size calculation
Jianguo Wu <[email protected]>
net-procfs: show net devices bound packet types
Trond Myklebust <[email protected]>
NFSv4: nfs_atomic_open() can race when looking up a non-regular file
Trond Myklebust <[email protected]>
NFSv4: Handle case where the lookup of a directory fails
Eric Dumazet <[email protected]>
ipv4: avoid using shared IP generator for connected sockets
Congyu Liu <[email protected]>
net: fix information leakage in /proc/net/ptype
Ido Schimmel <[email protected]>
ipv6_tunnel: Rate limit warning messages
John Meneghini <[email protected]>
scsi: bnx2fc: Flush destroy_work queue before calling bnx2fc_interface_put()
Christophe Leroy <[email protected]>
powerpc/32: Fix boot failure with GCC latent entropy plugin
Alan Stern <[email protected]>
USB: core: Fix hang in usb_kill_urb by adding memory barriers
Pavankumar Kondeti <[email protected]>
usb: gadget: f_sourcesink: Fix isoc transfer for USB_SPEED_SUPER_PLUS
Alan Stern <[email protected]>
usb-storage: Add unusual-devs entry for VL817 USB-SATA bridge
Cameron Williams <[email protected]>
tty: Add support for Brainboxes UC cards.
[email protected] <[email protected]>
tty: n_gsm: fix SW flow control encoding/handling
Valentin Caron <[email protected]>
serial: stm32: fix software flow control transfer
Greg Kroah-Hartman <[email protected]>
PM: wakeup: simplify the output logic of pm_show_wakelocks()
Jan Kara <[email protected]>
udf: Fix NULL ptr deref when converting from inline format
Jan Kara <[email protected]>
udf: Restore i_lenAlloc when inode expansion fails
Steffen Maier <[email protected]>
scsi: zfcp: Fix failed recovery on gone remote port with non-NPIV FCP devices
Vasily Gorbik <[email protected]>
s390/hypfs: include z/VM guests with access control group set
Brian Gix <[email protected]>
Bluetooth: refactor malicious adv data check
Ziyang Xuan <[email protected]>
can: bcm: fix UAF of bcm op
-------------
Diffstat:
Makefile | 4 +- arch/powerpc/kernel/Makefile | 1 + arch/powerpc/lib/Makefile | 3 + arch/s390/hypfs/hypfs_vm.c | 6 +- drivers/edac/altera_edac.c | 2 +- drivers/edac/xgene_edac.c | 2 +- drivers/gpu/drm/msm/msm_drv.c | 2 +- drivers/gpu/drm/nouveau/nvkm/subdev/bios/base.c | 2 +- drivers/hwmon/lm90.c | 2 +- drivers/iommu/amd_iommu_init.c | 2 + drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 14 +++- drivers/net/macsec.c | 9 +++ drivers/net/usb/ipheth.c | 6 +- drivers/rtc/rtc-mc146818-lib.c | 2 +- drivers/s390/scsi/zfcp_fc.c | 13 ++- drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 41 +++++----- drivers/spi/spi-bcm-qspi.c | 2 +- drivers/spi/spi-mt65xx.c | 2 +- drivers/tty/n_gsm.c | 4 +- drivers/tty/serial/8250/8250_pci.c | 100 +++++++++++++++++++++++- drivers/tty/serial/stm32-usart.c | 2 +- drivers/usb/core/hcd.c | 14 ++++ drivers/usb/core/urb.c | 12 +++ drivers/usb/gadget/function/f_sourcesink.c | 1 + drivers/usb/storage/unusual_devs.h | 10 +++ fs/ext4/inline.c | 10 ++- fs/nfs/dir.c | 18 +++++ fs/nfsd/nfs4state.c | 4 +- fs/udf/inode.c | 9 +-- include/linux/netdevice.h | 1 + include/net/ip.h | 21 +++-- include/net/netfilter/nf_nat_l4proto.h | 2 +- kernel/power/wakelock.c | 12 +-- net/bluetooth/hci_event.c | 10 +-- net/can/bcm.c | 20 ++--- net/core/net-procfs.c | 38 ++++++++- net/core/rtnetlink.c | 6 +- net/ieee802154/nl802154.c | 8 +- net/ipv4/ip_output.c | 11 ++- net/ipv4/raw.c | 5 +- net/ipv6/ip6_tunnel.c | 8 +- net/netfilter/nf_nat_proto_common.c | 36 ++++++--- net/netfilter/nf_nat_proto_dccp.c | 5 +- net/netfilter/nf_nat_proto_sctp.c | 5 +- net/netfilter/nf_nat_proto_tcp.c | 5 +- net/netfilter/nf_nat_proto_udp.c | 5 +- net/netfilter/nf_nat_proto_udplite.c | 5 +- net/packet/af_packet.c | 10 ++- sound/soc/fsl/pcm030-audio-fabric.c | 11 ++- sound/soc/soc-ops.c | 29 ++++++- 50 files changed, 410 insertions(+), 142 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/48 can: bcm: fix UAF of bcm op
From: Ziyang Xuan <[email protected]>
Stopping tasklet and hrtimer rely on the active state of tasklet and hrtimer sequentially in bcm_remove_op(), the op object will be freed if they are all unactive. Assume the hrtimer timeout is short, the hrtimer cb has been excuted after tasklet conditional judgment which must be false after last round tasklet_kill() and before condition hrtimer_active(), it is false when execute to hrtimer_active(). Bug is triggerd, because the stopping action is end and the op object will be freed, but the tasklet is scheduled. The resources of the op object will occur UAF bug.
Move hrtimer_cancel() behind tasklet_kill() and switch 'while () {...}' to 'do {...} while ()' to fix the op UAF problem.
--- net/can/bcm.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-)
net/can/bcm.c +10 -10
@@ -761,21 +761,21 @@ static struct bcm_op *bcm_find_op(structstatic void bcm_remove_op (struct bcm_op *op) {if (op->tsklet.func) { -while (test_bit (TASKLET_STATE_SCHED , &op->tsklet.state) || -test_bit (TASKLET_STATE_RUN , &op->tsklet.state) || -hrtimer_active (&op->timer)) { -hrtimer_cancel (&op->timer); +do {tasklet_kill (&op->tsklet); - } +hrtimer_cancel (&op->timer); + }while (test_bit (TASKLET_STATE_SCHED , &op->tsklet.state) || +test_bit (TASKLET_STATE_RUN , &op->tsklet.state) || +hrtimer_active (&op->timer)); }if (op->thrtsklet.func) { -while (test_bit (TASKLET_STATE_SCHED , &op->thrtsklet.state) || -test_bit (TASKLET_STATE_RUN , &op->thrtsklet.state) || -hrtimer_active (&op->thrtimer)) { -hrtimer_cancel (&op->thrtimer); +do {tasklet_kill (&op->thrtsklet); - } +hrtimer_cancel (&op->thrtimer); + }while (test_bit (TASKLET_STATE_SCHED , &op->thrtsklet.state) || +test_bit (TASKLET_STATE_RUN , &op->thrtsklet.state) || +hrtimer_active (&op->thrtimer)); }if ((op->frames) && (op->frames != &op->sframe))
Greg Kroah-Hartman
maintainerPATCH 2/48 Bluetooth: refactor malicious adv data check
In reply to Greg Kroah-HartmanFrom: Brian Gix <[email protected]>
commit 899663be5e75dc0174dc8bda0b5e6826edf0b29a upstream.
Check for out-of-bound read was being performed at the end of while num_reports loop, and would fill journal with false positives. Added check to beginning of loop processing so that it doesn't get checked after ptr has been advanced.
--- net/bluetooth/hci_event.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
net/bluetooth/hci_event.c +5 -5
@@ -4967,6 +4967,11 @@ static void hci_le_adv_report_evt(structstruct hci_ev_le_advertising_info *ev = ptr;s8 rssi; +if (ptr > (void *)skb_tail_pointer (skb) -sizeof (*ev)) { +bt_dev_err (hdev,"Malicious advertising data." ); +break ; + } +if (ev->length <=HCI_MAX_AD_LENGTH && ev->data + ev->length <=skb_tail_pointer (skb)) { rssi = ev->data[ev->length];
@@ -4978,11 +4983,6 @@ static void hci_le_adv_report_evt(struct } ptr +=sizeof (*ev) + ev->length +1 ; - -if (ptr > (void *)skb_tail_pointer (skb) -sizeof (*ev)) { -bt_dev_err (hdev,"Malicious advertising data. Stopping processing" ); -break ; - } }hci_dev_unlock (hdev);
Greg Kroah-Hartman
maintainerPATCH 3/48 s390/hypfs: include z/VM guests with access control group set
In reply to Greg Kroah-HartmanFrom: Vasily Gorbik <[email protected]>
commit 663d34c8df98740f1e90241e78e456d00b3c6cad upstream.
Currently if z/VM guest is allowed to retrieve hypervisor performance data globally for all guests (privilege class B) the query is formed in a way to include all guests but the group name is left empty. This leads to that z/VM guests which have access control group set not being included in the results (even local vm).
Change the query group identifier from empty to "any" to retrieve information about all guests from any groups (or without a group set).
--- arch/s390/hypfs/hypfs_vm.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
arch/s390/hypfs/hypfs_vm.c +4 -2
@@ -19,6 +19,7 @@static char local_guest[] =" " ;static char all_guests[] ="* " ; +static char *all_groups = all_guests;static char *guest_query;struct diag2fc_data {
@@ -61,10 +62,11 @@ static int diag2fc(int size, char* querymemcpy (parm_list.userid, query,NAME_LEN );ASCEBC (parm_list.userid,NAME_LEN ); - parm_list.addr = (unsigned long ) addr ; +memcpy (parm_list.aci_grp, all_groups,NAME_LEN ); +ASCEBC (parm_list.aci_grp,NAME_LEN ); + parm_list.addr = (unsigned long )addr; parm_list.size = size; parm_list.fmt =0x02 ; -memset (parm_list.aci_grp,0x40 ,NAME_LEN ); rc =-1 ;diag_stat_inc (DIAG_STAT_X2FC );
Greg Kroah-Hartman
maintainerPATCH 4/48 scsi: zfcp: Fix failed recovery on gone remote port with non-NPIV FCP devices
In reply to Greg Kroah-HartmanFrom: Steffen Maier <[email protected]>
commit 8c9db6679be4348b8aae108e11d4be2f83976e30 upstream.
Suppose we have an environment with a number of non-NPIV FCP devices (virtual HBAs / FCP devices / zfcp "adapter"s) sharing the same physical FCP channel (HBA port) and its I_T nexus. Plus a number of storage target ports zoned to such shared channel. Now one target port logs out of the fabric causing an RSCN. Zfcp reacts with an ADISC ELS and subsequent port recovery depending on the ADISC result. This happens on all such FCP devices (in different Linux images) concurrently as they all receive a copy of this RSCN. In the following we look at one of those FCP devices.
Requests other than FSF_QTCB_FCP_CMND can be slow until they get a response.
Depending on which requests are affected by slow responses, there are different recovery outcomes. Here we want to fix failed recoveries on port or adapter level by avoiding recovery requests that can be slow.
We need the cached N_Port_ID for the remote port "link" test with ADISC. Just before sending the ADISC, we now intentionally forget the old cached N_Port_ID. The idea is that on receiving an RSCN for a port, we have to assume that any cached information about this port is stale. This forces a fresh new GID_PN [FC-GS] nameserver lookup on any subsequent recovery for the same port. Since we typically can still communicate with the nameserver efficiently, we now reach steady state quicker: Either the nameserver still does not know about the port so we stop recovery, or the nameserver already knows the port potentially with a new N_Port_ID and we can successfully and quickly perform open port recovery. For the one case, where ADISC returns successfully, we re-initialize port->d_id because that case does not involve any port recovery.
This also solves a problem if the storage WWPN quickly logs into the fabric again but with a different N_Port_ID. Such as on virtual WWPN takeover during target NPIV failover.
[https://www.redbooks.ibm.com/abstracts/redp5477.html] In that case the RSCN from the storage FDISC was ignored by zfcp and we could not successfully recover the failover. On some later failback on the storage, we could have been lucky if the virtual WWPN got the same old N_Port_ID from the SAN switch as we still had cached. Then the related RSCN triggered a successful port reopen recovery. However, there is no guarantee to get the same N_Port_ID on NPIV FDISC.
Even though NPIV-enabled FCP devices are not affected by this problem, this code change optimizes recovery time for gone remote ports as a side effect. The timely drop of cached N_Port_IDs prevents unnecessary slow open port attempts.
While the problem might have been in code before v2.6.32 commit 799b76d09aee ("[SCSI] zfcp: Decouple gid_pn requests from erp") this fix depends on the gid_pn_work introduced with that commit, so we mark it as culprit to satisfy fix dependencies.
Note: Point-to-point remote port is already handled separately and gets its N_Port_ID from the cached peer_d_id. So resetting port->d_id in general does not affect PtP.
--- drivers/s390/scsi/zfcp_fc.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
drivers/s390/scsi/zfcp_fc.c +12 -1
@@ -518,6 +518,8 @@ static void zfcp_fc_adisc_handler(void * goto out; } +/* re-init to undo drop from zfcp_fc_adisc() */ + port->d_id =ntoh24 (adisc_resp->adisc_port_id);/* port is good, unblock rport without going through erp */ zfcp_scsi_schedule_rport_register (port); out:
@@ -531,6 +533,7 @@ static int zfcp_fc_adisc(struct zfcp_porstruct zfcp_fc_req *fc_req;struct zfcp_adapter *adapter = port->adapter;struct Scsi_Host *shost = adapter->scsi_host; +u32 d_id;int ret; fc_req =kmem_cache_zalloc (zfcp_fc_req_cache,GFP_ATOMIC );
@@ -555,7 +558,15 @@ static int zfcp_fc_adisc(struct zfcp_por fc_req->u.adisc.req.adisc_cmd =ELS_ADISC ;hton24 (fc_req->u.adisc.req.adisc_port_id,fc_host_port_id (shost)); - ret =zfcp_fsf_send_els (adapter, port->d_id, &fc_req->ct_els, + d_id = port->d_id;/* remember as destination for send els below */ +/* +* Force fresh GID_PN lookup on next port recovery. +* Must happen after request setup and before sending request, +* to prevent race with port->d_id re-init in zfcp_fc_adisc_handler(). +*/ + port->d_id =0 ; + + ret =zfcp_fsf_send_els (adapter, d_id, &fc_req->ct_els,ZFCP_FC_CTELS_TMO );if (ret)kmem_cache_free (zfcp_fc_req_cache, fc_req);
Greg Kroah-Hartman
maintainerPATCH 5/48 udf: Restore i_lenAlloc when inode expansion fails
In reply to Greg Kroah-HartmanFrom: Jan Kara <[email protected]>
commit ea8569194b43f0f01f0a84c689388542c7254a1f upstream.
When we fail to expand inode from inline format to a normal format, we restore inode to contain the original inline formatting but we forgot to set i_lenAlloc back. The mismatch between i_lenAlloc and i_size was then causing further problems such as warnings and lost data down the line.
--- fs/udf/inode.c | 1 + 1 file changed, 1 insertion(+)
fs/udf/inode.c +1 -0
@@ -319,6 +319,7 @@ int udf_expand_file_adinicb(struct inodeunlock_page (page); iinfo->i_alloc_type =ICBTAG_FLAG_AD_IN_ICB ; inode->i_data.a_ops = &udf_adinicb_aops; + iinfo->i_lenAlloc = inode->i_size;up_write (&iinfo->i_data_sem); }put_page (page);
Greg Kroah-Hartman
maintainerPATCH 6/48 udf: Fix NULL ptr deref when converting from inline format
In reply to Greg Kroah-HartmanFrom: Jan Kara <[email protected]>
commit 7fc3b7c2981bbd1047916ade327beccb90994eee upstream.
udf_expand_file_adinicb() calls directly ->writepage to write data expanded into a page. This however misses to setup inode for writeback properly and so we can crash on inode->i_wb dereference when submitting page for IO like:
BUG: kernel NULL pointer dereference, address: 0000000000000158 #PF: supervisor read access in kernel mode ... <TASK> __folio_start_writeback+0x2ac/0x350 __block_write_full_page+0x37d/0x490 udf_expand_file_adinicb+0x255/0x400 [udf] udf_file_write_iter+0xbe/0x1b0 [udf] new_sync_write+0x125/0x1c0 vfs_write+0x28e/0x400
Fix the problem by marking the page dirty and going through the standard writeback path to write the page. Strictly speaking we would not even have to write the page but we want to catch e.g. ENOSPC errors early.
--- fs/udf/inode.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-)
fs/udf/inode.c +3 -5
@@ -259,10 +259,6 @@ int udf_expand_file_adinicb(struct inodechar *kaddr;struct udf_inode_info *iinfo =UDF_I (inode);int err; -struct writeback_control udf_wbc = { - .sync_mode =WB_SYNC_NONE , - .nr_to_write =1 , - };WARN_ON_ONCE (!inode_is_locked (inode));if (!iinfo->i_lenAlloc) {
@@ -306,8 +302,10 @@ int udf_expand_file_adinicb(struct inode iinfo->i_alloc_type =ICBTAG_FLAG_AD_LONG ;/* from now on we have normal address_space methods */ inode->i_data.a_ops = &udf_aops; +set_page_dirty (page); +unlock_page (page);up_write (&iinfo->i_data_sem); - err = inode->i_data.a_ops->writepage (page, &udf_wbc); + err =filemap_fdatawrite (inode->i_mapping);if (err) {/* Restore everything back so that we don't lose data... */ lock_page (page);
Greg Kroah-Hartman
maintainerPATCH 7/48 PM: wakeup: simplify the output logic of pm_show_wakelocks()
In reply to Greg Kroah-HartmanFrom: Greg Kroah-Hartman <[email protected]>
commit c9d967b2ce40d71e968eb839f36c936b8a9cf1ea upstream.
The buffer handling in pm_show_wakelocks() is tricky, and hopefully correct. Ensure it really is correct by using sysfs_emit_at() which handles all of the tricky string handling logic in a PAGE_SIZE buffer for us automatically as this is a sysfs file being read from.
--- kernel/power/wakelock.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-)
kernel/power/wakelock.c +4 -8
@@ -38,23 +38,19 @@ ssize_t pm_show_wakelocks(char *buf, boo {struct rb_node *node;struct wakelock *wl; -char *str = buf; -char *end = buf +PAGE_SIZE ; +int len =0 ;mutex_lock (&wakelocks_lock);for (node =rb_first (&wakelocks_tree); node; node =rb_next (node)) { wl = rb_entry(node, struct wakelock, node);if (wl->ws.active == show_active) - str +=scnprintf (str, end - str,"%s " , wl->name); + len +=sysfs_emit_at (buf, len,"%s " , wl->name); } -if (str > buf) - str--; - - str +=scnprintf (str, end - str,"\n" ); + len +=sysfs_emit_at (buf, len,"\n" );mutex_unlock (&wakelocks_lock); -return (str - buf); +return len; }#if CONFIG_PM_WAKELOCKS_LIMIT >0
Greg Kroah-Hartman
maintainerPATCH 8/48 serial: stm32: fix software flow control transfer
In reply to Greg Kroah-HartmanFrom: Valentin Caron <[email protected]>
commit 037b91ec7729524107982e36ec4b40f9b174f7a2 upstream.
x_char is ignored by stm32_usart_start_tx() when xmit buffer is empty.
Fix start_tx condition to allow x_char to be sent.
--- drivers/tty/serial/stm32-usart.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/tty/serial/stm32-usart.c +1 -1
@@ -389,7 +389,7 @@ static void stm32_start_tx(struct uart_p {struct circ_buf *xmit = &port->state->xmit; -if (uart_circ_empty (xmit)) +if (uart_circ_empty (xmit) && !port->x_char)return ;stm32_transmit_chars (port);
Greg Kroah-Hartman
maintainerPATCH 9/48 tty: n_gsm: fix SW flow control encoding/handling
In reply to Greg Kroah-HartmanFrom: [email protected] <[email protected]>
commit 8838b2af23caf1ff0610caef2795d6668a013b2d upstream.
n_gsm is based on the 3GPP 07.010 and its newer version is the 3GPP 27.010.
See https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1516
The changes from 07.010 to 27.010 are non-functional. Therefore, I refer to
the newer 27.010 here. Chapter 5.2.7.3 states that DC1 (XON) and DC3 (XOFF)
are the control characters defined in ISO/IEC 646. These shall be quoted if
seen in the data stream to avoid interpretation as flow control characters.
ISO/IEC 646 refers to the set of ISO standards described as the ISO 7-bit coded character set for information interchange. Its final version is also known as ITU T.50.
See https://www.itu.int/rec/T-REC-T.50-199209-I/en
To abide the standard it is needed to quote DC1 and DC3 correctly if these are seen as data bytes and not as control characters. The current implementation already tries to enforce this but fails to catch all defined cases. 3GPP 27.010 chapter 5.2.7.3 clearly states that the most significant bit shall be ignored for DC1 and DC3 handling. The current implementation handles only the case with the most significant bit set 0. Cases in which DC1 and DC3 have the most significant bit set 1 are left unhandled.
This patch fixes this by masking the data bytes with ISO_IEC_646_MASK (only the 7 least significant bits set 1) before comparing them with XON (a.k.a. DC1) and XOFF (a.k.a. DC3) when testing which byte values need quotation via byte stuffing.
--- drivers/tty/n_gsm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/tty/n_gsm.c +3 -1
@@ -329,6 +329,7 @@ static struct tty_driver *gsm_tty_driver#define GSM1_ESCAPE_BITS 0x20#define XON 0x11#define XOFF 0x13 +#define ISO_IEC_646_MASK 0x7Fstatic const struct tty_port_operations gsm_port_ops;
@@ -547,7 +548,8 @@ static int gsm_stuff_frame(const u8 *inpint olen =0 ;while (len--) {if (*input ==GSM1_SOF || *input ==GSM1_ESCAPE - || *input ==XON || *input ==XOFF ) { + || (*input &ISO_IEC_646_MASK ) ==XON + || (*input &ISO_IEC_646_MASK ) ==XOFF ) { *output++ =GSM1_ESCAPE ; *output++ = *input++ ^GSM1_ESCAPE_BITS ; olen++;
Greg Kroah-Hartman
maintainerPATCH 10/48 tty: Add support for Brainboxes UC cards.
In reply to Greg Kroah-HartmanFrom: Cameron Williams <[email protected]>
commit 152d1afa834c84530828ee031cf07a00e0fc0b8c upstream.
This commit adds support for the some of the Brainboxes PCI range of cards, including the UC-101, UC-235/246, UC-257, UC-268, UC-275/279, UC-302, UC-310, UC-313, UC-320/324, UC-346, UC-357, UC-368 and UC-420/431.
--- drivers/tty/serial/8250/8250_pci.c | 100 ++++++++++++++++++++++++++++++++++++- 1 file changed, 98 insertions(+), 2 deletions(-)
drivers/tty/serial/8250/8250_pci.c +98 -2
@@ -5238,8 +5238,30 @@ static struct pci_device_id serial_pci_t {PCI_VENDOR_ID_INTASHIELD ,PCI_DEVICE_ID_INTASHIELD_IS400 ,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 ,/* 135a.0dc0 */ pbn_b2_4_115200 }, +/* Brainboxes Devices */ /* -* BrainBoxes UC-260 +* Brainboxes UC-101 +*/ + { PCI_VENDOR_ID_INTASHIELD, 0x0BA1, +PCI_ANY_ID ,PCI_ANY_ID , +0 ,0 , + pbn_b2_2_115200 }, +/* +* Brainboxes UC-235/246 +*/ + { PCI_VENDOR_ID_INTASHIELD, 0x0AA1, +PCI_ANY_ID ,PCI_ANY_ID , +0 ,0 , + pbn_b2_1_115200 }, +/* +* Brainboxes UC-257 +*/ + { PCI_VENDOR_ID_INTASHIELD, 0x0861, +PCI_ANY_ID ,PCI_ANY_ID , +0 ,0 , + pbn_b2_2_115200 }, +/* +* Brainboxes UC-260/271/701/756 */ { PCI_VENDOR_ID_INTASHIELD, 0x0D21, PCI_ANY_ID, PCI_ANY_ID,
@@ -5247,7 +5269,81 @@ static struct pci_device_id serial_pci_t pbn_b2_4_115200 }, {PCI_VENDOR_ID_INTASHIELD ,0x0E34 ,PCI_ANY_ID ,PCI_ANY_ID , -PCI_CLASS_COMMUNICATION_MULTISERIAL <<8 ,0xffff00 , +PCI_CLASS_COMMUNICATION_MULTISERIAL <<8 ,0xffff00 , + pbn_b2_4_115200 }, +/* +* Brainboxes UC-268 +*/ + { PCI_VENDOR_ID_INTASHIELD, 0x0841, +PCI_ANY_ID ,PCI_ANY_ID , +0 ,0 , + pbn_b2_4_115200 }, +/* +* Brainboxes UC-275/279 +*/ + { PCI_VENDOR_ID_INTASHIELD, 0x0881, +PCI_ANY_ID ,PCI_ANY_ID , +0 ,0 , + pbn_b2_8_115200 }, +/* +* Brainboxes UC-302 +*/ + { PCI_VENDOR_ID_INTASHIELD, 0x08E1, +PCI_ANY_ID ,PCI_ANY_ID , +0 ,0 , + pbn_b2_2_115200 }, +/* +* Brainboxes UC-310 +*/ + { PCI_VENDOR_ID_INTASHIELD, 0x08C1, +PCI_ANY_ID ,PCI_ANY_ID , +0 ,0 , + pbn_b2_2_115200 }, +/* +* Brainboxes UC-313 +*/ + { PCI_VENDOR_ID_INTASHIELD, 0x08A3, +PCI_ANY_ID ,PCI_ANY_ID , +0 ,0 , + pbn_b2_2_115200 }, +/* +* Brainboxes UC-320/324 +*/ + { PCI_VENDOR_ID_INTASHIELD, 0x0A61, +PCI_ANY_ID ,PCI_ANY_ID , +0 ,0 , + pbn_b2_1_115200 }, +/* +* Brainboxes UC-346 +*/ + { PCI_VENDOR_ID_INTASHIELD, 0x0B02, +PCI_ANY_ID ,PCI_ANY_ID , +0 ,0 , + pbn_b2_4_115200 }, +/* +* Brainboxes UC-357 +*/ + { PCI_VENDOR_ID_INTASHIELD, 0x0A81, +PCI_ANY_ID ,PCI_ANY_ID , +0 ,0 , + pbn_b2_2_115200 }, + { PCI_VENDOR_ID_INTASHIELD, 0x0A83, +PCI_ANY_ID ,PCI_ANY_ID , +0 ,0 , + pbn_b2_2_115200 }, +/* +* Brainboxes UC-368 +*/ + { PCI_VENDOR_ID_INTASHIELD, 0x0C41, +PCI_ANY_ID ,PCI_ANY_ID , +0 ,0 , + pbn_b2_4_115200 }, +/* +* Brainboxes UC-420/431 +*/ + { PCI_VENDOR_ID_INTASHIELD, 0x0921, +PCI_ANY_ID ,PCI_ANY_ID , +0 ,0 , pbn_b2_4_115200 },/* * Perle PCI-RAS cards
Greg Kroah-Hartman
maintainerPATCH 11/48 usb-storage: Add unusual-devs entry for VL817 USB-SATA bridge
In reply to Greg Kroah-HartmanFrom: Alan Stern <[email protected]>
commit 5b67b315037250a61861119683e7fcb509deea25 upstream.
Two people have reported (and mentioned numerous other reports on the web) that VIA's VL817 USB-SATA bridge does not work with the uas driver. Typical log messages are:
[ 3606.232149] sd 14:0:0:0: [sdg] tag#2 uas_zap_pending 0 uas-tag 1 inflight: CMD [ 3606.232154] sd 14:0:0:0: [sdg] tag#2 CDB: Write(16) 8a 00 00 00 00 00 18 0c c9 80 00 00 00 80 00 00 [ 3606.306257] usb 4-4.4: reset SuperSpeed Plus Gen 2x1 USB device number 11 using xhci_hcd [ 3606.328584] scsi host14: uas_eh_device_reset_handler success
Surprisingly, the devices do seem to work okay for some other people. The cause of the differing behaviors is not known.
In the hope of getting the devices to work for the most users, even at the possible cost of degraded performance for some, this patch adds an unusual_devs entry for the VL817 to block it from binding to the uas driver by default. Users will be able to override this entry by means of a module parameter, if they want.
--- drivers/usb/storage/unusual_devs.h | 10 ++++++++++ 1 file changed, 10 insertions(+)
drivers/usb/storage/unusual_devs.h +10 -0
@@ -2308,6 +2308,16 @@ UNUSUAL_DEV( 0x2027, 0xa001, 0x0000, 0x USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_euscsi_init, US_FL_SCM_MULT_TARG ), +/* +* Reported by DocMAX <[email protected]> +* and Thomas Weißschuh <[email protected]> +*/ +UNUSUAL_DEV (0x2109 ,0x0715 ,0x9999 ,0x9999 , +"VIA Labs, Inc." , +"VL817 SATA Bridge" , +USB_SC_DEVICE ,USB_PR_DEVICE ,NULL , +US_FL_IGNORE_UAS ), + UNUSUAL_DEV( 0x2116, 0x0320, 0x0001, 0x0001, "ST", "2A",
Greg Kroah-Hartman
maintainerPATCH 12/48 usb: gadget: f_sourcesink: Fix isoc transfer for USB_SPEED_SUPER_PLUS
In reply to Greg Kroah-HartmanFrom: Pavankumar Kondeti <[email protected]>
commit 904edf8aeb459697129be5fde847e2a502f41fd9 upstream.
Currently when gadget enumerates in super speed plus, the isoc endpoint request buffer size is not calculated correctly. Fix this by checking the gadget speed against USB_SPEED_SUPER_PLUS and update the request buffer size.
--- drivers/usb/gadget/function/f_sourcesink.c | 1 + 1 file changed, 1 insertion(+)
drivers/usb/gadget/function/f_sourcesink.c +1 -0
@@ -587,6 +587,7 @@ static int source_sink_start_ep(struct fif (is_iso) {switch (speed) { +case USB_SPEED_SUPER_PLUS :case USB_SPEED_SUPER : size = ss->isoc_maxpacket * (ss->isoc_mult + 1) *
Greg Kroah-Hartman
maintainerPATCH 13/48 USB: core: Fix hang in usb_kill_urb by adding memory barriers
In reply to Greg Kroah-HartmanFrom: Alan Stern <[email protected]>
commit 26fbe9772b8c459687930511444ce443011f86bf upstream.
The syzbot fuzzer has identified a bug in which processes hang waiting for usb_kill_urb() to return. It turns out the issue is not unlinking the URB; that works just fine. Rather, the problem arises when the wakeup notification that the URB has completed is not received.
The reason is memory-access ordering on SMP systems. In outline form, usb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on different CPUs perform the following actions:
CPU 0 CPU 1
---------------------------- ---------------------------------usb_kill_urb(): __usb_hcd_giveback_urb():
... ...
atomic_inc(&urb->reject); atomic_dec(&urb->use_count);
... ...
wait_event(usb_kill_urb_queue,
atomic_read(&urb->use_count) == 0); if (atomic_read(&urb->reject)) wake_up(&usb_kill_urb_queue);
Confining your attention to urb->reject and urb->use_count, you can see that the overall pattern of accesses on CPU 0 is:
write urb->reject, then read urb->use_count;
whereas the overall pattern of accesses on CPU 1 is:
write urb->use_count, then read urb->reject.
This pattern is referred to in memory-model circles as SB (for "Store Buffering"), and it is well known that without suitable enforcement of the desired order of accesses -- in the form of memory barriers -- it is entirely possible for one or both CPUs to execute their reads ahead of their writes. The end result will be that sometimes CPU 0 sees the old un-decremented value of urb->use_count while CPU 1 sees the old un-incremented value of urb->reject. Consequently CPU 0 ends up on the wait queue and never gets woken up, leading to the observed hang in usb_kill_urb().
The same pattern of accesses occurs in usb_poison_urb() and the failure pathway of usb_hcd_submit_urb().
The problem is fixed by adding suitable memory barriers. To provide proper memory-access ordering in the SB pattern, a full barrier is required on both CPUs. The atomic_inc() and atomic_dec() accesses themselves don't provide any memory ordering, but since they are present, we can use the optimized smp_mb__after_atomic() memory barrier in the various routines to obtain the desired effect.
This patch adds the necessary memory barriers.
--- drivers/usb/core/hcd.c | 14 ++++++++++++++ drivers/usb/core/urb.c | 12 ++++++++++++ 2 files changed, 26 insertions(+)
drivers/usb/core/hcd.c +14 -0
@@ -1668,6 +1668,13 @@ int usb_hcd_submit_urb (struct urb *urb, urb->hcpriv =NULL ;INIT_LIST_HEAD (&urb->urb_list);atomic_dec (&urb->use_count); +/* +* Order the write of urb->use_count above before the read +* of urb->reject below. Pairs with the memory barriers in +* usb_kill_urb() and usb_poison_urb(). +*/ +smp_mb__after_atomic (); +atomic_dec (&urb->dev->urbnum);if (atomic_read (&urb->reject))wake_up (&usb_kill_urb_queue);
@@ -1777,6 +1784,13 @@ static void __usb_hcd_giveback_urb(strucusb_anchor_resume_wakeups (anchor);atomic_dec (&urb->use_count); +/* +* Order the write of urb->use_count above before the read +* of urb->reject below. Pairs with the memory barriers in +* usb_kill_urb() and usb_poison_urb(). +*/ +smp_mb__after_atomic (); +if (unlikely (atomic_read (&urb->reject)))wake_up (&usb_kill_urb_queue);usb_put_urb (urb);
drivers/usb/core/urb.c +12 -0
@@ -684,6 +684,12 @@ void usb_kill_urb(struct urb *urb)if (!(urb && urb->dev && urb->ep))return ;atomic_inc (&urb->reject); +/* +* Order the write of urb->reject above before the read +* of urb->use_count below. Pairs with the barriers in +* __usb_hcd_giveback_urb() and usb_hcd_submit_urb(). +*/ +smp_mb__after_atomic ();usb_hcd_unlink_urb (urb, -ENOENT );wait_event (usb_kill_urb_queue,atomic_read (&urb->use_count) ==0 );
@@ -725,6 +731,12 @@ void usb_poison_urb(struct urb *urb)if (!urb)return ;atomic_inc (&urb->reject); +/* +* Order the write of urb->reject above before the read +* of urb->use_count below. Pairs with the barriers in +* __usb_hcd_giveback_urb() and usb_hcd_submit_urb(). +*/ +smp_mb__after_atomic ();if (!urb->dev || !urb->ep)return ;
Greg Kroah-Hartman
maintainerPATCH 14/48 powerpc/32: Fix boot failure with GCC latent entropy plugin
In reply to Greg Kroah-HartmanFrom: Christophe Leroy <[email protected]>
commit bba496656a73fc1d1330b49c7f82843836e9feb1 upstream.
Boot fails with GCC latent entropy plugin enabled.
This is due to early boot functions trying to access 'latent_entropy' global data while the kernel is not relocated at its final destination yet.
As there is no way to tell GCC to use PTRRELOC() to access it, disable latent entropy plugin in early_32.o and feature-fixups.o and code-patching.o
--- arch/powerpc/kernel/Makefile | 1 + arch/powerpc/lib/Makefile | 3 +++ 2 files changed, 4 insertions(+)
arch/powerpc/kernel/Makefile +1 -0
@@ -14,6 +14,7 @@ CFLAGS_prom_init.o += -fPIC CFLAGS_btext.o += -fPIC endif +CFLAGS_setup_32.o += $(DISABLE_LATENT_ENTROPY_PLUGIN) CFLAGS_cputable.o += $(DISABLE_LATENT_ENTROPY_PLUGIN) CFLAGS_prom_init.o += $(DISABLE_LATENT_ENTROPY_PLUGIN) CFLAGS_btext.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
arch/powerpc/lib/Makefile +3 -0
@@ -9,6 +9,9 @@ ccflags-$(CONFIG_PPC64) := $(NO_MINIMAL_ CFLAGS_REMOVE_code-patching.o = $(CC_FLAGS_FTRACE) CFLAGS_REMOVE_feature-fixups.o = $(CC_FLAGS_FTRACE) +CFLAGS_code-patching.o += $(DISABLE_LATENT_ENTROPY_PLUGIN) +CFLAGS_feature-fixups.o += $(DISABLE_LATENT_ENTROPY_PLUGIN) + obj-y += string.o alloc.o crtsavres.o code-patching.o \ feature-fixups.o
Greg Kroah-Hartman
maintainerPATCH 15/48 scsi: bnx2fc: Flush destroy_work queue before calling bnx2fc_interface_put()
In reply to Greg Kroah-HartmanFrom: John Meneghini <[email protected]>
commit 847f9ea4c5186fdb7b84297e3eeed9e340e83fce upstream.
The bnx2fc_destroy() functions are removing the interface before calling destroy_work. This results multiple WARNings from sysfs_remove_group() as the controller rport device attributes are removed too early.
Replace the fcoe_port's destroy_work queue. It's not needed.
The problem is easily reproducible with the following steps.
Example:
$ dmesg -w & $ systemctl enable --now fcoe $ fipvlan -s -c ens2f1 $ fcoeadm -d ens2f1.802 [ 583.464488] host2: libfc: Link down on port (7500a1) [ 583.472651] bnx2fc: 7500a1 - rport not created Yet!! [ 583.490468] ------------[ cut here ]------------ [ 583.538725] sysfs group 'power' not found for kobject 'rport-2:0-0' [ 583.568814] WARNING: CPU: 3 PID: 192 at fs/sysfs/group.c:279 sysfs_remove_group+0x6f/0x80 [ 583.607130] Modules linked in: dm_service_time 8021q garp mrp stp llc bnx2fc cnic uio rpcsec_gss_krb5 auth_rpcgss nfsv4 ... [ 583.942994] CPU: 3 PID: 192 Comm: kworker/3:2 Kdump: loaded Not tainted 5.14.0-39.el9.x86_64 #1 [ 583.984105] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013 [ 584.016535] Workqueue: fc_wq_2 fc_rport_final_delete [scsi_transport_fc] [ 584.050691] RIP: 0010:sysfs_remove_group+0x6f/0x80 [ 584.074725] Code: ff 5b 48 89 ef 5d 41 5c e9 ee c0 ff ff 48 89 ef e8 f6 b8 ff ff eb d1 49 8b 14 24 48 8b 33 48 c7 c7 ... [ 584.162586] RSP: 0018:ffffb567c15afdc0 EFLAGS: 00010282 [ 584.188225] RAX: 0000000000000000 RBX: ffffffff8eec4220 RCX: 0000000000000000 [ 584.221053] RDX: ffff8c1586ce84c0 RSI: ffff8c1586cd7cc0 RDI: ffff8c1586cd7cc0 [ 584.255089] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb567c15afc00 [ 584.287954] R10: ffffb567c15afbf8 R11: ffffffff8fbe7f28 R12: ffff8c1486326400 [ 584.322356] R13: ffff8c1486326480 R14: ffff8c1483a4a000 R15: 0000000000000004 [ 584.355379] FS: 0000000000000000(0000) GS:ffff8c1586cc0000(0000) knlGS:0000000000000000 [ 584.394419] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 584.421123] CR2: 00007fe95a6f7840 CR3: 0000000107674002 CR4: 00000000000606e0 [ 584.454888] Call Trace: [ 584.466108] device_del+0xb2/0x3e0 [ 584.481701] device_unregister+0x13/0x60 [ 584.501306] bsg_unregister_queue+0x5b/0x80 [ 584.522029] bsg_remove_queue+0x1c/0x40 [ 584.541884] fc_rport_final_delete+0xf3/0x1d0 [scsi_transport_fc] [ 584.573823] process_one_work+0x1e3/0x3b0 [ 584.592396] worker_thread+0x50/0x3b0 [ 584.609256] ? rescuer_thread+0x370/0x370 [ 584.628877] kthread+0x149/0x170 [ 584.643673] ? set_kthread_struct+0x40/0x40 [ 584.662909] ret_from_fork+0x22/0x30 [ 584.680002] ---[ end trace 53575ecefa942ece ]---
--- drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 20 +++++--------------- 1 file changed, 5 insertions(+), 15 deletions(-)
drivers/scsi/bnx2fc/bnx2fc_fcoe.c +5 -15
@@ -79,7 +79,7 @@ static int bnx2fc_bind_pcidev(struct bnxstatic void bnx2fc_unbind_pcidev (struct bnx2fc_hba *hba);static struct fc_lport *bnx2fc_if_create (struct bnx2fc_interface *interface,struct device *parent,int npiv); -static void bnx2fc_destroy_work (struct work_struct *work); +static void bnx2fc_port_destroy (struct fcoe_port *port);static struct bnx2fc_hba *bnx2fc_hba_lookup (struct net_device *phys_dev); static struct bnx2fc_interface *bnx2fc_interface_lookup(struct net_device
@@ -884,9 +884,6 @@ static void bnx2fc_indicate_netevent(voi__bnx2fc_destroy (interface); }mutex_unlock (&bnx2fc_dev_lock); - -/* Ensure ALL destroy work has been completed before return */ -flush_workqueue (bnx2fc_wq);return ;default :
@@ -1194,8 +1191,8 @@ static int bnx2fc_vport_destroy(struct fmutex_unlock (&n_port->lp_mutex);bnx2fc_free_vport (interface->hba, port->lport);bnx2fc_port_shutdown (port->lport); +bnx2fc_port_destroy (port);bnx2fc_interface_put (interface); -queue_work (bnx2fc_wq, &port->destroy_work);return 0 ; }
@@ -1504,7 +1501,6 @@ static struct fc_lport *bnx2fc_if_create port->lport = lport; port->priv = interface; port->get_netdev = bnx2fc_netdev; -INIT_WORK (&port->destroy_work, bnx2fc_destroy_work);/* Configure fcoe_port */ rc =bnx2fc_lport_config (lport);
@@ -1632,8 +1628,8 @@ static void __bnx2fc_destroy(struct bnx2bnx2fc_interface_cleanup (interface);bnx2fc_stop (interface);list_del (&interface->list); +bnx2fc_port_destroy (port);bnx2fc_interface_put (interface); -queue_work (bnx2fc_wq, &port->destroy_work); }/**
@@ -1674,15 +1670,12 @@ netdev_err:return rc; } -static void bnx2fc_destroy_work (struct work_struct *work) +static void bnx2fc_port_destroy (struct fcoe_port *port) { -struct fcoe_port *port;struct fc_lport *lport; - port = container_of(work, struct fcoe_port, destroy_work); lport = port->lport; - -BNX2FC_HBA_DBG (lport,"Entered bnx2fc_destroy_work\n" ); +BNX2FC_HBA_DBG (lport,"Entered %s, destroying lport %p\n" , __func__, lport);bnx2fc_if_destroy (lport); }
@@ -2522,9 +2515,6 @@ static void bnx2fc_ulp_exit(struct cnic___bnx2fc_destroy (interface);mutex_unlock (&bnx2fc_dev_lock); -/* Ensure ALL destroy work has been completed before return */ -flush_workqueue (bnx2fc_wq); -bnx2fc_ulp_stop (hba);/* unregister cnic device */ if (test_and_clear_bit (BNX2FC_CNIC_REGISTERED , &hba->reg_with_cnic))
Greg Kroah-Hartman
maintainerPATCH 16/48 ipv6_tunnel: Rate limit warning messages
In reply to Greg Kroah-HartmanFrom: Ido Schimmel <[email protected]>
commit 6cee105e7f2ced596373951d9ea08dacc3883c68 upstream.
The warning messages can be invoked from the data path for every packet transmitted through an ip6gre netdev, leading to high CPU utilization.
Fix that by rate limiting the messages.
--- net/ipv6/ip6_tunnel.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
net/ipv6/ip6_tunnel.c +4 -4
@@ -1007,12 +1007,12 @@ int ip6_tnl_xmit_ctl(struct ip6_tnl *t, ldev =dev_get_by_index_rcu (net, p->link);if (unlikely (!ipv6_chk_addr (net, laddr, ldev,0 ))) -pr_warn ("%s xmit: Local address not yet configured!\n" , - p->name); +pr_warn_ratelimited ("%s xmit: Local address not yet configured!\n" , + p->name);else if (!ipv6_addr_is_multicast (raddr) &&unlikely (ipv6_chk_addr (net, raddr,NULL ,0 ))) -pr_warn ("%s xmit: Routing loop! Remote address found on this node!\n" , - p->name); +pr_warn_ratelimited ("%s xmit: Routing loop! Remote address found on this node!\n" , + p->name);else ret =1 ;rcu_read_unlock ();
Greg Kroah-Hartman
maintainerPATCH 17/48 net: fix information leakage in /proc/net/ptype
In reply to Greg Kroah-HartmanFrom: Congyu Liu <[email protected]>
commit 47934e06b65637c88a762d9c98329ae6e3238888 upstream.
In one net namespace, after creating a packet socket without binding it to a device, users in other net namespaces can observe the new packet_type added by this packet socket by reading /proc/net/ptype file. This is minor information leakage as packet socket is namespace aware.
Add a net pointer in packet_type to keep the net namespace of of corresponding packet socket. In ptype_seq_show, this net pointer must be checked when it is not NULL.
--- include/linux/netdevice.h | 1 + net/core/net-procfs.c | 3 ++- net/packet/af_packet.c | 2 ++ 3 files changed, 5 insertions(+), 1 deletion(-)
include/linux/netdevice.h +1 -0
@@ -2237,6 +2237,7 @@ struct packet_type { struct net_device *);bool (*id_match)(struct packet_type *ptype,struct sock *sk); +struct net *af_packet_net;void *af_packet_priv;struct list_head list; };
net/core/net-procfs.c +2 -1
@@ -278,7 +278,8 @@ static int ptype_seq_show(struct seq_filif (v ==SEQ_START_TOKEN )seq_puts (seq,"Type Device Function\n" ); -else if (pt->dev ==NULL ||dev_net (pt->dev) ==seq_file_net (seq)) { +else if ((!pt->af_packet_net ||net_eq (pt->af_packet_net,seq_file_net (seq))) && + (!pt->dev ||net_eq (dev_net (pt->dev),seq_file_net (seq)))) {if (pt->type ==htons (ETH_P_ALL ))seq_puts (seq,"ALL " );else
net/packet/af_packet.c +2 -0
@@ -1705,6 +1705,7 @@ static int fanout_add(struct sock *sk, u match->prot_hook.dev = po->prot_hook.dev; match->prot_hook.func = packet_rcv_fanout; match->prot_hook.af_packet_priv = match; + match->prot_hook.af_packet_net =read_pnet (&match->net); match->prot_hook.id_match = match_fanout_group;list_add (&match->list, &fanout_list); }
@@ -3310,6 +3311,7 @@ static int packet_create(struct net *net po->prot_hook.func = packet_rcv_spkt; po->prot_hook.af_packet_priv = sk; + po->prot_hook.af_packet_net =sock_net (sk);if (proto) { po->prot_hook.type = proto;
Greg Kroah-Hartman
maintainerPATCH 18/48 ipv4: avoid using shared IP generator for connected sockets
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
commit 23f57406b82de51809d5812afd96f210f8b627f3 upstream.
ip_select_ident_segs() has been very conservative about using the connected socket private generator only for packets with IP_DF set, claiming it was needed for some VJ compression implementations.
As mentioned in this referenced document, this can be abused. (Ref: Off-Path TCP Exploits of the Mixed IPID Assignment)
Before switching to pure random IPID generation and possibly hurt some workloads, lets use the private inet socket generator.
Not only this will remove one vulnerability, this will also improve performance of TCP flows using pmtudisc==IP_PMTUDISC_DONT
--- include/net/ip.h | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-)
include/net/ip.h +10 -11
@@ -377,19 +377,18 @@ static inline void ip_select_ident_segs( {struct iphdr *iph =ip_hdr (skb); +/* We had many attacks based on IPID, use the private +* generator as much as we can. +*/ +if (sk &&inet_sk (sk)->inet_daddr) { + iph->id =htons (inet_sk (sk)->inet_id); +inet_sk (sk)->inet_id += segs; +return ; + }if ((iph->frag_off &htons (IP_DF )) && !skb->ignore_df) { -/* This is only to work around buggy Windows95/2000 -* VJ compression implementations. If the ID field -* does not change, they drop every other packet in -* a TCP stream using header compression. -*/ -if (sk &&inet_sk (sk)->inet_daddr) { - iph->id =htons (inet_sk (sk)->inet_id); -inet_sk (sk)->inet_id += segs; - }else { - iph->id =0 ; - } + iph->id =0 ; }else { +/* Unfortunately we need the big hammer to get a suitable IPID */ __ip_select_ident (net, iph, segs); } }
Greg Kroah-Hartman
maintainerPATCH 19/48 NFSv4: Handle case where the lookup of a directory fails
In reply to Greg Kroah-HartmanFrom: Trond Myklebust <[email protected]>
commit ac795161c93699d600db16c1a8cc23a65a1eceaf upstream.
If the application sets the O_DIRECTORY flag, and tries to open a regular file, nfs_atomic_open() will punt to doing a regular lookup. If the server then returns a regular file, we will happily return a file descriptor with uninitialised open state.
The fix is to return the expected ENOTDIR error in these cases.
--- fs/nfs/dir.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
fs/nfs/dir.c +13 -0
@@ -1602,6 +1602,19 @@ out: no_open: res =nfs_lookup (dir, dentry, lookup_flags); +if (!res) { + inode =d_inode (dentry); +if ((lookup_flags &LOOKUP_DIRECTORY ) && inode && + !S_ISDIR (inode->i_mode)) + res =ERR_PTR (-ENOTDIR ); + }else if (!IS_ERR (res)) { + inode =d_inode (res); +if ((lookup_flags &LOOKUP_DIRECTORY ) && inode && + !S_ISDIR (inode->i_mode)) { +dput (res); + res =ERR_PTR (-ENOTDIR ); + } + }if (switched) {d_lookup_done (dentry);if (!res)
Greg Kroah-Hartman
maintainerPATCH 20/48 NFSv4: nfs_atomic_open() can race when looking up a non-regular file
In reply to Greg Kroah-HartmanFrom: Trond Myklebust <[email protected]>
commit 1751fc1db36f6f411709e143d5393f92d12137a9 upstream.
If the file type changes back to being a regular file on the server between the failed OPEN and our LOOKUP, then we need to re-run the OPEN.
--- fs/nfs/dir.c | 5 +++++ 1 file changed, 5 insertions(+)
fs/nfs/dir.c +5 -0
@@ -1607,12 +1607,17 @@ no_open:if ((lookup_flags &LOOKUP_DIRECTORY ) && inode && !S_ISDIR (inode->i_mode)) res =ERR_PTR (-ENOTDIR ); +else if (inode &&S_ISREG (inode->i_mode)) + res =ERR_PTR (-EOPENSTALE ); }else if (!IS_ERR (res)) { inode =d_inode (res);if ((lookup_flags &LOOKUP_DIRECTORY ) && inode && !S_ISDIR (inode->i_mode)) {dput (res); res =ERR_PTR (-ENOTDIR ); + }else if (inode &&S_ISREG (inode->i_mode)) { +dput (res); + res =ERR_PTR (-EOPENSTALE ); } }if (switched) {
Greg Kroah-Hartman
maintainerPATCH 21/48 net-procfs: show net devices bound packet types
In reply to Greg Kroah-HartmanFrom: Jianguo Wu <[email protected]>
commit 1d10f8a1f40b965d449e8f2d5ed7b96a7c138b77 upstream.
After commit:7866a621043f ("dev: add per net_device packet type chains"), we can not get packet types that are bound to a specified net device by /proc/net/ptype, this patch fix the regression.
Run "tcpdump -i ens192 udp -nns0" Before and after apply this patch:
Before:
[root@localhost ~]# cat /proc/net/ptype
Type Device Function
0800 ip_rcv 0806 arp_rcv 86dd ipv6_rcv
After:
[root@localhost ~]# cat /proc/net/ptype
Type Device Function
ALL ens192 tpacket_rcv 0800 ip_rcv 0806 arp_rcv 86dd ipv6_rcv
v1 -> v2:
- fix the regression rather than adding new /proc API as suggested by Stephen Hemminger.
--- net/core/net-procfs.c | 35 ++++++++++++++++++++++++++++++++--- 1 file changed, 32 insertions(+), 3 deletions(-)
net/core/net-procfs.c +32 -3
@@ -208,12 +208,23 @@ static const struct file_operations soft .release = seq_release, }; -static void *ptype_get_idx (loff_t pos) +static void *ptype_get_idx (struct seq_file *seq,loff_t pos) { +struct list_head *ptype_list =NULL ;struct packet_type *pt =NULL ; +struct net_device *dev;loff_t i =0 ;int t; +for_each_netdev_rcu (seq_file_net (seq), dev) { + ptype_list = &dev->ptype_all; +list_for_each_entry_rcu (pt, ptype_list, list) { +if (i == pos) +return pt; + ++i; + } + } +list_for_each_entry_rcu (pt, &ptype_all, list) {if (i == pos)return pt;
@@ -234,22 +245,40 @@ static void *ptype_seq_start(struct seq___acquires (RCU ) {rcu_read_lock (); -return *pos ?ptype_get_idx (*pos -1 ) :SEQ_START_TOKEN ; +return *pos ?ptype_get_idx (seq, *pos -1 ) :SEQ_START_TOKEN ; }static void *ptype_seq_next (struct seq_file *seq,void *v,loff_t *pos) { +struct net_device *dev;struct packet_type *pt;struct list_head *nxt;int hash; ++*pos;if (v ==SEQ_START_TOKEN ) -return ptype_get_idx (0 ); +return ptype_get_idx (seq,0 ); pt = v; nxt = pt->list.next; +if (pt->dev) { +if (nxt != &pt->dev->ptype_all) + goto found; + + dev = pt->dev; +for_each_netdev_continue_rcu (seq_file_net (seq), dev) { +if (!list_empty (&dev->ptype_all)) { + nxt = dev->ptype_all.next; + goto found; + } + } + + nxt = ptype_all.next; + goto ptype_all; + } +if (pt->type ==htons (ETH_P_ALL )) { +ptype_all:if (nxt != &ptype_all) goto found; hash =0 ;
Greg Kroah-Hartman
maintainerPATCH 22/48 drm/msm: Fix wrong size calculation
In reply to Greg Kroah-HartmanFrom: Xianting Tian <[email protected]>
commit 0a727b459ee39bd4c5ced19d6024258ac87b6b2e upstream.
For example, memory-region in .dts as below,
reg = <0x0 0x50000000 0x0 0x20000000>
We can get below values,
struct resource r;
r.start = 0x50000000;
r.end = 0x6fffffff;
So the size should be:
size = r.end - r.start + 1 = 0x20000000
--- drivers/gpu/drm/msm/msm_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/msm/msm_drv.c +1 -1
@@ -297,7 +297,7 @@ static int msm_init_vram(struct drm_deviof_node_put (node);if (ret)return ret; - size = r.end - r.start; + size = r.end - r.start +1 ;DRM_INFO ("using VRAM carveout: %lx@%pa\n" , size, &r.start);/* if we have no IOMMU, then we need to use carveout allocator.
Greg Kroah-Hartman
maintainerPATCH 23/48 hwmon: (lm90) Reduce maximum conversion rate for G781
In reply to Greg Kroah-HartmanFrom: Guenter Roeck <[email protected]>
[ Upstream commit a66c5ed539277b9f2363bbace0dba88b85b36c26 ]
According to its datasheet, G781 supports a maximum conversion rate value of 8 (62.5 ms). However, chips labeled G781 and G780 were found to only support a maximum conversion rate value of 7 (125 ms). On the other side, chips labeled G781-1 and G784 were found to support a conversion rate value of 8. There is no known means to distinguish G780 from G781 or G784; all chips report the same manufacturer ID and chip revision. Setting the conversion rate register value to 8 on chips not supporting it causes unexpected behavior since the real conversion rate is set to 0 (16 seconds) if a value of 8 is written into the conversion rate register. Limit the conversion rate register value to 7 for all G78x chips to avoid the problem.
--- drivers/hwmon/lm90.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hwmon/lm90.c +1 -1
@@ -265,7 +265,7 @@ static const struct lm90_params lm90_params[] = { .flags = LM90_HAVE_OFFSET | LM90_HAVE_REM_LIMIT_EXT | LM90_HAVE_BROKEN_ALERT, .alert_alarms = 0x7c, - .max_convrate = 8, + .max_convrate = 7, }, [lm86] = { .flags = LM90_HAVE_OFFSET | LM90_HAVE_REM_LIMIT_EXT,
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 24/48 ipv4: raw: lock the socket in raw_bind()
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
[ Upstream commit 153a0d187e767c68733b8e9f46218eb1f41ab902 ]
For some reason, raw_bind() forgot to lock the socket.
BUG: KCSAN: data-race in __ip4_datagram_connect / raw_bind
write to 0xffff8881170d4308 of 4 bytes by task 5466 on cpu 0:
raw_bind+0x1b0/0x250 net/ipv4/raw.c:739 inet_bind+0x56/0xa0 net/ipv4/af_inet.c:443 __sys_bind+0x14b/0x1b0 net/socket.c:1697 __do_sys_bind net/socket.c:1708 [inline] __se_sys_bind net/socket.c:1706 [inline] __x64_sys_bind+0x3d/0x50 net/socket.c:1706 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae
read to 0xffff8881170d4308 of 4 bytes by task 5468 on cpu 1:
__ip4_datagram_connect+0xb7/0x7b0 net/ipv4/datagram.c:39 ip4_datagram_connect+0x2a/0x40 net/ipv4/datagram.c:89 inet_dgram_connect+0x107/0x190 net/ipv4/af_inet.c:576 __sys_connect_file net/socket.c:1900 [inline] __sys_connect+0x197/0x1b0 net/socket.c:1917 __do_sys_connect net/socket.c:1927 [inline] __se_sys_connect net/socket.c:1924 [inline] __x64_sys_connect+0x3d/0x50 net/socket.c:1924 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae
value changed: 0x00000000 -> 0x0003007f
Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 5468 Comm: syz-executor.5 Not tainted 5.17.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
--- net/ipv4/raw.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
net/ipv4/raw.c +4 -1
@@ -706,6 +706,7 @@ static int raw_bind(struct sock *sk, struct sockaddr *uaddr, int addr_len)int ret = -EINVAL ;int chk_addr_ret; +lock_sock (sk);if (sk->sk_state !=TCP_CLOSE || addr_len <sizeof (struct sockaddr_in )) goto out; chk_addr_ret =inet_addr_type (sock_net (sk), addr->sin_addr.s_addr);
@@ -718,7 +719,9 @@ static int raw_bind(struct sock *sk, struct sockaddr *uaddr, int addr_len) inet->inet_saddr =0 ;/* Use device */ sk_dst_reset (sk); ret =0 ; -out:return ret; +out: +release_sock (sk); +return ret; }/*
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 25/48 ipv4: tcp: send zero IPID in SYNACK messages
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
[ Upstream commit 970a5a3ea86da637471d3cd04d513a0755aba4bf ]
In commit 431280eebed9 ("ipv4: tcp: send zero IPID for RST and ACK sent in SYN-RECV and TIME-WAIT state") we took care of some ctl packets sent by TCP.
It turns out we need to use a similar strategy for SYNACK packets.
By default, they carry IP_DF and IPID==0, but there are ways to ask them to use the hashed IP ident generator and thus be used to build off-path attacks.
(Ref: Off-Path TCP Exploits of the Mixed IPID Assignment)
One of this way is to force (before listener is started) echo 1 >/proc/sys/net/ipv4/ip_no_pmtu_disc
Another way is using forged ICMP ICMP_FRAG_NEEDED with a very small MTU (like 68) to force a false return from ip_dont_fragment()
In this patch, ip_build_and_send_pkt() uses the following heuristics.
1) Most SYNACK packets are smaller than IPV4_MIN_MTU and therefore can use IP_DF regardless of the listener or route pmtu setting.
2) In case the SYNACK packet is bigger than IPV4_MIN_MTU, we use prandom_u32() generator instead of the IPv4 hashed ident one.
--- net/ipv4/ip_output.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)
net/ipv4/ip_output.c +9 -2
@@ -159,12 +159,19 @@ int ip_build_and_send_pkt(struct sk_buff iph->daddr = (opt && opt->opt.srr ? opt->opt.faddr : daddr); iph->saddr = saddr; iph->protocol = sk->sk_protocol; -if (ip_dont_fragment (sk, &rt->dst)) { +/* Do not bother generating IPID for small packets (eg SYNACK) */ +if (skb->len <=IPV4_MIN_MTU ||ip_dont_fragment (sk, &rt->dst)) { iph->frag_off =htons (IP_DF ); iph->id =0 ; }else { iph->frag_off =0 ; -__ip_select_ident (net, iph,1 ); +/* TCP packets here are SYNACK with fat IPv4/TCP options. +* Avoid using the hashed IP ident generator. +*/ +if (sk->sk_protocol ==IPPROTO_TCP ) + iph->id = (__force __be16 )prandom_u32 (); +else +__ip_select_ident (net, iph,1 ); }if (opt && opt->opt.optlen) {
Greg Kroah-Hartman
maintainerPATCH 26/48 netfilter: nat: remove l4 protocol port rovers
In reply to Greg Kroah-HartmanFrom: Florian Westphal <[email protected]>
commit 6ed5943f8735e2b778d92ea4d9805c0a1d89bc2b upstream.
This is a leftover from days where single-cpu systems were common:
Store last port used to resolve a clash to use it as a starting point when the next conflict needs to be resolved.
When we have parallel attempt to connect to same address:port pair, its likely that both cores end up computing the same "available" port, as both use same starting port, and newly used ports won't become visible to other cores until the conntrack gets confirmed later.
One of the cores then has to drop the packet at insertion time because the chosen new tuple turns out to be in use after all.
Lets simplify this: remove port rover and use a pseudo-random starting point.
Note that this doesn't make netfilter default to 'fully random' mode; the 'rover' was only used if NAT could not reuse source port as-is.
--- include/net/netfilter/nf_nat_l4proto.h | 2 +- net/netfilter/nf_nat_proto_common.c | 7 ++----- net/netfilter/nf_nat_proto_dccp.c | 5 +---- net/netfilter/nf_nat_proto_sctp.c | 5 +---- net/netfilter/nf_nat_proto_tcp.c | 5 +---- net/netfilter/nf_nat_proto_udp.c | 5 +---- net/netfilter/nf_nat_proto_udplite.c | 5 +---- 7 files changed, 8 insertions(+), 26 deletions(-)
include/net/netfilter/nf_nat_l4proto.h +1 -1
@@ -64,7 +64,7 @@ void nf_nat_l4proto_unique_tuple(const sstruct nf_conntrack_tuple *tuple, const struct nf_nat_range *range, enum nf_nat_manip_type maniptype, - const struct nf_conn *ct, u16 *rover); + const struct nf_conn *ct);int nf_nat_l4proto_nlattr_to_range (struct nlattr *tb[],struct nf_nat_range *range);
net/netfilter/nf_nat_proto_common.c +2 -5
@@ -38,8 +38,7 @@ void nf_nat_l4proto_unique_tuple(const sstruct nf_conntrack_tuple *tuple, const struct nf_nat_range *range, enum nf_nat_manip_type maniptype, - const struct nf_conn *ct, - u16 *rover) + const struct nf_conn *ct) { unsigned int range_size, min, max, i;__be16 *portptr;
@@ -84,15 +83,13 @@ void nf_nat_l4proto_unique_tuple(const s }else if (range->flags &NF_NAT_RANGE_PROTO_RANDOM_FULLY ) { off =prandom_u32 (); }else { - off = *rover; + off =prandom_u32 (); }for (i =0 ; ; ++off) { *portptr =htons (min + off % range_size);if (++i != range_size &&nf_nat_used_tuple (tuple, ct))continue ; -if (!(range->flags &NF_NAT_RANGE_PROTO_RANDOM_ALL )) - *rover = off;return ; } }
net/netfilter/nf_nat_proto_dccp.c +1 -4
@@ -20,8 +20,6 @@#include <net/netfilter/nf_nat_l3proto.h> #include <net/netfilter/nf_nat_l4proto.h> -static u_int16_t dccp_port_rover; - static void dccp_unique_tuple(const struct nf_nat_l3proto *l3proto, struct nf_conntrack_tuple *tuple,
@@ -29,8 +27,7 @@ dccp_unique_tuple(const struct nf_nat_l3enum nf_nat_manip_type maniptype, const struct nf_conn *ct) { -nf_nat_l4proto_unique_tuple (l3proto ,tuple ,range ,maniptype ,ct , - &dccp_port_rover); +nf_nat_l4proto_unique_tuple (l3proto ,tuple ,range ,maniptype ,ct ); } static bool
net/netfilter/nf_nat_proto_sctp.c +1 -4
@@ -14,8 +14,6 @@#include <net/netfilter/nf_nat_l4proto.h> -static u_int16_t nf_sctp_port_rover; - static void sctp_unique_tuple(const struct nf_nat_l3proto *l3proto, struct nf_conntrack_tuple *tuple,
@@ -23,8 +21,7 @@ sctp_unique_tuple(const struct nf_nat_l3enum nf_nat_manip_type maniptype, const struct nf_conn *ct) { -nf_nat_l4proto_unique_tuple (l3proto ,tuple ,range ,maniptype ,ct , - &nf_sctp_port_rover); +nf_nat_l4proto_unique_tuple (l3proto ,tuple ,range ,maniptype ,ct ); } static bool
net/netfilter/nf_nat_proto_tcp.c +1 -4
@@ -18,8 +18,6 @@#include <net/netfilter/nf_nat_l4proto.h> #include <net/netfilter/nf_nat_core.h> -static u16 tcp_port_rover; - static void tcp_unique_tuple(const struct nf_nat_l3proto *l3proto, struct nf_conntrack_tuple *tuple,
@@ -27,8 +25,7 @@ tcp_unique_tuple(const struct nf_nat_l3penum nf_nat_manip_type maniptype, const struct nf_conn *ct) { -nf_nat_l4proto_unique_tuple (l3proto ,tuple ,range ,maniptype ,ct , - &tcp_port_rover); +nf_nat_l4proto_unique_tuple (l3proto ,tuple ,range ,maniptype ,ct ); } static bool
net/netfilter/nf_nat_proto_udp.c +1 -4
@@ -17,8 +17,6 @@#include <net/netfilter/nf_nat_l3proto.h> #include <net/netfilter/nf_nat_l4proto.h> -static u16 udp_port_rover; - static void udp_unique_tuple(const struct nf_nat_l3proto *l3proto, struct nf_conntrack_tuple *tuple,
@@ -26,8 +24,7 @@ udp_unique_tuple(const struct nf_nat_l3penum nf_nat_manip_type maniptype, const struct nf_conn *ct) { -nf_nat_l4proto_unique_tuple (l3proto ,tuple ,range ,maniptype ,ct , - &udp_port_rover); +nf_nat_l4proto_unique_tuple (l3proto ,tuple ,range ,maniptype ,ct ); } static bool
net/netfilter/nf_nat_proto_udplite.c +1 -4
@@ -17,8 +17,6 @@#include <net/netfilter/nf_nat_l3proto.h> #include <net/netfilter/nf_nat_l4proto.h> -static u16 udplite_port_rover; - static void udplite_unique_tuple(const struct nf_nat_l3proto *l3proto, struct nf_conntrack_tuple *tuple,
@@ -26,8 +24,7 @@ udplite_unique_tuple(const struct nf_natenum nf_nat_manip_type maniptype, const struct nf_conn *ct) { -nf_nat_l4proto_unique_tuple (l3proto ,tuple ,range ,maniptype ,ct , - &udplite_port_rover); +nf_nat_l4proto_unique_tuple (l3proto ,tuple ,range ,maniptype ,ct ); } static bool
Greg Kroah-Hartman
maintainerPATCH 27/48 netfilter: nat: limit port clash resolution attempts
In reply to Greg Kroah-HartmanFrom: Florian Westphal <[email protected]>
commit a504b703bb1da526a01593da0e4be2af9d9f5fa8 upstream.
In case almost or all available ports are taken, clash resolution can take a very long time, resulting in soft lockup.
This can happen when many to-be-natted hosts connect to same destination:port (e.g. a proxy) and all connections pass the same SNAT.
Pick a random offset in the acceptable range, then try ever smaller number of adjacent port numbers, until either the limit is reached or a useable port was found. This results in at most 248 attempts (128 + 64 + 32 + 16 + 8, i.e. 4 restarts with new search offset) instead of 64000+,
--- net/netfilter/nf_nat_proto_common.c | 29 +++++++++++++++++++++++------ 1 file changed, 23 insertions(+), 6 deletions(-)
net/netfilter/nf_nat_proto_common.c +23 -6
@@ -40,9 +40,10 @@ void nf_nat_l4proto_unique_tuple(const senum nf_nat_manip_type maniptype, const struct nf_conn *ct) { - unsigned int range_size, min, max, i; + unsigned int range_size, min, max, i, attempts;__be16 *portptr; -u_int16_t off; +u16 off; +static const unsigned int max_attempts =128 ;if (maniptype ==NF_NAT_MANIP_SRC ) portptr = &tuple->src.u.all;
@@ -86,12 +87,28 @@ void nf_nat_l4proto_unique_tuple(const s off =prandom_u32 (); } -for (i =0 ; ; ++off) { + attempts = range_size; +if (attempts > max_attempts) + attempts = max_attempts; + +/* We are in softirq; doing a search of the entire range risks +* soft lockup when all tuples are already used. +* +* If we can't find any free port from first offset, pick a new +* one and try again, with ever smaller search window. +*/ +another_round: +for (i =0 ; i < attempts; i++, off++) { *portptr =htons (min + off % range_size); -if (++i != range_size &&nf_nat_used_tuple (tuple, ct)) -continue ; -return ; +if (!nf_nat_used_tuple (tuple, ct)) +return ; } + +if (attempts >= range_size || attempts <16 ) +return ; + attempts /=2 ; + off =prandom_u32 (); + goto another_round; }EXPORT_SYMBOL_GPL (nf_nat_l4proto_unique_tuple);
Greg Kroah-Hartman
maintainerPATCH 28/48 ipheth: fix EOVERFLOW in ipheth_rcvbulk_callback
In reply to Greg Kroah-HartmanFrom: Georgi Valkov <[email protected]>
commit 63e4b45c82ed1bde979da7052229a4229ce9cabf upstream.
When rx_buf is allocated we need to account for IPHETH_IP_ALIGN, which reduces the usable size by 2 bytes. Otherwise we have 1512 bytes usable instead of 1514, and if we receive more than 1512 bytes, ipheth_rcvbulk_callback is called with status -EOVERFLOW, after which the driver malfunctiones and all communication stops.
Resolves ipheth 2-1:4.2: ipheth_rcvbulk_callback: urb status: -75
--- drivers/net/usb/ipheth.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/net/usb/ipheth.c +3 -3
@@ -173,7 +173,7 @@ static int ipheth_alloc_urbs(struct ipheif (tx_buf ==NULL ) goto free_rx_urb; - rx_buf =usb_alloc_coherent (iphone->udev,IPHETH_BUF_SIZE , + rx_buf =usb_alloc_coherent (iphone->udev,IPHETH_BUF_SIZE +IPHETH_IP_ALIGN ,GFP_KERNEL , &rx_urb->transfer_dma);if (rx_buf ==NULL ) goto free_tx_buf;
@@ -198,7 +198,7 @@ error_nomem:static void ipheth_free_urbs (struct ipheth_device *iphone) { -usb_free_coherent (iphone->udev,IPHETH_BUF_SIZE , iphone->rx_buf, +usb_free_coherent (iphone->udev,IPHETH_BUF_SIZE +IPHETH_IP_ALIGN , iphone->rx_buf, iphone->rx_urb->transfer_dma);usb_free_coherent (iphone->udev,IPHETH_BUF_SIZE , iphone->tx_buf, iphone->tx_urb->transfer_dma);
@@ -371,7 +371,7 @@ static int ipheth_rx_submit(struct iphetusb_fill_bulk_urb (dev->rx_urb, udev,usb_rcvbulkpipe (udev, dev->bulk_in), - dev->rx_buf,IPHETH_BUF_SIZE , + dev->rx_buf,IPHETH_BUF_SIZE +IPHETH_IP_ALIGN , ipheth_rcvbulk_callback, dev); dev->rx_urb->transfer_flags |=URB_NO_TRANSFER_DMA_MAP ;
Greg Kroah-Hartman
maintainerPATCH 29/48 net: amd-xgbe: ensure to reset the tx_timer_active flag
In reply to Greg Kroah-HartmanFrom: Raju Rangoju <[email protected]>
commit 7674b7b559b683478c3832527c59bceb169e701d upstream.
Ensure to reset the tx_timer_active flag in xgbe_stop(), otherwise a port restart may result in tx timeout due to uncleared flag.
--- drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/ethernet/amd/xgbe/xgbe-drv.c +2 -0
@@ -494,7 +494,9 @@ static void xgbe_stop_timers(struct xgbeif (!channel->tx_ring)break ; +/* Deactivate the Tx timer */ del_timer_sync (&channel->tx_timer); + channel->tx_timer_active =0 ; } }
Greg Kroah-Hartman
maintainerPATCH 30/48 net: amd-xgbe: Fix skb data length underflow
In reply to Greg Kroah-HartmanFrom: Shyam Sundar S K <[email protected]>
commit 5aac9108a180fc06e28d4e7fb00247ce603b72ee upstream.
There will be BUG_ON() triggered in include/linux/skbuff.h leading to intermittent kernel panic, when the skb length underflow is detected.
Fix this by dropping the packet if such length underflows are seen because of inconsistencies in the hardware descriptors.
--- drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
drivers/net/ethernet/amd/xgbe/xgbe-drv.c +11 -1
@@ -1968,6 +1968,14 @@ read_again: buf2_len =xgbe_rx_buf2_len (rdata, packet, len); len += buf2_len; +if (buf2_len > rdata->rx.buf.dma_len) { +/* Hardware inconsistency within the descriptors +* that has resulted in a length underflow. +*/ + error =1 ; + goto skip_data; + } +if (!skb) { skb =xgbe_create_skb (pdata, napi, rdata, buf1_len);
@@ -1997,8 +2005,10 @@ skip_data:if (!last || context_next) goto read_again; -if (!skb) +if (!skb || error) { +dev_kfree_skb (skb); goto next_packet; + }/* Be sure we don't exceed the configured MTU */ max_len = netdev->mtu +ETH_HLEN ;
Greg Kroah-Hartman
maintainerPATCH 31/48 rtnetlink: make sure to refresh master_dev/m_ops in __rtnl_newlink()
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
commit c6f6f2444bdbe0079e41914a35081530d0409963 upstream.
While looking at one unrelated syzbot bug, I found the replay logic in __rtnl_newlink() to potentially trigger use-after-free.
It is better to clear master_dev and m_ops inside the loop, in case we have to replay it.
--- net/core/rtnetlink.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
net/core/rtnetlink.c +4 -2
@@ -2454,9 +2454,9 @@ static int rtnl_newlink(struct sk_buff * {struct net *net =sock_net (skb->sk);const struct rtnl_link_ops *ops; -const struct rtnl_link_ops *m_ops =NULL ; +const struct rtnl_link_ops *m_ops;struct net_device *dev; -struct net_device *master_dev =NULL ; +struct net_device *master_dev;struct ifinfomsg *ifm;char kind[MODULE_NAME_LEN ];char ifname[IFNAMSIZ ];
@@ -2487,6 +2487,8 @@ replay: dev =NULL ; } + master_dev =NULL ; + m_ops =NULL ;if (dev) { master_dev =netdev_master_upper_dev_get (dev);if (master_dev)
Greg Kroah-Hartman
maintainerPATCH 32/48 af_packet: fix data-race in packet_setsockopt / packet_setsockopt
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
commit e42e70ad6ae2ae511a6143d2e8da929366e58bd9 upstream.
When packet_setsockopt( PACKET_FANOUT_DATA ) reads po->fanout, no lock is held, meaning that another thread can change po->fanout.
Given that po->fanout can only be set once during the socket lifetime (it is only cleared from fanout_release()), we can use READ_ONCE()/WRITE_ONCE() to document the race.
BUG: KCSAN: data-race in packet_setsockopt / packet_setsockopt
write to 0xffff88813ae8e300 of 8 bytes by task 14653 on cpu 0:
fanout_add net/packet/af_packet.c:1791 [inline] packet_setsockopt+0x22fe/0x24a0 net/packet/af_packet.c:3931 __sys_setsockopt+0x209/0x2a0 net/socket.c:2180 __do_sys_setsockopt net/socket.c:2191 [inline] __se_sys_setsockopt net/socket.c:2188 [inline] __x64_sys_setsockopt+0x62/0x70 net/socket.c:2188 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae
read to 0xffff88813ae8e300 of 8 bytes by task 14654 on cpu 1:
packet_setsockopt+0x691/0x24a0 net/packet/af_packet.c:3935 __sys_setsockopt+0x209/0x2a0 net/socket.c:2180 __do_sys_setsockopt net/socket.c:2191 [inline] __se_sys_setsockopt net/socket.c:2188 [inline] __x64_sys_setsockopt+0x62/0x70 net/socket.c:2188 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae
value changed: 0x0000000000000000 -> 0xffff888106f8c000
Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 14654 Comm: syz-executor.3 Not tainted 5.16.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
--- net/packet/af_packet.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
net/packet/af_packet.c +6 -2
@@ -1719,7 +1719,10 @@ static int fanout_add(struct sock *sk, u err = -ENOSPC ;if (atomic_read (&match->sk_ref) <PACKET_FANOUT_MAX ) {__dev_remove_pack (&po->prot_hook); - po->fanout = match; + +/* Paired with packet_setsockopt(PACKET_FANOUT_DATA) */ +WRITE_ONCE (po->fanout, match); + po->rollover = rollover; rollover =NULL ;atomic_inc (&match->sk_ref);
@@ -3895,7 +3898,8 @@ packet_setsockopt(struct socket *sock, i }case PACKET_FANOUT_DATA : { -if (!po->fanout) +/* Paired with the WRITE_ONCE() in fanout_add() */ +if (!READ_ONCE (po->fanout))return -EINVAL ;return fanout_set_data (po, optval, optlen);
Greg Kroah-Hartman
maintainerPATCH 33/48 ASoC: ops: Reject out of bounds values in snd_soc_put_volsw()
In reply to Greg Kroah-HartmanFrom: Mark Brown <[email protected]>
commit 817f7c9335ec01e0f5e8caffc4f1dcd5e458a4c0 upstream.
We don't currently validate that the values being set are within the range we advertised to userspace as being valid, do so and reject any values that are out of range.
--- sound/soc/soc-ops.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-)
sound/soc/soc-ops.c +16 -2
@@ -327,13 +327,27 @@ int snd_soc_put_volsw(struct snd_kcontroif (sign_bit) mask =BIT (sign_bit +1 ) -1 ; - val = ((ucontrol->value.integer.value[0 ] + min) & mask); + val = ucontrol->value.integer.value[0 ]; +if (mc->platform_max && val > mc->platform_max) +return -EINVAL ; +if (val > max - min) +return -EINVAL ; +if (val <0 ) +return -EINVAL ; + val = (val + min) & mask;if (invert) val = max - val; val_mask = mask << shift; val = val << shift;if (snd_soc_volsw_is_stereo (mc)) { - val2 = ((ucontrol->value.integer.value[1 ] + min) & mask); + val2 = ucontrol->value.integer.value[1 ]; +if (mc->platform_max && val2 > mc->platform_max) +return -EINVAL ; +if (val2 > max - min) +return -EINVAL ; +if (val2 <0 ) +return -EINVAL ; + val2 = (val2 + min) & mask;if (invert) val2 = max - val2;if (reg == reg2) {
Greg Kroah-Hartman
maintainerPATCH 34/48 ASoC: ops: Reject out of bounds values in snd_soc_put_volsw_sx()
In reply to Greg Kroah-HartmanFrom: Mark Brown <[email protected]>
commit 4f1e50d6a9cf9c1b8c859d449b5031cacfa8404e upstream.
We don't currently validate that the values being set are within the range we advertised to userspace as being valid, do so and reject any values that are out of range.
--- sound/soc/soc-ops.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
sound/soc/soc-ops.c +8 -1
@@ -441,8 +441,15 @@ int snd_soc_put_volsw_sx(struct snd_kconint err =0 ;unsigned int val, val_mask, val2 =0 ; + val = ucontrol->value.integer.value[0 ]; +if (mc->platform_max && val > mc->platform_max) +return -EINVAL ; +if (val > max - min) +return -EINVAL ; +if (val <0 ) +return -EINVAL ; val_mask = mask << shift; - val = (ucontrol->value.integer.value[0 ] + min) & mask; + val = (val + min) & mask; val = val << shift; err =snd_soc_component_update_bits (component, reg, val_mask, val);
Re: [PATCH 4.9 34/48] ASoC: ops: Reject out of bounds values in snd_soc_put_volsw_sx()
Hi!
Quoted 5 lines
commit
4f1e50d6a9cf9c1b8c859d449b5031cacfa8404eupstream.We don't currently validate that the values being set are within the range we advertised to userspace as being valid, do so and reject any values that are out of range.
We are getting reports that this commit breaks audio on some phones... and indeed it looks like "+ min" is missing in first condition:
val = ucontrol->value.integer.value[0];
- if (mc->platform_max && val > mc->platform_max)
+ if (mc->platform_max && ((int)val + min) > mc->platform_max)
 return -EINVAL;
What needs to be done to get this fixed?
Best regards,
Pavel
Quoted 29 lines
Signed-off-by Mark Brown <[email protected]>Signed-off-by Mark Brown <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- sound/soc/soc-ops.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)sound/soc/soc-ops.c +8
-1@@ -441,8 +441,15 @@ int snd_soc_put_volsw_sx(struct snd_kconint err =0 ;unsigned int val, val_mask, val2 =0 ; + val = ucontrol->value.integer.value[0 ]; +if (mc->platform_max && val > mc->platform_max) +return -EINVAL ; +if (val > max - min) +return -EINVAL ; +if (val <0 ) +return -EINVAL ; val_mask = mask << shift; - val = (ucontrol->value.integer.value[0 ] + min) & mask; + val = (val + min) & mask; val = val << shift; err =snd_soc_component_update_bits (component, reg, val_mask, val);
Signature · 1 line
People of Russia, stop Putin before his war on Ukraine escalates.
Re: [PATCH 4.9 34/48] ASoC: ops: Reject out of bounds values in snd_soc_put_volsw_sx()
Quoted 11 lines · Pavel Machek
We are getting reports that this commit breaks audio on some phones... and indeed it looks like "+ min" is missing in first condition:
val = ucontrol->value.integer.value[0];- if (
mc->platform_max&& val >mc->platform_max)
+ if (mc->platform_max&& ((int)val + min) >mc->platform_max)
 return-EINVAL;What needs to be done to get this fixed?
The downstream kernel platform_max configuration should really be using the user visible value, not a direct register value. Note that some of the Qualcomm vendor trees have modifictions to the semantics of some of the controls which cause issues, and partly due to this confusion there should be some fixes for their upstream drivers coming soon.
Re: [PATCH 4.9 34/48] ASoC: ops: Reject out of bounds values in snd_soc_put_volsw_sx()
Quoted 12 lines · Mark Brown
Quoted 9 lines · Pavel Machek
We are getting reports that this commit breaks audio on some phones... and indeed it looks like "+ min" is missing in first condition:
val = ucontrol->value.integer.value[0];- if (
mc->platform_max&& val >mc->platform_max)
+ if (mc->platform_max&& ((int)val + min) >mc->platform_max)
 return-EINVAL;
Quoted 8 lines
Quoted 1 line
What needs to be done to get this fixed?
The downstream kernel
platform_maxconfiguration should really be using the user visible value, not a direct register value. Note that some of the Qualcomm vendor trees have modifictions to the semantics of some of the controls which cause issues, and partly due to this confusion there should be some fixes for their upstream drivers coming soon.
Actually potentially we want to revert the handling of platform_max only. Do we know where these systems are getting their platform_max values from (a machine driver or sometehing else?)? Sadly these controls were not even self consistent so it's not clear which behaviour to fix, though fortunately it's all in the areas where the userspaces were out of spec trying to use the behaviour.
Greg Kroah-Hartman
maintainerPATCH 35/48 ASoC: ops: Reject out of bounds values in snd_soc_put_xr_sx()
In reply to Greg Kroah-HartmanFrom: Mark Brown <[email protected]>
commit 4cf28e9ae6e2e11a044be1bcbcfa1b0d8675fe4d upstream.
We don't currently validate that the values being set are within the range we advertised to userspace as being valid, do so and reject any values that are out of range.
--- sound/soc/soc-ops.c | 2 ++ 1 file changed, 2 insertions(+)
sound/soc/soc-ops.c +2 -0
@@ -915,6 +915,8 @@ int snd_soc_put_xr_sx(struct snd_kcontrounsigned int i, regval, regmask;int err; +if (val < mc->min || val > mc->max) +return -EINVAL ;if (invert) val = max - val; val &= mask;
Greg Kroah-Hartman
maintainerPATCH 36/48 drm/nouveau: fix off by one in BIOS boundary checking
In reply to Greg Kroah-HartmanFrom: Nick Lopez <[email protected]>
commit 1b777d4d9e383d2744fc9b3a09af6ec1893c8b1a upstream.
Bounds checking when parsing init scripts embedded in the BIOS reject access to the last byte. This causes driver initialization to fail on Apple eMac's with GeForce 2 MX GPUs, leaving the system with no working console.
This is probably only seen on OpenFirmware machines like PowerPC Macs because the BIOS image provided by OF is only the used parts of the ROM, not a power-of-two blocks read from PCI directly so PCs always have empty bytes at the end that are never accessed.
--- drivers/gpu/drm/nouveau/nvkm/subdev/bios/base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/nouveau/nvkm/subdev/bios/base.c +1 -1
@@ -38,7 +38,7 @@ nvbios_addr(struct nvkm_bios *bios, u32 *addr += bios->imaged_addr; } -if (unlikely (*addr + size >= bios->size)) { +if (unlikely (*addr + size > bios->size)) {nvkm_error (&bios->subdev,"OOB %d %08x %08x\n" , size, p, *addr);return false; }
Greg Kroah-Hartman
maintainerPATCH 37/48 iommu/amd: Fix loop timeout issue in iommu_ga_log_enable()
In reply to Greg Kroah-HartmanFrom: Joerg Roedel <[email protected]>
commit 9b45a7738eec52bf0f5d8d3d54e822962781c5f2 upstream.
The polling loop for the register change in iommu_ga_log_enable() needs to have a udelay() in it. Otherwise the CPU might be faster than the IOMMU hardware and wrongly trigger the WARN_ON() further down the code stream. Use a 10us for udelay(), has there is some hardware where activation of the GA log can take more than a 100ms.
A future optimization should move the activation check of the GA log to the point where it gets used for the first time. But that is a bigger change and not suitable for a fix.
--- drivers/iommu/amd_iommu_init.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/iommu/amd_iommu_init.c +2 -0
@@ -28,6 +28,7 @@#include <linux/amd-iommu.h> #include <linux/export.h> #include <linux/iommu.h> +#include <linux/iopoll.h> #include <asm/pci-direct.h> #include <asm/iommu.h> #include <asm/gart.h>
@@ -715,6 +716,7 @@ static int iommu_ga_log_enable(struct am status =readl (iommu->mmio_base +MMIO_STATUS_OFFSET );if (status & (MMIO_STATUS_GALOG_RUN_MASK ))break ; +udelay (10 ); }if (i >=LOOP_TIMEOUT )
Greg Kroah-Hartman
maintainerPATCH 38/48 spi: bcm-qspi: check for valid cs before applying chip select
In reply to Greg Kroah-HartmanFrom: Kamal Dasu <[email protected]>
commit 2cbd27267ffe020af1442b95ec57f59a157ba85c upstream.
Apply only valid chip select value. This change fixes case where chip select is set to initial value of '-1' during probe and PM supend and subsequent resume can try to use the value with undefined behaviour. Also in case where gpio based chip select, the check in bcm_qspi_chip_select() shall prevent undefined behaviour on resume.
--- drivers/spi/spi-bcm-qspi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/spi/spi-bcm-qspi.c +1 -1
@@ -546,7 +546,7 @@ static void bcm_qspi_chip_select(structu32 rd =0 ;u32 wr =0 ; -if (qspi->base[CHIP_SELECT ]) { +if (cs >=0 && qspi->base[CHIP_SELECT ]) { rd =bcm_qspi_read (qspi,CHIP_SELECT ,0 ); wr = (rd & ~0xff ) | (1 << cs);if (rd == wr)
Greg Kroah-Hartman
maintainerPATCH 39/48 spi: mediatek: Avoid NULL pointer crash in interrupt
In reply to Greg Kroah-HartmanFrom: Benjamin Gaignard <[email protected]>
commit f83a96e5f033fbbd21764705cb9c04234b96218e upstream.
In some case, like after a transfer timeout, master->cur_msg pointer is NULL which led to a kernel crash when trying to use master->cur_msg->spi. mtk_spi_can_dma(), pointed by master->can_dma, doesn't use this parameter avoid the problem by setting NULL as second parameter.
--- drivers/spi/spi-mt65xx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/spi/spi-mt65xx.c +1 -1
@@ -440,7 +440,7 @@ static irqreturn_t mtk_spi_interrupt(intelse mdata->state =MTK_SPI_IDLE ; -if (!master->can_dma (master, master->cur_msg->spi, trans)) { +if (!master->can_dma (master,NULL , trans)) {if (trans->rx_buf) { cnt = mdata->xfer_len /4 ; ioread32_rep(mdata->base + SPI_RX_DATA_REG,
Greg Kroah-Hartman
maintainerPATCH 40/48 net: ieee802154: Return meaningful error codes from the netlink helpers
In reply to Greg Kroah-HartmanFrom: Miquel Raynal <[email protected]>
commit 79c37ca73a6e9a33f7b2b7783ba6af07a448c8a9 upstream.
Returning -1 does not indicate anything useful.
Use a standard and meaningful error code instead.
--- net/ieee802154/nl802154.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
net/ieee802154/nl802154.c +4 -4
@@ -1474,7 +1474,7 @@ static int nl802154_send_key(struct sk_b hdr =nl802154hdr_put (msg, portid, seq, flags, cmd);if (!hdr) -return -1 ; +return -ENOBUFS ;if (nla_put_u32 (msg,NL802154_ATTR_IFINDEX , dev->ifindex)) goto nla_put_failure;
@@ -1665,7 +1665,7 @@ static int nl802154_send_device(struct s hdr =nl802154hdr_put (msg, portid, seq, flags, cmd);if (!hdr) -return -1 ; +return -ENOBUFS ;if (nla_put_u32 (msg,NL802154_ATTR_IFINDEX , dev->ifindex)) goto nla_put_failure;
@@ -1843,7 +1843,7 @@ static int nl802154_send_devkey(struct s hdr =nl802154hdr_put (msg, portid, seq, flags, cmd);if (!hdr) -return -1 ; +return -ENOBUFS ;if (nla_put_u32 (msg,NL802154_ATTR_IFINDEX , dev->ifindex)) goto nla_put_failure;
@@ -2020,7 +2020,7 @@ static int nl802154_send_seclevel(struct hdr =nl802154hdr_put (msg, portid, seq, flags, cmd);if (!hdr) -return -1 ; +return -ENOBUFS ;if (nla_put_u32 (msg,NL802154_ATTR_IFINDEX , dev->ifindex)) goto nla_put_failure;
Greg Kroah-Hartman
maintainerPATCH 41/48 net: macsec: Verify that send_sci is on when setting Tx sci explicitly
In reply to Greg Kroah-HartmanFrom: Lior Nahmanson <[email protected]>
commit d0cfa548dbde354de986911d3913897b5448faad upstream.
When setting Tx sci explicit, the Rx side is expected to use this sci and not recalculate it from the packet.However, in case of Tx sci is explicit and send_sci is off, the receiver is wrongly recalculate the sci from the source MAC address which most likely be different than the explicit sci.
Fix by preventing such configuration when macsec newlink is established and return EINVAL error code on such cases.
--- drivers/net/macsec.c | 9 +++++++++ 1 file changed, 9 insertions(+)
drivers/net/macsec.c +9 -0
@@ -3230,6 +3230,15 @@ static int macsec_newlink(struct net *ne macsec->real_dev = real_dev; +/* send_sci must be set to true when transmit sci explicitly is set */ +if ((data && data[IFLA_MACSEC_SCI ]) && + (data && data[IFLA_MACSEC_INC_SCI ])) { +u8 send_sci = !!nla_get_u8 (data[IFLA_MACSEC_INC_SCI ]); + +if (!send_sci) +return -EINVAL ; + } +if (data && data[IFLA_MACSEC_ICV_LEN ]) icv_len =nla_get_u8 (data[IFLA_MACSEC_ICV_LEN ]); mtu = real_dev->mtu - icv_len -macsec_extra_len (true);
Greg Kroah-Hartman
maintainerPATCH 42/48 ASoC: fsl: Add missing error handling in pcm030_fabric_probe
In reply to Greg Kroah-HartmanFrom: Miaoqian Lin <[email protected]>
commit fb25621da5702c104ce0a48de5b174ced09e5b4e upstream.
Add the missing platform_device_put() and platform_device_del() before return from pcm030_fabric_probe in the error handling case.
--- sound/soc/fsl/pcm030-audio-fabric.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
sound/soc/fsl/pcm030-audio-fabric.c +8 -3
@@ -90,16 +90,21 @@ static int pcm030_fabric_probe(struct pldev_err (&op->dev,"platform_device_alloc() failed\n" ); ret =platform_device_add (pdata->codec_device); -if (ret) +if (ret) {dev_err (&op->dev,"platform_device_add() failed: %d\n" , ret); +platform_device_put (pdata->codec_device); + } ret =snd_soc_register_card (card); -if (ret) +if (ret) {dev_err (&op->dev,"snd_soc_register_card() failed: %d\n" , ret); +platform_device_del (pdata->codec_device); +platform_device_put (pdata->codec_device); + }platform_set_drvdata (op, pdata); -return ret; + }static int pcm030_fabric_remove (struct platform_device *op)
Greg Kroah-Hartman
maintainerPATCH 43/48 scsi: bnx2fc: Make bnx2fc_recv_frame() mp safe
In reply to Greg Kroah-HartmanFrom: John Meneghini <[email protected]>
commit 936bd03405fc83ba039d42bc93ffd4b88418f1d3 upstream.
Running tests with a debug kernel shows that bnx2fc_recv_frame() is modifying the per_cpu lport stats counters in a non-mpsafe way. Just boot a debug kernel and run the bnx2fc driver with the hardware enabled.
[ 1391.699147] BUG: using smp_processor_id() in preemptible [00000000] code: bnx2fc_ [ 1391.699160] caller is bnx2fc_recv_frame+0xbf9/0x1760 [bnx2fc] [ 1391.699174] CPU: 2 PID: 4355 Comm: bnx2fc_l2_threa Kdump: loaded Tainted: G B [ 1391.699180] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013 [ 1391.699183] Call Trace: [ 1391.699188] dump_stack_lvl+0x57/0x7d [ 1391.699198] check_preemption_disabled+0xc8/0xd0 [ 1391.699205] bnx2fc_recv_frame+0xbf9/0x1760 [bnx2fc] [ 1391.699215] ? do_raw_spin_trylock+0xb5/0x180 [ 1391.699221] ? bnx2fc_npiv_create_vports.isra.0+0x4e0/0x4e0 [bnx2fc] [ 1391.699229] ? bnx2fc_l2_rcv_thread+0xb7/0x3a0 [bnx2fc] [ 1391.699240] bnx2fc_l2_rcv_thread+0x1af/0x3a0 [bnx2fc] [ 1391.699250] ? bnx2fc_ulp_init+0xc0/0xc0 [bnx2fc] [ 1391.699258] kthread+0x364/0x420 [ 1391.699263] ? _raw_spin_unlock_irq+0x24/0x50 [ 1391.699268] ? set_kthread_struct+0x100/0x100 [ 1391.699273] ret_from_fork+0x22/0x30
Restore the old get_cpu/put_cpu code with some modifications to reduce the size of the critical section.
--- drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-)
drivers/scsi/bnx2fc/bnx2fc_fcoe.c +13 -8
@@ -521,7 +521,8 @@ static int bnx2fc_l2_rcv_thread(void *arstatic void bnx2fc_recv_frame (struct sk_buff *skb) { -u32 fr_len; +u64 crc_err; +u32 fr_len, fr_crc;struct fc_lport *lport;struct fcoe_rcv_info *fr;struct fc_stats *stats;
@@ -553,6 +554,11 @@ static void bnx2fc_recv_frame(struct sk_skb_pull (skb,sizeof (struct fcoe_hdr )); fr_len = skb->len -sizeof (struct fcoe_crc_eof ); + stats =per_cpu_ptr (lport->stats,get_cpu ()); + stats->RxFrames++; + stats->RxWords += fr_len /FCOE_WORD_TO_BYTE ; +put_cpu (); + fp = (struct fc_frame *)skb;fc_frame_init (fp);fr_dev (fp) = lport;
@@ -604,16 +610,15 @@ static void bnx2fc_recv_frame(struct sk_return ; } - stats =per_cpu_ptr (lport->stats,smp_processor_id ()); - stats->RxFrames++; - stats->RxWords += fr_len /FCOE_WORD_TO_BYTE ; + fr_crc =le32_to_cpu (fr_crc (fp)); -if (le32_to_cpu (fr_crc (fp)) != - ~crc32 (~0 , skb->data, fr_len)) { -if (stats->InvalidCRCCount <5 ) +if (unlikely (fr_crc != ~crc32 (~0 , skb->data, fr_len))) { + stats =per_cpu_ptr (lport->stats,get_cpu ()); + crc_err = (stats->InvalidCRCCount++); +put_cpu (); +if (crc_err <5 ) printk(KERN_WARNING PFX "dropping frame with ""CRC error\n" ); - stats->InvalidCRCCount++;kfree_skb (skb);return ; }
Greg Kroah-Hartman
maintainerPATCH 44/48 nfsd: nfsd4_setclientid_confirm mistakenly expires confirmed client.
In reply to Greg Kroah-HartmanFrom: Dai Ngo <[email protected]>
commit ab451ea952fe9d7afefae55ddb28943a148247fe upstream.
Quoted 1 line
From RFC 7530 Section 16.34.5:
o The server has not recorded an unconfirmed { v, x, c, *, * } and has recorded a confirmed { v, x, c, *, s }. If the principals of the record and of SETCLIENTID_CONFIRM do not match, the server returns NFS4ERR_CLID_INUSE without removing any relevant leased client state, and without changing recorded callback and callback_ident values for client { x }.
The current code intends to do what the spec describes above but it forgot to set 'old' to NULL resulting to the confirmed client to be expired.
--- fs/nfsd/nfs4state.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
fs/nfsd/nfs4state.c +3 -1
@@ -3424,8 +3424,10 @@ nfsd4_setclientid_confirm(struct svc_rqs status = nfserr_clid_inuse;if (client_has_state (old) && !same_creds (&unconf->cl_cred, - &old->cl_cred)) + &old->cl_cred)) { + old =NULL ; goto out; + } status =mark_client_expired_locked (old);if (status) { old =NULL ;
Greg Kroah-Hartman
maintainerPATCH 45/48 rtc: cmos: Evaluate century appropriate
In reply to Greg Kroah-HartmanFrom: Riwen Lu <[email protected]>
commit ff164ae39b82ee483b24579c8e22a13a8ce5bd04 upstream.
There's limiting the year to 2069. When setting the rtc year to 2070, reading it returns 1970. Evaluate century starting from 19 to count the correct year.
$ sudo date -s 20700106 Mon 06 Jan 2070 12:00:00 AM CST $ sudo hwclock -w $ sudo hwclock -r 1970-01-06 12:00:49.604968+08:00
--- drivers/rtc/rtc-mc146818-lib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/rtc/rtc-mc146818-lib.c +1 -1
@@ -82,7 +82,7 @@ unsigned int mc146818_get_time(struct rt time->tm_year += real_year -72 ;#endif -if (century >20 ) +if (century >19 ) time->tm_year += (century -19 ) *100 ;/*
Greg Kroah-Hartman
maintainerPATCH 46/48 EDAC/altera: Fix deferred probing
In reply to Greg Kroah-HartmanFrom: Sergey Shtylyov <[email protected]>
commit 279eb8575fdaa92c314a54c0d583c65e26229107 upstream.
The driver overrides the error codes returned by platform_get_irq() to -ENODEV for some strange reason, so if it returns -EPROBE_DEFER, the driver will fail the probe permanently instead of the deferred probing. Switch to propagating the proper error codes to platform driver code upwards.
[ bp: Massage commit message. ]
--- drivers/edac/altera_edac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/edac/altera_edac.c +1 -1
@@ -363,7 +363,7 @@ static int altr_sdram_probe(struct platfif (irq <0 ) {edac_printk (KERN_ERR ,EDAC_MC ,"No irq %d in DT\n" , irq); -return -ENODEV ; +return irq; }/* Arria10 has a 2nd IRQ */
Greg Kroah-Hartman
maintainerPATCH 47/48 EDAC/xgene: Fix deferred probing
In reply to Greg Kroah-HartmanFrom: Sergey Shtylyov <[email protected]>
commit dfd0dfb9a7cc04acf93435b440dd34c2ca7b4424 upstream.
The driver overrides error codes returned by platform_get_irq_optional() to -EINVAL for some strange reason, so if it returns -EPROBE_DEFER, the driver will fail the probe permanently instead of the deferred probing. Switch to propagating the proper error codes to platform driver code upwards.
[ bp: Massage commit message. ]
--- drivers/edac/xgene_edac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/edac/xgene_edac.c +1 -1
@@ -1936,7 +1936,7 @@ static int xgene_edac_probe(struct platf irq =platform_get_irq (pdev, i);if (irq <0 ) {dev_err (&pdev->dev,"No IRQ resource\n" ); - rc = -EINVAL ; + rc = irq; goto out_err; } rc = devm_request_irq(&pdev->dev, irq,
Greg Kroah-Hartman
maintainerPATCH 48/48 ext4: fix error handling in ext4_restore_inline_data()
In reply to Greg Kroah-HartmanFrom: Ritesh Harjani <[email protected]>
commit 897026aaa73eb2517dfea8d147f20ddb0b813044 upstream.
While running "./check -I 200 generic/475" it sometimes gives below kernel BUG(). Ideally we should not call ext4_write_inline_data() if ext4_create_inline_data() has failed.
<log snip>
[73131.453234] kernel BUG at fs/ext4/inline.c:223!
<code snip>
212 static void ext4_write_inline_data(struct inode *inode, struct ext4_iloc *iloc,
213 void *buffer, loff_t pos, unsigned int len)
214 {
<...>
223 BUG_ON(!EXT4_I(inode)->i_inline_off);
224 BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);
This patch handles the error and prints out a emergency msg saying potential data loss for the given inode (since we couldn't restore the original inline_data due to some previous error).
[ 9571.070313] EXT4-fs (dm-0): error restoring inline_data for inode -- potential data loss! (inode 1703982, error -30)
--- fs/ext4/inline.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
fs/ext4/inline.c +9 -1
@@ -1123,7 +1123,15 @@ static void ext4_restore_inline_data(hanstruct ext4_iloc *iloc, void *buf, int inline_size) { -ext4_create_inline_data (handle ,inode ,inline_size ); + int ret; + + ret =ext4_create_inline_data (handle, inode, inline_size); +if (ret) { +ext4_msg (inode->i_sb,KERN_EMERG , +"error restoring inline_data for inode -- potential data loss! (inode %lu, error %d)" , + inode->i_ino, ret); +return ; + }ext4_write_inline_data (inode, iloc, buf,0 , inline_size);ext4_set_inode_state (inode,EXT4_STATE_MAY_INLINE_DATA ); }
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.300 release. There are 48 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, 09 Feb 2022 10:37:42 +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.300-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 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.300 release. There are 48 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, 09 Feb 2022 10:37:42 +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
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.300 release. There are 48 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, 09 Feb 2022 10:37:42 +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.300-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 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.300 release. There are 48 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, 09 Feb 2022 10:37:42 +0000. Anything received after that time might be too late.
Compiled and booted 4.9.300-rc1 on my x86_64 test system successfully without errors or regressions.
Thanks,
Slade
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.300 release. There are 48 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, 09 Feb 2022 10:37:42 +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.300-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.300-rc1-gfa39f098578a
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04
Jon
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.300 release. There are 48 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, 09 Feb 2022 10:37:42 +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.300-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.300-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git branch: linux-4.9.y
* git commit: fa39f098578af99470f3762bca8001c0db1c3335
* git describe: v4.9.299-49-gfa39f098578a
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.9.y/build/v4.9.299-49-gfa39f098578a
## Test Regressions (compared to v4.9.299-33-g5e40da2b7be3) No test regressions found.
## Metric Regressions (compared to v4.9.299-33-g5e40da2b7be3) No metric regressions found.
## Test Fixes (compared to v4.9.299-33-g5e40da2b7be3) No test fixes found.
## Metric Fixes (compared to v4.9.299-33-g5e40da2b7be3) No metric fixes found.
## Test result summary
total: 62346, pass: 50123, fail: 394, skip: 10326, xfail: 1503
## Build Summary
* arm: 254 total, 238 passed, 16 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-arm64/arm64.btitest.bti_c_func
* kselftest-arm64/arm64.btitest.bti_j_func
* kselftest-arm64/arm64.btitest.bti_jc_func
* kselftest-arm64/arm64.btitest.bti_none_func
* kselftest-arm64/arm64.btitest.nohint_func
* kselftest-arm64/arm64.btitest.paciasp_func
* kselftest-arm64/arm64.nobtitest.bti_c_func
* kselftest-arm64/arm64.nobtitest.bti_j_func
* kselftest-arm64/arm64.nobtitest.bti_jc_func
* kselftest-arm64/arm64.nobtitest.bti_none_func
* kselftest-arm64/arm64.nobtitest.nohint_func
* kselftest-arm64/arm64.nobtitest.paciasp_func
* 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-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* 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
--
Linaro LKFT
https://lkft.linaro.org