From: Sasha Levin Date: Sun, 26 Feb 2023 15:46:03 +0000 (-0500) Subject: Fixes for 5.10 X-Git-Tag: v4.19.275~36 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=94dfd8d8c8f1bb692dd6ce337c3f0b32c80c70ee;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 5.10 Signed-off-by: Sasha Levin --- diff --git a/queue-5.10/acpi-nfit-fix-a-potential-deadlock-during-nfit-teard.patch b/queue-5.10/acpi-nfit-fix-a-potential-deadlock-during-nfit-teard.patch new file mode 100644 index 00000000000..b920e328100 --- /dev/null +++ b/queue-5.10/acpi-nfit-fix-a-potential-deadlock-during-nfit-teard.patch @@ -0,0 +1,75 @@ +From 3183ac2d9e6be6def3e376957fc36bc6990f7d1d Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 25 Jan 2023 11:34:18 -0700 +Subject: ACPI: NFIT: fix a potential deadlock during NFIT teardown + +From: Vishal Verma + +[ Upstream commit fb6df4366f86dd252bfa3049edffa52d17e7b895 ] + +Lockdep reports that acpi_nfit_shutdown() may deadlock against an +opportune acpi_nfit_scrub(). acpi_nfit_scrub () is run from inside a +'work' and therefore has already acquired workqueue-internal locks. It +also acquiires acpi_desc->init_mutex. acpi_nfit_shutdown() first +acquires init_mutex, and was subsequently attempting to cancel any +pending workqueue items. This reversed locking order causes a potential +deadlock: + + ====================================================== + WARNING: possible circular locking dependency detected + 6.2.0-rc3 #116 Tainted: G O N + ------------------------------------------------------ + libndctl/1958 is trying to acquire lock: + ffff888129b461c0 ((work_completion)(&(&acpi_desc->dwork)->work)){+.+.}-{0:0}, at: __flush_work+0x43/0x450 + + but task is already holding lock: + ffff888129b460e8 (&acpi_desc->init_mutex){+.+.}-{3:3}, at: acpi_nfit_shutdown+0x87/0xd0 [nfit] + + which lock already depends on the new lock. + + ... + + Possible unsafe locking scenario: + + CPU0 CPU1 + ---- ---- + lock(&acpi_desc->init_mutex); + lock((work_completion)(&(&acpi_desc->dwork)->work)); + lock(&acpi_desc->init_mutex); + lock((work_completion)(&(&acpi_desc->dwork)->work)); + + *** DEADLOCK *** + +Since the workqueue manipulation is protected by its own internal locking, +the cancellation of pending work doesn't need to be done under +acpi_desc->init_mutex. Move cancel_delayed_work_sync() outside the +init_mutex to fix the deadlock. Any work that starts after +acpi_nfit_shutdown() drops the lock will see ARS_CANCEL, and the +cancel_delayed_work_sync() will safely flush it out. + +Reported-by: Dan Williams +Signed-off-by: Vishal Verma +Link: https://lore.kernel.org/r/20230112-acpi_nfit_lockdep-v1-1-660be4dd10be@intel.com +Signed-off-by: Dan Williams +Signed-off-by: Sasha Levin +--- + drivers/acpi/nfit/core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c +index 99e23a5df0267..2306abb09f7f5 100644 +--- a/drivers/acpi/nfit/core.c ++++ b/drivers/acpi/nfit/core.c +@@ -3687,8 +3687,8 @@ void acpi_nfit_shutdown(void *data) + + mutex_lock(&acpi_desc->init_mutex); + set_bit(ARS_CANCEL, &acpi_desc->scrub_flags); +- cancel_delayed_work_sync(&acpi_desc->dwork); + mutex_unlock(&acpi_desc->init_mutex); ++ cancel_delayed_work_sync(&acpi_desc->dwork); + + /* + * Bounce the nvdimm bus lock to make sure any in-flight +-- +2.39.0 + diff --git a/queue-5.10/arm-dts-rockchip-add-power-domains-property-to-dp-no.patch b/queue-5.10/arm-dts-rockchip-add-power-domains-property-to-dp-no.patch new file mode 100644 index 00000000000..867522cbf77 --- /dev/null +++ b/queue-5.10/arm-dts-rockchip-add-power-domains-property-to-dp-no.patch @@ -0,0 +1,36 @@ +From 3adfde0f464e4043881e0cfa169310074724e87e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 28 Dec 2022 21:17:32 +0100 +Subject: ARM: dts: rockchip: add power-domains property to dp node on rk3288 + +From: Johan Jonker + +[ Upstream commit 80422339a75088322b4d3884bd12fa0fe5d11050 ] + +The clocks in the Rockchip rk3288 DisplayPort node are +included in the power-domain@RK3288_PD_VIO logic, but the +power-domains property in the dp node is missing, so fix it. + +Signed-off-by: Johan Jonker +Link: https://lore.kernel.org/r/dab85bfb-9f55-86a1-5cd5-7388c43e0ec5@gmail.com +Signed-off-by: Heiko Stuebner +Signed-off-by: Sasha Levin +--- + arch/arm/boot/dts/rk3288.dtsi | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi +index 9051fb4a267d4..aab28161b9ae9 100644 +--- a/arch/arm/boot/dts/rk3288.dtsi ++++ b/arch/arm/boot/dts/rk3288.dtsi +@@ -1203,6 +1203,7 @@ edp: dp@ff970000 { + clock-names = "dp", "pclk"; + phys = <&edp_phy>; + phy-names = "dp"; ++ power-domains = <&power RK3288_PD_VIO>; + resets = <&cru SRST_EDP>; + reset-names = "dp"; + rockchip,grf = <&grf>; +-- +2.39.0 + diff --git a/queue-5.10/arm64-dts-rockchip-drop-unused-led-mode-property-fro.patch b/queue-5.10/arm64-dts-rockchip-drop-unused-led-mode-property-fro.patch new file mode 100644 index 00000000000..58841a08d5e --- /dev/null +++ b/queue-5.10/arm64-dts-rockchip-drop-unused-led-mode-property-fro.patch @@ -0,0 +1,45 @@ +From 26625557649115ecce3b9bcb6ab604ea38ae6da0 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 25 Nov 2022 15:41:34 +0100 +Subject: arm64: dts: rockchip: drop unused LED mode property from + rk3328-roc-cc + +From: Krzysztof Kozlowski + +[ Upstream commit 1692bffec674551163a7a4be32f59fdde04ecd27 ] + +GPIO LEDs do not have a 'mode' property: + + rockchip/rk3328-roc-pc.dtb: leds: led-0: Unevaluated properties are not allowed ('mode' was unexpected) + +Signed-off-by: Krzysztof Kozlowski +Link: https://lore.kernel.org/r/20221125144135.477144-1-krzysztof.kozlowski@linaro.org +Signed-off-by: Heiko Stuebner +Signed-off-by: Sasha Levin +--- + arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 2 -- + 1 file changed, 2 deletions(-) + +diff --git a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts +index daa9a0c601a9f..22ab5e1d7319d 100644 +--- a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts ++++ b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts +@@ -91,7 +91,6 @@ power_led: led-0 { + linux,default-trigger = "heartbeat"; + gpios = <&rk805 1 GPIO_ACTIVE_LOW>; + default-state = "on"; +- mode = <0x23>; + }; + + user_led: led-1 { +@@ -99,7 +98,6 @@ user_led: led-1 { + linux,default-trigger = "mmc1"; + gpios = <&rk805 0 GPIO_ACTIVE_LOW>; + default-state = "off"; +- mode = <0x05>; + }; + }; + }; +-- +2.39.0 + diff --git a/queue-5.10/btrfs-send-limit-number-of-clones-and-allocated-memo.patch b/queue-5.10/btrfs-send-limit-number-of-clones-and-allocated-memo.patch new file mode 100644 index 00000000000..b217a184dcc --- /dev/null +++ b/queue-5.10/btrfs-send-limit-number-of-clones-and-allocated-memo.patch @@ -0,0 +1,44 @@ +From 622019b261f1ae48d312161a2228e842705d301d Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 24 Jan 2023 20:32:10 +0100 +Subject: btrfs: send: limit number of clones and allocated memory size + +From: David Sterba + +[ Upstream commit 33e17b3f5ab74af12aca58c515bc8424ff69a343 ] + +The arg->clone_sources_count is u64 and can trigger a warning when a +huge value is passed from user space and a huge array is allocated. +Limit the allocated memory to 8MiB (can be increased if needed), which +in turn limits the number of clone sources to 8M / sizeof(struct +clone_root) = 8M / 40 = 209715. Real world number of clones is from +tens to hundreds, so this is future proof. + +Reported-by: syzbot+4376a9a073770c173269@syzkaller.appspotmail.com +Signed-off-by: David Sterba +Signed-off-by: Sasha Levin +--- + fs/btrfs/send.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c +index 4a6ba0997e399..b081b61e97c8d 100644 +--- a/fs/btrfs/send.c ++++ b/fs/btrfs/send.c +@@ -7276,10 +7276,10 @@ long btrfs_ioctl_send(struct file *mnt_file, struct btrfs_ioctl_send_args *arg) + /* + * Check that we don't overflow at later allocations, we request + * clone_sources_count + 1 items, and compare to unsigned long inside +- * access_ok. ++ * access_ok. Also set an upper limit for allocation size so this can't ++ * easily exhaust memory. Max number of clone sources is about 200K. + */ +- if (arg->clone_sources_count > +- ULONG_MAX / sizeof(struct clone_root) - 1) { ++ if (arg->clone_sources_count > SZ_8M / sizeof(struct clone_root)) { + ret = -EINVAL; + goto out; + } +-- +2.39.0 + diff --git a/queue-5.10/fix-xfrm-i-support-for-nested-esp-tunnels.patch b/queue-5.10/fix-xfrm-i-support-for-nested-esp-tunnels.patch new file mode 100644 index 00000000000..6b98e6fd027 --- /dev/null +++ b/queue-5.10/fix-xfrm-i-support-for-nested-esp-tunnels.patch @@ -0,0 +1,131 @@ +From a20674e98b1de19681bedfe8fb986049787440ec Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 5 Jan 2023 21:28:12 +0000 +Subject: Fix XFRM-I support for nested ESP tunnels + +From: Benedict Wong + +[ Upstream commit b0355dbbf13c0052931dd14c38c789efed64d3de ] + +This change adds support for nested IPsec tunnels by ensuring that +XFRM-I verifies existing policies before decapsulating a subsequent +policies. Addtionally, this clears the secpath entries after policies +are verified, ensuring that previous tunnels with no-longer-valid +do not pollute subsequent policy checks. + +This is necessary especially for nested tunnels, as the IP addresses, +protocol and ports may all change, thus not matching the previous +policies. In order to ensure that packets match the relevant inbound +templates, the xfrm_policy_check should be done before handing off to +the inner XFRM protocol to decrypt and decapsulate. + +Notably, raw ESP/AH packets did not perform policy checks inherently, +whereas all other encapsulated packets (UDP, TCP encapsulated) do policy +checks after calling xfrm_input handling in the respective encapsulation +layer. + +Test: Verified with additional Android Kernel Unit tests +Signed-off-by: Benedict Wong +Signed-off-by: Steffen Klassert +Signed-off-by: Sasha Levin +--- + net/xfrm/xfrm_interface.c | 54 ++++++++++++++++++++++++++++++++++++--- + net/xfrm/xfrm_policy.c | 3 +++ + 2 files changed, 53 insertions(+), 4 deletions(-) + +diff --git a/net/xfrm/xfrm_interface.c b/net/xfrm/xfrm_interface.c +index da518b4ca84c6..e4f21a6924153 100644 +--- a/net/xfrm/xfrm_interface.c ++++ b/net/xfrm/xfrm_interface.c +@@ -207,6 +207,52 @@ static void xfrmi_scrub_packet(struct sk_buff *skb, bool xnet) + skb->mark = 0; + } + ++static int xfrmi_input(struct sk_buff *skb, int nexthdr, __be32 spi, ++ int encap_type, unsigned short family) ++{ ++ struct sec_path *sp; ++ ++ sp = skb_sec_path(skb); ++ if (sp && (sp->len || sp->olen) && ++ !xfrm_policy_check(NULL, XFRM_POLICY_IN, skb, family)) ++ goto discard; ++ ++ XFRM_SPI_SKB_CB(skb)->family = family; ++ if (family == AF_INET) { ++ XFRM_SPI_SKB_CB(skb)->daddroff = offsetof(struct iphdr, daddr); ++ XFRM_TUNNEL_SKB_CB(skb)->tunnel.ip4 = NULL; ++ } else { ++ XFRM_SPI_SKB_CB(skb)->daddroff = offsetof(struct ipv6hdr, daddr); ++ XFRM_TUNNEL_SKB_CB(skb)->tunnel.ip6 = NULL; ++ } ++ ++ return xfrm_input(skb, nexthdr, spi, encap_type); ++discard: ++ kfree_skb(skb); ++ return 0; ++} ++ ++static int xfrmi4_rcv(struct sk_buff *skb) ++{ ++ return xfrmi_input(skb, ip_hdr(skb)->protocol, 0, 0, AF_INET); ++} ++ ++static int xfrmi6_rcv(struct sk_buff *skb) ++{ ++ return xfrmi_input(skb, skb_network_header(skb)[IP6CB(skb)->nhoff], ++ 0, 0, AF_INET6); ++} ++ ++static int xfrmi4_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type) ++{ ++ return xfrmi_input(skb, nexthdr, spi, encap_type, AF_INET); ++} ++ ++static int xfrmi6_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type) ++{ ++ return xfrmi_input(skb, nexthdr, spi, encap_type, AF_INET6); ++} ++ + static int xfrmi_rcv_cb(struct sk_buff *skb, int err) + { + const struct xfrm_mode *inner_mode; +@@ -780,8 +826,8 @@ static struct pernet_operations xfrmi_net_ops = { + }; + + static struct xfrm6_protocol xfrmi_esp6_protocol __read_mostly = { +- .handler = xfrm6_rcv, +- .input_handler = xfrm_input, ++ .handler = xfrmi6_rcv, ++ .input_handler = xfrmi6_input, + .cb_handler = xfrmi_rcv_cb, + .err_handler = xfrmi6_err, + .priority = 10, +@@ -831,8 +877,8 @@ static struct xfrm6_tunnel xfrmi_ip6ip_handler __read_mostly = { + #endif + + static struct xfrm4_protocol xfrmi_esp4_protocol __read_mostly = { +- .handler = xfrm4_rcv, +- .input_handler = xfrm_input, ++ .handler = xfrmi4_rcv, ++ .input_handler = xfrmi4_input, + .cb_handler = xfrmi_rcv_cb, + .err_handler = xfrmi4_err, + .priority = 10, +diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c +index 0d12bdf59d4cc..d15aa62887de0 100644 +--- a/net/xfrm/xfrm_policy.c ++++ b/net/xfrm/xfrm_policy.c +@@ -3710,6 +3710,9 @@ int __xfrm_policy_check(struct sock *sk, int dir, struct sk_buff *skb, + goto reject; + } + ++ if (if_id) ++ secpath_reset(skb); ++ + xfrm_pols_put(pols, npols); + return 1; + } +-- +2.39.0 + diff --git a/queue-5.10/hid-core-fix-deadloop-in-hid_apply_multiplier.patch b/queue-5.10/hid-core-fix-deadloop-in-hid_apply_multiplier.patch new file mode 100644 index 00000000000..ae7f829468e --- /dev/null +++ b/queue-5.10/hid-core-fix-deadloop-in-hid_apply_multiplier.patch @@ -0,0 +1,63 @@ +From 5a083de227679a8ab69234e09b888804e012d916 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 30 Jan 2023 21:29:47 +0000 +Subject: HID: core: Fix deadloop in hid_apply_multiplier. + +From: Xin Zhao + +[ Upstream commit ea427a222d8bdf2bc1a8a6da3ebe247f7dced70c ] + +The initial value of hid->collection[].parent_idx if 0. When +Report descriptor doesn't contain "HID Collection", the value +remains as 0. + +In the meanwhile, when the Report descriptor fullfill +all following conditions, it will trigger hid_apply_multiplier +function call. +1. Usage page is Generic Desktop Ctrls (0x01) +2. Usage is RESOLUTION_MULTIPLIER (0x48) +3. Contain any FEATURE items + +The while loop in hid_apply_multiplier will search the top-most +collection by searching parent_idx == -1. Because all parent_idx +is 0. The loop will run forever. + +There is a Report Descriptor triggerring the deadloop +0x05, 0x01, // Usage Page (Generic Desktop Ctrls) +0x09, 0x48, // Usage (0x48) +0x95, 0x01, // Report Count (1) +0x75, 0x08, // Report Size (8) +0xB1, 0x01, // Feature + +Signed-off-by: Xin Zhao +Link: https://lore.kernel.org/r/20230130212947.1315941-1-xnzhao@google.com +Signed-off-by: Benjamin Tissoires +Signed-off-by: Sasha Levin +--- + drivers/hid/hid-core.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c +index baadead947c8b..5f9ec1d1464a2 100644 +--- a/drivers/hid/hid-core.c ++++ b/drivers/hid/hid-core.c +@@ -1197,6 +1197,7 @@ int hid_open_report(struct hid_device *device) + __u8 *end; + __u8 *next; + int ret; ++ int i; + static int (*dispatch_type[])(struct hid_parser *parser, + struct hid_item *item) = { + hid_parser_main, +@@ -1247,6 +1248,8 @@ int hid_open_report(struct hid_device *device) + goto err; + } + device->collection_size = HID_DEFAULT_NUM_COLLECTIONS; ++ for (i = 0; i < HID_DEFAULT_NUM_COLLECTIONS; i++) ++ device->collection[i].parent_idx = -1; + + ret = -EINVAL; + while ((next = fetch_item(start, end, &item)) != NULL) { +-- +2.39.0 + diff --git a/queue-5.10/ib-hfi1-assign-npages-earlier.patch b/queue-5.10/ib-hfi1-assign-npages-earlier.patch new file mode 100644 index 00000000000..5d0fea849fc --- /dev/null +++ b/queue-5.10/ib-hfi1-assign-npages-earlier.patch @@ -0,0 +1,64 @@ +From 07b2a1a49654d6781e6006ba67b5b0f12b2a683f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 9 Jan 2023 14:04:08 -0500 +Subject: IB/hfi1: Assign npages earlier + +From: Dean Luick + +[ Upstream commit f9c47b2caa7ffc903ec950b454b59c209afe3182 ] + +Improve code clarity and enable earlier use of +tidbuf->npages by moving its assignment to +structure creation time. + +Signed-off-by: Dean Luick +Signed-off-by: Dennis Dalessandro +Link: https://lore.kernel.org/r/167329104884.1472990.4639750192433251493.stgit@awfm-02.cornelisnetworks.com +Signed-off-by: Leon Romanovsky +Signed-off-by: Jason Gunthorpe +Signed-off-by: Sasha Levin +--- + drivers/infiniband/hw/hfi1/user_exp_rcv.c | 9 ++------- + 1 file changed, 2 insertions(+), 7 deletions(-) + +diff --git a/drivers/infiniband/hw/hfi1/user_exp_rcv.c b/drivers/infiniband/hw/hfi1/user_exp_rcv.c +index 897923981855d..0e0be6c62e3d1 100644 +--- a/drivers/infiniband/hw/hfi1/user_exp_rcv.c ++++ b/drivers/infiniband/hw/hfi1/user_exp_rcv.c +@@ -202,16 +202,11 @@ static void unpin_rcv_pages(struct hfi1_filedata *fd, + static int pin_rcv_pages(struct hfi1_filedata *fd, struct tid_user_buf *tidbuf) + { + int pinned; +- unsigned int npages; ++ unsigned int npages = tidbuf->npages; + unsigned long vaddr = tidbuf->vaddr; + struct page **pages = NULL; + struct hfi1_devdata *dd = fd->uctxt->dd; + +- /* Get the number of pages the user buffer spans */ +- npages = num_user_pages(vaddr, tidbuf->length); +- if (!npages) +- return -EINVAL; +- + if (npages > fd->uctxt->expected_count) { + dd_dev_err(dd, "Expected buffer too big\n"); + return -EINVAL; +@@ -238,7 +233,6 @@ static int pin_rcv_pages(struct hfi1_filedata *fd, struct tid_user_buf *tidbuf) + return pinned; + } + tidbuf->pages = pages; +- tidbuf->npages = npages; + fd->tid_n_pinned += pinned; + return pinned; + } +@@ -316,6 +310,7 @@ int hfi1_user_exp_rcv_setup(struct hfi1_filedata *fd, + mutex_init(&tidbuf->cover_mutex); + tidbuf->vaddr = tinfo->vaddr; + tidbuf->length = tinfo->length; ++ tidbuf->npages = num_user_pages(tidbuf->vaddr, tidbuf->length); + tidbuf->psets = kcalloc(uctxt->expected_count, sizeof(*tidbuf->psets), + GFP_KERNEL); + if (!tidbuf->psets) { +-- +2.39.0 + diff --git a/queue-5.10/neigh-make-sure-used-and-confirmed-times-are-valid.patch b/queue-5.10/neigh-make-sure-used-and-confirmed-times-are-valid.patch new file mode 100644 index 00000000000..50761d02d46 --- /dev/null +++ b/queue-5.10/neigh-make-sure-used-and-confirmed-times-are-valid.patch @@ -0,0 +1,96 @@ +From 4a6c5688e44b4264f527c74268465c2d9eacb55d Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 2 Feb 2023 17:25:51 +0200 +Subject: neigh: make sure used and confirmed times are valid + +From: Julian Anastasov + +[ Upstream commit c1d2ecdf5e38e3489ce8328238b558b3b2866fe1 ] + +Entries can linger in cache without timer for days, thanks to +the gc_thresh1 limit. As result, without traffic, the confirmed +time can be outdated and to appear to be in the future. Later, +on traffic, NUD_STALE entries can switch to NUD_DELAY and start +the timer which can see the invalid confirmed time and wrongly +switch to NUD_REACHABLE state instead of NUD_PROBE. As result, +timer is set many days in the future. This is more visible on +32-bit platforms, with higher HZ value. + +Why this is a problem? While we expect unused entries to expire, +such entries stay in REACHABLE state for too long, locked in +cache. They are not expired normally, only when cache is full. + +Problem and the wrong state change reported by Zhang Changzhong: + +172.16.1.18 dev bond0 lladdr 0a:0e:0f:01:12:01 ref 1 used 350521/15994171/350520 probes 4 REACHABLE + +350520 seconds have elapsed since this entry was last updated, but it is +still in the REACHABLE state (base_reachable_time_ms is 30000), +preventing lladdr from being updated through probe. + +Fix it by ensuring timer is started with valid used/confirmed +times. Considering the valid time range is LONG_MAX jiffies, +we try not to go too much in the past while we are in +DELAY/PROBE state. There are also places that need +used/updated times to be validated while timer is not running. + +Reported-by: Zhang Changzhong +Signed-off-by: Julian Anastasov +Tested-by: Zhang Changzhong +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + net/core/neighbour.c | 18 +++++++++++++++--- + 1 file changed, 15 insertions(+), 3 deletions(-) + +diff --git a/net/core/neighbour.c b/net/core/neighbour.c +index f6f580e9d2820..82ccc3eebe71d 100644 +--- a/net/core/neighbour.c ++++ b/net/core/neighbour.c +@@ -242,7 +242,7 @@ static int neigh_forced_gc(struct neigh_table *tbl) + (n->nud_state == NUD_NOARP) || + (tbl->is_multicast && + tbl->is_multicast(n->primary_key)) || +- time_after(tref, n->updated)) ++ !time_in_range(n->updated, tref, jiffies)) + remove = true; + write_unlock(&n->lock); + +@@ -262,7 +262,17 @@ static int neigh_forced_gc(struct neigh_table *tbl) + + static void neigh_add_timer(struct neighbour *n, unsigned long when) + { ++ /* Use safe distance from the jiffies - LONG_MAX point while timer ++ * is running in DELAY/PROBE state but still show to user space ++ * large times in the past. ++ */ ++ unsigned long mint = jiffies - (LONG_MAX - 86400 * HZ); ++ + neigh_hold(n); ++ if (!time_in_range(n->confirmed, mint, jiffies)) ++ n->confirmed = mint; ++ if (time_before(n->used, n->confirmed)) ++ n->used = n->confirmed; + if (unlikely(mod_timer(&n->timer, when))) { + printk("NEIGH: BUG, double timer add, state is %x\n", + n->nud_state); +@@ -948,12 +958,14 @@ static void neigh_periodic_work(struct work_struct *work) + goto next_elt; + } + +- if (time_before(n->used, n->confirmed)) ++ if (time_before(n->used, n->confirmed) && ++ time_is_before_eq_jiffies(n->confirmed)) + n->used = n->confirmed; + + if (refcount_read(&n->refcnt) == 1 && + (state == NUD_FAILED || +- time_after(jiffies, n->used + NEIGH_VAR(n->parms, GC_STALETIME)))) { ++ !time_in_range_open(jiffies, n->used, ++ n->used + NEIGH_VAR(n->parms, GC_STALETIME)))) { + *np = n->next; + neigh_mark_dead(n); + write_unlock(&n->lock); +-- +2.39.0 + diff --git a/queue-5.10/series b/queue-5.10/series new file mode 100644 index 00000000000..5afbbdb9f2b --- /dev/null +++ b/queue-5.10/series @@ -0,0 +1,8 @@ +fix-xfrm-i-support-for-nested-esp-tunnels.patch +arm64-dts-rockchip-drop-unused-led-mode-property-fro.patch +arm-dts-rockchip-add-power-domains-property-to-dp-no.patch +acpi-nfit-fix-a-potential-deadlock-during-nfit-teard.patch +btrfs-send-limit-number-of-clones-and-allocated-memo.patch +ib-hfi1-assign-npages-earlier.patch +neigh-make-sure-used-and-confirmed-times-are-valid.patch +hid-core-fix-deadloop-in-hid_apply_multiplier.patch