- Linux-stable-mirror - lists.linaro.org

[Linux-stable-mirror] Patch "ethtool: do not print warning for applications using legacy API" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ethtool: do not print warning for applications using legacy API to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ethtool-do-not-print-warning-for-applications-using-legacy-api.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sat Jan 13 10:51:19 CET 2018 From: Stephen Hemminger <stephen(a)networkplumber.org> Date: Fri, 29 Dec 2017 10:02:52 -0800 Subject: ethtool: do not print warning for applications using legacy API From: Stephen Hemminger <stephen(a)networkplumber.org> [ Upstream commit 71891e2dab6b55a870f8f7735e44a2963860b5c6 ] In kernel log ths message appears on every boot: "warning: `NetworkChangeNo' uses legacy ethtool link settings API, link modes are only partially reported" When ethtool link settings API changed, it started complaining about usages of old API. Ironically, the original patch was from google but the application using the legacy API is chrome. Linux ABI is fixed as much as possible. The kernel must not break it and should not complain about applications using legacy API's. This patch just removes the warning since using legacy API's in Linux is perfectly acceptable. Fixes: 3f1ac7a700d0 ("net: ethtool: add new ETHTOOL_xLINKSETTINGS API") Signed-off-by: Stephen Hemminger <stephen(a)networkplumber.org> Signed-off-by: David Decotigny <decot(a)googlers.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/core/ethtool.c | 15 ++------------- 1 file changed, 2 insertions(+), 13 deletions(-) --- a/net/core/ethtool.c +++ b/net/core/ethtool.c @@ -742,15 +742,6 @@ static int ethtool_set_link_ksettings(st return dev->ethtool_ops->set_link_ksettings(dev, &link_ksettings); } -static void -warn_incomplete_ethtool_legacy_settings_conversion(const char *details) -{ - char name[sizeof(current->comm)]; - - pr_info_once("warning: `%s' uses legacy ethtool link settings API, %s\n", - get_task_comm(name, current), details); -} - /* Query device for its ethtool_cmd settings. * * Backward compatibility note: for compatibility with legacy ethtool, @@ -777,10 +768,8 @@ static int ethtool_get_settings(struct n &link_ksettings); if (err < 0) return err; - if (!convert_link_ksettings_to_legacy_settings(&cmd, - &link_ksettings)) - warn_incomplete_ethtool_legacy_settings_conversion( - "link modes are only partially reported"); + convert_link_ksettings_to_legacy_settings(&cmd, + &link_ksettings); /* send a sensible cmd tag back to user */ cmd.cmd = ETHTOOL_GSET; Patches currently in stable-queue which might be from stephen(a)networkplumber.org are queue-4.9/ethtool-do-not-print-warning-for-applications-using-legacy-api.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "8021q: fix a memory leak for VLAN 0 device" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled 8021q: fix a memory leak for VLAN 0 device to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: 8021q-fix-a-memory-leak-for-vlan-0-device.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sat Jan 13 10:51:19 CET 2018 From: Cong Wang <xiyou.wangcong(a)gmail.com> Date: Tue, 9 Jan 2018 13:40:41 -0800 Subject: 8021q: fix a memory leak for VLAN 0 device From: Cong Wang <xiyou.wangcong(a)gmail.com> [ Upstream commit 78bbb15f2239bc8e663aa20bbe1987c91a0b75f6 ] A vlan device with vid 0 is allow to creat by not able to be fully cleaned up by unregister_vlan_dev() which checks for vlan_id!=0. Also, VLAN 0 is probably not a valid number and it is kinda "reserved" for HW accelerating devices, but it is probably too late to reject it from creation even if makes sense. Instead, just remove the check in unregister_vlan_dev(). Reported-by: Dmitry Vyukov <dvyukov(a)google.com> Fixes: ad1afb003939 ("vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)") Cc: Vlad Yasevich <vyasevich(a)gmail.com> Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk> Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/8021q/vlan.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) --- a/net/8021q/vlan.c +++ b/net/8021q/vlan.c @@ -111,12 +111,7 @@ void unregister_vlan_dev(struct net_devi vlan_gvrp_uninit_applicant(real_dev); } - /* Take it out of our own structures, but be sure to interlock with - * HW accelerating devices or SW vlan input packet processing if - * VLAN is not 0 (leave it there for 802.1p). - */ - if (vlan_id) - vlan_vid_del(real_dev, vlan->vlan_proto, vlan_id); + vlan_vid_del(real_dev, vlan->vlan_proto, vlan_id); /* Get rid of the vlan's reference to real_dev */ dev_put(real_dev); Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are queue-4.9/8021q-fix-a-memory-leak-for-vlan-0-device.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "sh_eth: fix TSU resource handling" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sh_eth: fix TSU resource handling to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: sh_eth-fix-tsu-resource-handling.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sat Jan 13 10:51:05 CET 2018 From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com> Date: Wed, 3 Jan 2018 20:09:49 +0300 Subject: sh_eth: fix TSU resource handling From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com> [ Upstream commit dfe8266b8dd10e12a731c985b725fcf7f0e537f0 ] When switching the driver to the managed device API, I managed to break the case of a dual Ether devices sharing a single TSU: the 2nd Ether port wouldn't probe. Iwamatsu-san has tried to fix this but his patch was buggy and he then dropped the ball... The solution is to limit calling devm_request_mem_region() to the first of the two ports sharing the same TSU, so devm_ioremap_resource() can't be used anymore for the TSU resource... Fixes: d5e07e69218f ("sh_eth: use managed device API") Reported-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj(a)renesas.com> Signed-off-by: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/renesas/sh_eth.c | 25 ++++++++++++++++++++++--- 1 file changed, 22 insertions(+), 3 deletions(-) --- a/drivers/net/ethernet/renesas/sh_eth.c +++ b/drivers/net/ethernet/renesas/sh_eth.c @@ -3212,10 +3212,29 @@ static int sh_eth_drv_probe(struct platf /* ioremap the TSU registers */ if (mdp->cd->tsu) { struct resource *rtsu; + rtsu = platform_get_resource(pdev, IORESOURCE_MEM, 1); - mdp->tsu_addr = devm_ioremap_resource(&pdev->dev, rtsu); - if (IS_ERR(mdp->tsu_addr)) { - ret = PTR_ERR(mdp->tsu_addr); + if (!rtsu) { + dev_err(&pdev->dev, "no TSU resource\n"); + ret = -ENODEV; + goto out_release; + } + /* We can only request the TSU region for the first port + * of the two sharing this TSU for the probe to succeed... + */ + if (devno % 2 == 0 && + !devm_request_mem_region(&pdev->dev, rtsu->start, + resource_size(rtsu), + dev_name(&pdev->dev))) { + dev_err(&pdev->dev, "can't request TSU resource.\n"); + ret = -EBUSY; + goto out_release; + } + mdp->tsu_addr = devm_ioremap(&pdev->dev, rtsu->start, + resource_size(rtsu)); + if (!mdp->tsu_addr) { + dev_err(&pdev->dev, "TSU region ioremap() failed.\n"); + ret = -ENOMEM; goto out_release; } mdp->port = devno % 2; Patches currently in stable-queue which might be from sergei.shtylyov(a)cogentembedded.com are queue-4.14/sh_eth-fix-sh7757-gether-initialization.patch queue-4.14/sh_eth-fix-tsu-resource-handling.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "sh_eth: fix SH7757 GEther initialization" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sh_eth: fix SH7757 GEther initialization to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: sh_eth-fix-sh7757-gether-initialization.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sat Jan 13 10:51:05 CET 2018 From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com> Date: Thu, 4 Jan 2018 21:06:49 +0300 Subject: sh_eth: fix SH7757 GEther initialization From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com> [ Upstream commit 5133550296d43236439494aa955bfb765a89f615 ] Renesas SH7757 has 2 Fast and 2 Gigabit Ether controllers, while the 'sh_eth' driver can only reset and initialize TSU of the first controller pair. Shimoda-san tried to solve that adding the 'needs_init' member to the 'struct sh_eth_plat_data', however the platform code still never sets this flag. I think that we can infer this information from the 'devno' variable (set to 'platform_device::id') and reset/init the Ether controller pair only for an even 'devno'; therefore 'sh_eth_plat_data::needs_init' can be removed... Fixes: 150647fb2c31 ("net: sh_eth: change the condition of initialization") Signed-off-by: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/renesas/sh_eth.c | 4 ++-- include/linux/sh_eth.h | 1 - 2 files changed, 2 insertions(+), 3 deletions(-) --- a/drivers/net/ethernet/renesas/sh_eth.c +++ b/drivers/net/ethernet/renesas/sh_eth.c @@ -3241,8 +3241,8 @@ static int sh_eth_drv_probe(struct platf ndev->features = NETIF_F_HW_VLAN_CTAG_FILTER; } - /* initialize first or needed device */ - if (!devno || pd->needs_init) { + /* Need to init only the first port of the two sharing a TSU */ + if (devno % 2 == 0) { if (mdp->cd->chip_reset) mdp->cd->chip_reset(ndev); --- a/include/linux/sh_eth.h +++ b/include/linux/sh_eth.h @@ -17,7 +17,6 @@ struct sh_eth_plat_data { unsigned char mac_addr[ETH_ALEN]; unsigned no_ether_link:1; unsigned ether_link_active_low:1; - unsigned needs_init:1; }; #endif Patches currently in stable-queue which might be from sergei.shtylyov(a)cogentembedded.com are queue-4.14/sh_eth-fix-sh7757-gether-initialization.patch queue-4.14/sh_eth-fix-tsu-resource-handling.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "sfp: fix sfp-bus oops when removing socket/upstream" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sfp: fix sfp-bus oops when removing socket/upstream to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: sfp-fix-sfp-bus-oops-when-removing-socket-upstream.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sat Jan 13 10:51:05 CET 2018 From: Russell King <rmk+kernel(a)armlinux.org.uk> Date: Tue, 26 Dec 2017 23:15:17 +0000 Subject: sfp: fix sfp-bus oops when removing socket/upstream From: Russell King <rmk+kernel(a)armlinux.org.uk> [ Upstream commit 0b2122e4934c7783d336397864e34ee53aad0965 ] When we remove a socket or upstream, and the other side isn't registered, we dereference a NULL pointer, causing a kernel oops. Fix this. Fixes: ce0aa27ff3f6 ("sfp: add sfp-bus to bridge between network devices and sfp cages") Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk> Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/phy/sfp-bus.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/drivers/net/phy/sfp-bus.c +++ b/drivers/net/phy/sfp-bus.c @@ -359,7 +359,8 @@ EXPORT_SYMBOL_GPL(sfp_register_upstream) void sfp_unregister_upstream(struct sfp_bus *bus) { rtnl_lock(); - sfp_unregister_bus(bus); + if (bus->sfp) + sfp_unregister_bus(bus); bus->upstream = NULL; bus->netdev = NULL; rtnl_unlock(); @@ -464,7 +465,8 @@ EXPORT_SYMBOL_GPL(sfp_register_socket); void sfp_unregister_socket(struct sfp_bus *bus) { rtnl_lock(); - sfp_unregister_bus(bus); + if (bus->netdev) + sfp_unregister_bus(bus); bus->sfp_dev = NULL; bus->sfp = NULL; bus->socket_ops = NULL; Patches currently in stable-queue which might be from rmk+kernel(a)armlinux.org.uk are queue-4.14/sfp-fix-sfp-bus-oops-when-removing-socket-upstream.patch queue-4.14/phylink-ensure-we-report-link-down-when-los-asserted.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "sctp: fix the handling of ICMP Frag Needed for too small MTUs" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sctp: fix the handling of ICMP Frag Needed for too small MTUs to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: sctp-fix-the-handling-of-icmp-frag-needed-for-too-small-mtus.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sat Jan 13 10:51:05 CET 2018 From: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com> Date: Fri, 5 Jan 2018 11:17:18 -0200 Subject: sctp: fix the handling of ICMP Frag Needed for too small MTUs From: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com> [ Upstream commit b6c5734db07079c9410147b32407f2366d584e6c ] syzbot reported a hang involving SCTP, on which it kept flooding dmesg with the message: [ 246.742374] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too low, using default minimum of 512 That happened because whenever SCTP hits an ICMP Frag Needed, it tries to adjust to the new MTU and triggers an immediate retransmission. But it didn't consider the fact that MTUs smaller than the SCTP minimum MTU allowed (512) would not cause the PMTU to change, and issued the retransmission anyway (thus leading to another ICMP Frag Needed, and so on). As IPv4 (ip_rt_min_pmtu=556) and IPv6 (IPV6_MIN_MTU=1280) minimum MTU are higher than that, sctp_transport_update_pmtu() is changed to re-fetch the PMTU that got set after our request, and with that, detect if there was an actual change or not. The fix, thus, skips the immediate retransmission if the received ICMP resulted in no change, in the hope that SCTP will select another path. Note: The value being used for the minimum MTU (512, SCTP_DEFAULT_MINSEGMENT) is not right and instead it should be (576, SCTP_MIN_PMTU), but such change belongs to another patch. Changes from v1: - do not disable PMTU discovery, in the light of commit 06ad391919b2 ("[SCTP] Don't disable PMTU discovery when mtu is small") and as suggested by Xin Long. - changed the way to break the rtx loop by detecting if the icmp resulted in a change or not Changes from v2: none See-also: https://lkml.org/lkml/2017/12/22/811 Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/net/sctp/structs.h | 2 +- net/sctp/input.c | 8 ++++++-- net/sctp/transport.c | 29 +++++++++++++++++++---------- 3 files changed, 26 insertions(+), 13 deletions(-) --- a/include/net/sctp/structs.h +++ b/include/net/sctp/structs.h @@ -955,7 +955,7 @@ void sctp_transport_burst_limited(struct void sctp_transport_burst_reset(struct sctp_transport *); unsigned long sctp_transport_timeout(struct sctp_transport *); void sctp_transport_reset(struct sctp_transport *t); -void sctp_transport_update_pmtu(struct sctp_transport *t, u32 pmtu); +bool sctp_transport_update_pmtu(struct sctp_transport *t, u32 pmtu); void sctp_transport_immediate_rtx(struct sctp_transport *); void sctp_transport_dst_release(struct sctp_transport *t); void sctp_transport_dst_confirm(struct sctp_transport *t); --- a/net/sctp/input.c +++ b/net/sctp/input.c @@ -406,8 +406,12 @@ void sctp_icmp_frag_needed(struct sock * */ return; - /* Update transports view of the MTU */ - sctp_transport_update_pmtu(t, pmtu); + /* Update transports view of the MTU. Return if no update was needed. + * If an update wasn't needed/possible, it also doesn't make sense to + * try to retransmit now. + */ + if (!sctp_transport_update_pmtu(t, pmtu)) + return; /* Update association pmtu. */ sctp_assoc_sync_pmtu(asoc); --- a/net/sctp/transport.c +++ b/net/sctp/transport.c @@ -251,28 +251,37 @@ void sctp_transport_pmtu(struct sctp_tra transport->pathmtu = SCTP_DEFAULT_MAXSEGMENT; } -void sctp_transport_update_pmtu(struct sctp_transport *t, u32 pmtu) +bool sctp_transport_update_pmtu(struct sctp_transport *t, u32 pmtu) { struct dst_entry *dst = sctp_transport_dst_check(t); + bool change = true; if (unlikely(pmtu < SCTP_DEFAULT_MINSEGMENT)) { - pr_warn("%s: Reported pmtu %d too low, using default minimum of %d\n", - __func__, pmtu, SCTP_DEFAULT_MINSEGMENT); - /* Use default minimum segment size and disable - * pmtu discovery on this transport. - */ - t->pathmtu = SCTP_DEFAULT_MINSEGMENT; - } else { - t->pathmtu = pmtu; + pr_warn_ratelimited("%s: Reported pmtu %d too low, using default minimum of %d\n", + __func__, pmtu, SCTP_DEFAULT_MINSEGMENT); + /* Use default minimum segment instead */ + pmtu = SCTP_DEFAULT_MINSEGMENT; } + pmtu = SCTP_TRUNC4(pmtu); if (dst) { dst->ops->update_pmtu(dst, t->asoc->base.sk, NULL, pmtu); dst = sctp_transport_dst_check(t); } - if (!dst) + if (!dst) { t->af_specific->get_dst(t, &t->saddr, &t->fl, t->asoc->base.sk); + dst = t->dst; + } + + if (dst) { + /* Re-fetch, as under layers may have a higher minimum size */ + pmtu = SCTP_TRUNC4(dst_mtu(dst)); + change = t->pathmtu != pmtu; + } + t->pathmtu = pmtu; + + return change; } /* Caches the dst entry and source address for a transport's destination Patches currently in stable-queue which might be from marcelo.leitner(a)gmail.com are queue-4.14/sctp-do-not-retransmit-upon-fragneeded-if-pmtu-discovery-is-disabled.patch queue-4.14/sctp-fix-the-handling-of-icmp-frag-needed-for-too-small-mtus.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "sctp: do not retransmit upon FragNeeded if PMTU discovery is disabled" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sctp: do not retransmit upon FragNeeded if PMTU discovery is disabled to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: sctp-do-not-retransmit-upon-fragneeded-if-pmtu-discovery-is-disabled.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sat Jan 13 10:51:05 CET 2018 From: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com> Date: Fri, 5 Jan 2018 11:17:17 -0200 Subject: sctp: do not retransmit upon FragNeeded if PMTU discovery is disabled From: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com> [ Upstream commit cc35c3d1edf7a8373a1a5daa80a912dec96a9cd5 ] Currently, if PMTU discovery is disabled on a given transport, but the configured value is higher than the actual PMTU, it is likely that we will get some icmp Frag Needed. The issue is, if PMTU discovery is disabled, we won't update the information and will issue a retransmission immediately, which may very well trigger another ICMP, and another retransmission, leading to a loop. The fix is to simply not trigger immediate retransmissions if PMTU discovery is disabled on the given transport. Changes from v2: - updated stale comment, noticed by Xin Long Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/sctp/input.c | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) --- a/net/sctp/input.c +++ b/net/sctp/input.c @@ -399,20 +399,20 @@ void sctp_icmp_frag_needed(struct sock * return; } - if (t->param_flags & SPP_PMTUD_ENABLE) { - /* Update transports view of the MTU */ - sctp_transport_update_pmtu(t, pmtu); + if (!(t->param_flags & SPP_PMTUD_ENABLE)) + /* We can't allow retransmitting in such case, as the + * retransmission would be sized just as before, and thus we + * would get another icmp, and retransmit again. + */ + return; - /* Update association pmtu. */ - sctp_assoc_sync_pmtu(asoc); - } + /* Update transports view of the MTU */ + sctp_transport_update_pmtu(t, pmtu); + + /* Update association pmtu. */ + sctp_assoc_sync_pmtu(asoc); - /* Retransmit with the new pmtu setting. - * Normally, if PMTU discovery is disabled, an ICMP Fragmentation - * Needed will never be sent, but if a message was sent before - * PMTU discovery was disabled that was larger than the PMTU, it - * would not be fragmented, so it must be re-transmitted fragmented. - */ + /* Retransmit with the new pmtu setting. */ sctp_retransmit(&asoc->outqueue, t, SCTP_RTXR_PMTUD); } Patches currently in stable-queue which might be from marcelo.leitner(a)gmail.com are queue-4.14/sctp-do-not-retransmit-upon-fragneeded-if-pmtu-discovery-is-disabled.patch queue-4.14/sctp-fix-the-handling-of-icmp-frag-needed-for-too-small-mtus.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "Revert "Revert "xfrm: Fix stack-out-of-bounds read in xfrm_state_find.""" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Revert "Revert "xfrm: Fix stack-out-of-bounds read in xfrm_state_find."" to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: revert-revert-xfrm-fix-stack-out-of-bounds-read-in-xfrm_state_find.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sat Jan 13 10:51:05 CET 2018 From: "David S. Miller" <davem(a)davemloft.net> Date: Fri, 12 Jan 2018 16:09:58 -0500 Subject: Revert "Revert "xfrm: Fix stack-out-of-bounds read in xfrm_state_find."" From: "David S. Miller" <davem(a)davemloft.net> This reverts commit 94802151894d482e82c324edf2c658f8e6b96508. It breaks transport mode when the policy template has wildcard addresses configured. Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/xfrm/xfrm_policy.c | 29 +++++++++++------------------ 1 file changed, 11 insertions(+), 18 deletions(-) --- a/net/xfrm/xfrm_policy.c +++ b/net/xfrm/xfrm_policy.c @@ -1362,36 +1362,29 @@ xfrm_tmpl_resolve_one(struct xfrm_policy struct net *net = xp_net(policy); int nx; int i, error; - xfrm_address_t *daddr = xfrm_flowi_daddr(fl, family); - xfrm_address_t *saddr = xfrm_flowi_saddr(fl, family); xfrm_address_t tmp; for (nx = 0, i = 0; i < policy->xfrm_nr; i++) { struct xfrm_state *x; - xfrm_address_t *remote = daddr; - xfrm_address_t *local = saddr; + xfrm_address_t *local; + xfrm_address_t *remote; struct xfrm_tmpl *tmpl = &policy->xfrm_vec[i]; - if (tmpl->mode == XFRM_MODE_TUNNEL || - tmpl->mode == XFRM_MODE_BEET) { - remote = &tmpl->id.daddr; - local = &tmpl->saddr; - if (xfrm_addr_any(local, tmpl->encap_family)) { - error = xfrm_get_saddr(net, fl->flowi_oif, - &tmp, remote, - tmpl->encap_family, 0); - if (error) - goto fail; - local = &tmp; - } + remote = &tmpl->id.daddr; + local = &tmpl->saddr; + if (xfrm_addr_any(local, tmpl->encap_family)) { + error = xfrm_get_saddr(net, fl->flowi_oif, + &tmp, remote, + tmpl->encap_family, 0); + if (error) + goto fail; + local = &tmp; } x = xfrm_state_find(remote, local, fl, tmpl, policy, &error, family); if (x && x->km.state == XFRM_STATE_VALID) { xfrm[nx++] = x; - daddr = remote; - saddr = local; continue; } if (x) { Patches currently in stable-queue which might be from davem(a)davemloft.net are queue-4.14/net-fec-defer-probe-if-regulator-is-not-ready.patch queue-4.14/sfp-fix-sfp-bus-oops-when-removing-socket-upstream.patch queue-4.14/8021q-fix-a-memory-leak-for-vlan-0-device.patch queue-4.14/net-fec-free-restore-resource-in-related-probe-error-pathes.patch queue-4.14/revert-revert-xfrm-fix-stack-out-of-bounds-read-in-xfrm_state_find.patch queue-4.14/ip6_tunnel-disable-dst-caching-if-tunnel-is-dual-stack.patch queue-4.14/rds-null-pointer-dereference-in-rds_atomic_free_op.patch queue-4.14/phylink-ensure-we-report-link-down-when-los-asserted.patch queue-4.14/ethtool-do-not-print-warning-for-applications-using-legacy-api.patch queue-4.14/sctp-do-not-retransmit-upon-fragneeded-if-pmtu-discovery-is-disabled.patch queue-4.14/rds-heap-oob-write-in-rds_message_alloc_sgs.patch queue-4.14/mlxsw-spectrum_router-fix-null-pointer-deref.patch queue-4.14/sctp-fix-the-handling-of-icmp-frag-needed-for-too-small-mtus.patch queue-4.14/sh_eth-fix-sh7757-gether-initialization.patch queue-4.14/net-stmmac-enable-eee-in-mii-gmii-or-rgmii-only.patch queue-4.14/net-core-fix-module-type-in-sock_diag_bind.patch queue-4.14/mlxsw-spectrum-relax-sanity-checks-during-enslavement.patch queue-4.14/net-fec-restore-dev_id-in-the-cases-of-probe-error.patch queue-4.14/sh_eth-fix-tsu-resource-handling.patch queue-4.14/ipv6-sr-fix-tlvs-not-being-copied-using-setsockopt.patch queue-4.14/net-sched-fix-update-of-lastuse-in-act-modules-implementing-stats_update.patch queue-4.14/ipv6-fix-possible-mem-leaks-in-ipv6_make_skb.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "RDS: null pointer dereference in rds_atomic_free_op" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled RDS: null pointer dereference in rds_atomic_free_op to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rds-null-pointer-dereference-in-rds_atomic_free_op.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sat Jan 13 10:51:05 CET 2018 From: Mohamed Ghannam <simo.ghannam(a)gmail.com> Date: Wed, 3 Jan 2018 21:06:06 +0000 Subject: RDS: null pointer dereference in rds_atomic_free_op From: Mohamed Ghannam <simo.ghannam(a)gmail.com> [ Upstream commit 7d11f77f84b27cef452cee332f4e469503084737 ] set rm->atomic.op_active to 0 when rds_pin_pages() fails or the user supplied address is invalid, this prevents a NULL pointer usage in rds_atomic_free_op() Signed-off-by: Mohamed Ghannam <simo.ghannam(a)gmail.com> Acked-by: Santosh Shilimkar <santosh.shilimkar(a)oracle.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/rds/rdma.c | 1 + 1 file changed, 1 insertion(+) --- a/net/rds/rdma.c +++ b/net/rds/rdma.c @@ -877,6 +877,7 @@ int rds_cmsg_atomic(struct rds_sock *rs, err: if (page) put_page(page); + rm->atomic.op_active = 0; kfree(rm->atomic.op_notifier); return ret; Patches currently in stable-queue which might be from simo.ghannam(a)gmail.com are queue-4.14/rds-null-pointer-dereference-in-rds_atomic_free_op.patch queue-4.14/rds-heap-oob-write-in-rds_message_alloc_sgs.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "RDS: Heap OOB write in rds_message_alloc_sgs()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled RDS: Heap OOB write in rds_message_alloc_sgs() to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rds-heap-oob-write-in-rds_message_alloc_sgs.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sat Jan 13 10:51:05 CET 2018 From: Mohamed Ghannam <simo.ghannam(a)gmail.com> Date: Tue, 2 Jan 2018 19:44:34 +0000 Subject: RDS: Heap OOB write in rds_message_alloc_sgs() From: Mohamed Ghannam <simo.ghannam(a)gmail.com> [ Upstream commit c095508770aebf1b9218e77026e48345d719b17c ] When args->nr_local is 0, nr_pages gets also 0 due some size calculation via rds_rm_size(), which is later used to allocate pages for DMA, this bug produces a heap Out-Of-Bound write access to a specific memory region. Signed-off-by: Mohamed Ghannam <simo.ghannam(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/rds/rdma.c | 3 +++ 1 file changed, 3 insertions(+) --- a/net/rds/rdma.c +++ b/net/rds/rdma.c @@ -525,6 +525,9 @@ int rds_rdma_extra_size(struct rds_rdma_ local_vec = (struct rds_iovec __user *)(unsigned long) args->local_vec_addr; + if (args->nr_local == 0) + return -EINVAL; + /* figure out the number of pages in the vector */ for (i = 0; i < args->nr_local; i++) { if (copy_from_user(&vec, &local_vec[i], Patches currently in stable-queue which might be from simo.ghannam(a)gmail.com are queue-4.14/rds-null-pointer-dereference-in-rds_atomic_free_op.patch queue-4.14/rds-heap-oob-write-in-rds_message_alloc_sgs.patch

7 years, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror