- Mar 26, 2020
-
-
Johannes Berg authored
If we know that we have an encrypted link (based on having had a key configured for TX in the past) then drop all data frames in the key selection handler if there's no key anymore. This fixes an issue with mac80211 internal TXQs - there we can buffer frames for an encrypted link, but then if the key is no longer there when they're dequeued, the frames are sent without encryption. This happens if a station is disconnected while the frames are still on the TXQ. Detecting that a link should be encrypted based on a first key having been configured for TX is fine as there are no use cases for a connection going from with encryption to no encryption. With extended key IDs, however, there is a case of having a key configured for only decryption, so we can't just trigger this behaviour on a key being configured. Cc: stable@vger.kernel.org Reported-by:
Jouni Malinen <j@w1.fi> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200326150855.6865c7f28a14.I9fb1d911b064262d33e33dfba730cdeef83926ca@changeid Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
- Mar 25, 2020
-
-
Johannes Berg authored
The he_sr_control field is just a u8, so le32_to_cpu() shouldn't be applied to it; this was evidently copied from ieee80211_he_oper_size(). Fix it, and also adjust the type of the local variable. Fixes: ef11a931bd1c ("mac80211: HE: add Spatial Reuse element parsing support") Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Link: https://lore.kernel.org/r/20200325090918.dfe483b49e06.Ia53622f23b2610a2ae6ea39a199866196fe946c1@changeid Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
The new opmode notification used this attribute with a u8, when it's documented as a u32 and indeed used in userspace as such, it just happens to work on little-endian systems since userspace isn't doing any strict size validation, and the u8 goes into the lower byte. Fix this. Cc: stable@vger.kernel.org Fixes: 466b9936 ("cfg80211: Add support to notify station's opmode change to userspace") Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Link: https://lore.kernel.org/r/20200325090531.be124f0a11c7.Iedbf4e197a85471ebd729b186d5365c0343bf7a8@changeid Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
- Mar 18, 2020
-
-
Mauro Carvalho Chehab authored
There's a markup for link with is "foo_". On this kernel-doc comment, we don't want this, but instead, place a literal reference. So, escape the literal with ``foo``, in order to avoid this warning: ./net/core/dev.c:5195: WARNING: Unknown target name: "page_is". Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Mauro Carvalho Chehab authored
The indentation for the returned values are weird, causing those warnings: ./drivers/net/phy/sfp-bus.c:579: WARNING: Unexpected indentation. ./drivers/net/phy/sfp-bus.c:619: WARNING: Unexpected indentation. Use a list and change the identation for it to be properly parsed by the documentation toolchain. Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Arthur Kiyanovski says: ==================== ENA driver bug fixes ==================== Acked-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Arthur Kiyanovski authored
last_keep_alive_jiffies is updated in probe and when a keep-alive event is received. In case the driver times-out on a keep-alive event, it has high chances of continuously timing-out on keep-alive events. This is because when the driver recovers from the keep-alive-timeout reset the value of last_keep_alive_jiffies is very old, and if a keep-alive event is not received before the next timer expires, the value of last_keep_alive_jiffies will cause another keep-alive-timeout reset and so forth in a loop. Solution: Update last_keep_alive_jiffies whenever the device is restored after reset. Fixes: 1738cd3e ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by:
Noam Dagan <ndagan@amazon.com> Signed-off-by:
Arthur Kiyanovski <akiyano@amazon.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Arthur Kiyanovski authored
Rx req_id is an index in struct ena_eth_io_rx_cdesc_base. The driver should validate that the Rx req_id it received from the device is in range [0, ring_size -1]. Failure to do so could yield to potential memory access violoation. The validation was mistakenly done when refilling the Rx submission queue and not in Rx completion queue. Fixes: ad974bae ("net: ena: add support for out of order rx buffers refill") Signed-off-by:
Noam Dagan <ndagan@amazon.com> Signed-off-by:
Arthur Kiyanovski <akiyano@amazon.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Arthur Kiyanovski authored
Bug: In short the main issue is caused by the fact that the number of queues is changed using ethtool after ena_probe() has been called and before ena_up() was executed. Here is the full scenario in detail: * ena_probe() is called when the driver is loaded, the driver is not up yet at the end of ena_probe(). * The number of queues is changed -> io_queue_count is changed as well - ena_up() is not called since the "dev_was_up" boolean in ena_update_queue_count() is false. * ena_up() is called by the kernel (it's called asynchronously some time after ena_probe()). ena_setup_io_intr() is called by ena_up() and it uses io_queue_count to get the suitable irq lines for each msix vector. The function ena_request_io_irq() is called right after that and it uses msix_vecs - This value only changes during ena_probe() and ena_restore() - to request the irq vectors. This results in "Failed to request I/O IRQ" error for i > io_queue_count. Numeric example: * After ena_probe() io_queue_count = 8, msix_vecs = 9. * The number of queues changes to 4 -> io_queue_count = 4, msix_vecs = 9. * ena_up() is executed for the first time: ** ena_setup_io_intr() inits the vectors only up to io_queue_count. ** ena_request_io_irq() calls request_irq() and fails for i = 5. How to reproduce: simply run the following commands: sudo rmmod ena && sudo insmod ena.ko; sudo ethtool -L eth1 combined 3; Fix: Use ENA_MAX_MSIX_VEC(adapter->num_io_queues + adapter->xdp_num_queues) instead of adapter->msix_vecs. We need to take XDP queues into consideration as they need to have msix vectors assigned to them as well. Note that the XDP cannot be attached before the driver is up and running but in XDP mode the issue might occur when the number of queues changes right after a reset trigger. The ENA_MAX_MSIX_VEC simply adds one to the argument since the first msix vector is reserved for management queue. Fixes: 1738cd3e ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by:
Sameeh Jubran <sameehj@amazon.com> Signed-off-by:
Arthur Kiyanovski <akiyano@amazon.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Arthur Kiyanovski authored
Overview: We don't frequently change the msix vectors throughout the life cycle of the driver. We do so in two functions: ena_probe() and ena_restore(). ena_probe() is only called when the driver is loaded. ena_restore() on the other hand is called during device reset / resume operations. We use num_io_queues for calculating and allocating the number of msix vectors. At ena_probe() this value is equal to max_num_io_queues and thus this is not an issue, however ena_restore() might be called after the number of io queues has changed. A possible bug scenario is as follows: * Change number of queues from 8 to 4. (num_io_queues = 4, max_num_io_queues = 8, msix_vecs = 9,) * Trigger reset occurs -> ena_restore is called. (num_io_queues = 4, max_num_io_queues =8 , msix_vecs = 5) * Change number of queues from 4 to 6. (num_io_queues = 6, max_num_io_queues = 8, msix_vecs = 5) * The driver will reset due to failure of check_for_rx_interrupt_queue() Fix: This can be easily fixed by always using max_num_io_queues to init the msix_vecs, since this number won't change as opposed to num_io_queues. Fixes: 4d192660 ("net: ena: multiple queue creation related cleanups") Signed-off-by:
Sameeh Jubran <sameehj@amazon.com> Signed-off-by:
Arthur Kiyanovski <akiyano@amazon.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Rayagonda Kokatanur authored
Check clk_prepare_enable() return value. Fixes: 2c723044 ("net: phy: Add pm support to Broadcom iProc mdio mux driver") Signed-off-by:
Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Doug Berger says: ==================== net: bcmgenet: revisit MAC reset Commit 3a55402c ("net: bcmgenet: use RGMII loopback for MAC reset") was intended to resolve issues with reseting the UniMAC core within the GENET block by providing better control over the clocks used by the UniMAC core. Unfortunately, it is not compatible with all of the supported system configurations so an alternative method must be applied. This commit set provides such an alternative. The first commit reverts the previous change and the second commit provides the alternative reset sequence that addresses the concerns observed with the previous implementation. This replacement implementation should be applied to the stable branches wherever commit 3a55402c ("net: bcmgenet: use RGMII loopback for MAC reset") has been applied. Unfortunately, reverting that commit may conflict with some restructuring changes introduced by commit 4f8d81b7 ("net: bcmgenet: Refactor register access in bcmgenet_mii_config"). The first commit in this set has been manually edited to resolve the conflict on net/master. I would be happy to help stable maintainers with resolving any such conflicts if they occur. However, I do not expect that commit to have been backported to stable branch so hopefully the revert can be applied cleanly. ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Doug Berger authored
As noted in commit 28c2d1a7 ("net: bcmgenet: enable loopback during UniMAC sw_reset") the UniMAC must be clocked at least 5 cycles while the sw_reset is asserted to ensure a clean reset. That commit enabled local loopback to provide an Rx clock from the GENET sourced Tx clk. However, when connected in MII mode the Tx clk is sourced by the PHY so if an EPHY is not supplying clocks (e.g. when the link is down) the UniMAC does not receive the necessary clocks. This commit extends the sw_reset window until the PHY reports that the link is up thereby ensuring that the clocks are being provided to the MAC to produce a clean reset. One consequence is that if the system attempts to enter a Wake on LAN suspend state when the PHY link has not been active the MAC may not have had a chance to initialize cleanly. In this case, we remove the sw_reset and enable the WoL reception path as normal with the hope that the PHY will provide the necessary clocks to drive the WoL blocks if the link becomes active after the system has entered suspend. Fixes: 1c1008c7 ("net: bcmgenet: add main driver file") Signed-off-by:
Doug Berger <opendmb@gmail.com> Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Doug Berger authored
This reverts commit 3a55402c . This is not a good solution when connecting to an external switch that may not support the isolation of the TXC signal resulting in output driver contention on the pin. A different solution is necessary. Signed-off-by:
Doug Berger <opendmb@gmail.com> Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Chris Packham says: ==================== net: mvmdio: avoid error message for optional IRQ I've gone ahead an sent a revert. This is the same as the original v1 except I've added Andrew's review to the commit message. ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Chris Packham authored
Per the dt-binding the interrupt is optional so use platform_get_irq_optional() instead of platform_get_irq(). Since commit 7723f4c5 ("driver core: platform: Add an error message to platform_get_irq*()") platform_get_irq() produces an error message orion-mdio f1072004.mdio: IRQ index 0 not found which is perfectly normal if one hasn't specified the optional property in the device tree. Signed-off-by:
Chris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Chris Packham authored
This reverts commit e1f550dc . platform_get_irq_optional() will still return -ENXIO when no interrupt is provided so the additional error handling caused the driver prone to fail when no interrupt was specified. Revert the change so we can apply the correct minimal fix. Signed-off-by:
Chris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- Mar 17, 2020
-
-
Petr Machata authored
The fix referenced below causes a crash when an ERSPAN tunnel is created without passing IFLA_INFO_DATA. Fix by validating passed-in data in the same way as ipgre does. Fixes: e1f8f78f ("net: ip_gre: Separate ERSPAN newlink / changelink callbacks") Reported-by:
<syzbot+1b4ebf4dae4e510dd219@syzkaller.appspotmail.com> Signed-off-by:
Petr Machata <petrm@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jisheng Zhang authored
For the case where the last mvneta_poll did not process all RX packets, we need to xor the pp->cause_rx_tx or port->cause_rx_tx before claculating the rx_queue. Fixes: 2dcf75e2 ("net: mvneta: Associate RX queues with each CPU") Signed-off-by:
Jisheng Zhang <Jisheng.Zhang@synaptics.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Zheng Wei authored
printk in macro vxge_debug_ll uses __VA_ARGS__ without "##" prefix, it causes a build error when there is no variable arguments(e.g. only fmt is specified.). Signed-off-by:
Zheng Wei <wei.zheng@vivo.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Madalin Bucur says: ==================== QorIQ DPAA ARM RDBs need internal delay on RGMII v2: used phy_interface_mode_is_rgmii() to identify RGMII The QorIQ DPAA 1 based RDB boards require internal delay on both Tx and Rx to be set. The patch set ensures all RGMII modes are treated correctly by the FMan driver and sets the phy-connection-type to "rgmii-id" to restore functionality. Previously Rx internal delay was set by board pull-ups and was left untouched by the PHY driver. Since commit 1b3047b5 ("net: phy: realtek: add support for configuring the RX delay on RTL8211F") the Realtek 8211F PHY driver has control over the RGMII RX delay and it is disabling it for other modes than RGMII_RXID and RGMII_ID. Please note that u-boot in particular performs a fix-up of the PHY connection type and will overwrite the values from the Linux device tree. Another patch set was sent for u-boot and one needs to apply that [1] to the boot loader, to ensure this fix is complete, unless a different bootloader is used. ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Madalin Bucur authored
The correct setting for the RGMII ports on LS1046ARDB is to enable delay on both Rx and Tx so the interface mode used must be PHY_INTERFACE_MODE_RGMII_ID. Since commit 1b3047b5 ("net: phy: realtek: add support for configuring the RX delay on RTL8211F") the Realtek 8211F PHY driver has control over the RGMII RX delay and it is disabling it for RGMII_TXID. The LS1046ARDB uses two such PHYs in RGMII_ID mode but in the device tree the mode was described as "rgmii". Changing the phy-connection-type to "rgmii-id" to address the issue. Fixes: 3fa395d2 ("arm64: dts: add LS1046A DPAA FMan nodes") Signed-off-by:
Madalin Bucur <madalin.bucur@oss.nxp.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Madalin Bucur authored
The correct setting for the RGMII ports on LS1043ARDB is to enable delay on both Rx and Tx so the interface mode used must be PHY_INTERFACE_MODE_RGMII_ID. Since commit 1b3047b5 ("net: phy: realtek: add support for configuring the RX delay on RTL8211F") the Realtek 8211F PHY driver has control over the RGMII RX delay and it is disabling it for RGMII_TXID. The LS1043ARDB uses two such PHYs in RGMII_ID mode but in the device tree the mode was described as "rgmii_txid". This issue was not apparent at the time as the PHY driver took the same action for RGMII_TXID and RGMII_ID back then but it became visible (RX no longer working) after the above patch. Changing the phy-connection-type to "rgmii-id" to address the issue. Fixes: bf02f2ff ("arm64: dts: add LS1043A DPAA FMan support") Signed-off-by:
Madalin Bucur <madalin.bucur@oss.nxp.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Madalin Bucur authored
Treat all internal delay variants the same as RGMII. Signed-off-by:
Madalin Bucur <madalin.bucur@oss.nxp.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- Mar 16, 2020
-
-
David S. Miller authored
Michal Kubecek says: ==================== ethtool: fail with error if request has unknown flags Jakub Kicinski pointed out that if unrecognized flags are set in netlink header request, kernel shoud fail with an error rather than silently ignore them so that we have more freedom in future flags semantics. To help userspace with handling such errors, inform the client which flags are supported by kernel. For that purpose, we need to allow passing cookies as part of extack also in case of error (they can be only passed on success now). ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Michal Kubecek authored
As pointed out by Jakub Kicinski, we ethtool netlink code should respond with an error if request head has flags set which are not recognized by kernel, either as a mistake or because it expects functionality introduced in later kernel versions. To avoid unnecessary roundtrips, use extack cookie to provide the information about supported request flags. Signed-off-by:
Michal Kubecek <mkubecek@suse.cz> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Michal Kubecek authored
Similar to existing nl_set_extack_cookie_u64(), add new helper nl_set_extack_cookie_u32() which sets extack cookie to a u32 value. Signed-off-by:
Michal Kubecek <mkubecek@suse.cz> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Michal Kubecek authored
Commit ba0dc5f6 ("netlink: allow sending extended ACK with cookie on success") introduced a cookie which can be sent to userspace as part of extended ack message in the form of NLMSGERR_ATTR_COOKIE attribute. Currently the cookie is ignored if error code is non-zero but there is no technical reason for such limitation and it can be useful to provide machine parseable information as part of an error message. Include NLMSGERR_ATTR_COOKIE whenever the cookie has been set, regardless of error code. Signed-off-by:
Michal Kubecek <mkubecek@suse.cz> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Cong Wang authored
route4_change() allocates a new filter and copies values from the old one. After the new filter is inserted into the hash table, the old filter should be removed and freed, as the final step of the update. However, the current code mistakenly removes the new one. This looks apparently wrong to me, and it causes double "free" and use-after-free too, as reported by syzbot. Reported-and-tested-by:
<syzbot+f9b32aaacd60305d9687@syzkaller.appspotmail.com> Reported-and-tested-by:
<syzbot+2f8c233f131943d6056d@syzkaller.appspotmail.com> Reported-and-tested-by:
<syzbot+9c2df9fd5e9445b74e01@syzkaller.appspotmail.com> Fixes: 1109c005 ("net: sched: RCU cls_route") Cc: Jamal Hadi Salim <jhs@mojatatu.com> Cc: Jiri Pirko <jiri@resnulli.us> Cc: John Fastabend <john.fastabend@gmail.com> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Taehee Yoo says: ==================== hsr: fix several bugs in generic netlink callback This patchset is to fix several bugs they are related in generic netlink callback in hsr module. 1. The first patch is to add missing rcu_read_lock() in hsr_get_node_{list/status}(). The hsr_get_node_{list/status}() are not protected by RTNL because they are callback functions of generic netlink. But it calls __dev_get_by_index() without acquiring RTNL. So, it would use unsafe data. 2. The second patch is to avoid failure of hsr_get_node_list(). hsr_get_node_list() is a callback of generic netlink and it is used to get node information in userspace. But, if there are so many nodes, it fails because of buffer size. So, in this patch, restart routine is added. 3. The third patch is to set .netnsok flag to true. If .netnsok flag is false, non-init_net namespace is not allowed to operate generic netlink operations. So, currently, non-init_net namespace has no way to get node information because .netnsok is false in the current hsr code. Change log: v1->v2: - Preserve reverse christmas tree variable ordering in the second patch. ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Taehee Yoo authored
The hsr module has been supporting the list and status command. (HSR_C_GET_NODE_LIST and HSR_C_GET_NODE_STATUS) These commands send node information to the user-space via generic netlink. But, in the non-init_net namespace, these commands are not allowed because .netnsok flag is false. So, there is no way to get node information in the non-init_net namespace. Fixes: f421436a ("net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)") Signed-off-by:
Taehee Yoo <ap420073@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Taehee Yoo authored
The hsr_get_node_list() is to send node addresses to the userspace. If there are so many nodes, it could fail because of buffer size. In order to avoid this failure, the restart routine is added. Fixes: f421436a ("net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)") Signed-off-by:
Taehee Yoo <ap420073@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Taehee Yoo authored
hsr_get_node_{list/status}() are not under rtnl_lock() because they are callback functions of generic netlink. But they use __dev_get_by_index() without rtnl_lock(). So, it would use unsafe data. In order to fix it, rcu_read_lock() and dev_get_by_index_rcu() are used instead of __dev_get_by_index(). Fixes: f421436a ("net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)") Signed-off-by:
Taehee Yoo <ap420073@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Takashi Iwai says: ==================== net: Use scnprintf() for avoiding potential buffer overflow here is a respin of trivial patch series just to convert suspicious snprintf() usages with the more safer one, scnprintf(). v1->v2: Align the remaining lines to the open parenthesis Excluded i40e patch that was already queued ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Takashi Iwai authored
Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Cc: "David S . Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: netdev@vger.kernel.org Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Takashi Iwai authored
Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Cc: "David S . Miller" <davem@davemloft.net> Cc: Edward Cree <ecree@solarflare.com> Cc: Martin Habets <mhabets@solarflare.com> Cc: Solarflare linux maintainers <linux-net-drivers@solarflare.com> Cc: netdev@vger.kernel.org Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Takashi Iwai authored
Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Reviewed-by:
Simon Horman <simon.horman@netronome.com> Acked-by:
Shannon Nelson <snelson@pensando.io> Cc: "David S . Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: oss-drivers@netronome.com Cc: netdev@vger.kernel.org Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Takashi Iwai authored
Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Reviewed-by:
Simon Horman <simon.horman@netronome.com> Cc: "David S . Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: oss-drivers@netronome.com To: netdev@vger.kernel.org Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Takashi Iwai authored
Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Cc: "David S . Miller" <davem@davemloft.net> Cc: Tariq Toukan <tariqt@mellanox.com> To: netdev@vger.kernel.org Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Takashi Iwai authored
Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Cc: "David S . Miller" <davem@davemloft.net> Cc: netdev@vger.kernel.org Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
David S. Miller <davem@davemloft.net>
-