From d179224108c27bc2eba0deb48cb42a16d86adf90 Mon Sep 17 00:00:00 2001 From: Sasha Levin Date: Sun, 11 Aug 2024 08:55:11 -0400 Subject: [PATCH] Fixes for 4.19 Signed-off-by: Sasha Levin --- ...always-unlock-channel-in-l2cap_conle.patch | 37 +++++ ...-leak-when-loading-free-space-cache-.patch | 39 +++++ ...ers-sh_cmt-address-race-condition-fo.patch | 144 ++++++++++++++++++ ...bigen-fix-mbigen-node-address-layout.patch | 89 +++++++++++ ...ak-in-jbd2_journal_write_metadata_bu.patch | 37 +++++ ...ug_on-while-continue-reshape-after-r.patch | 93 +++++++++++ ...o-fix-the-bandwdith-quirk-on-usb-3.x.patch | 52 +++++++ ...dia-uvcvideo-ignore-empty-ts-packets.patch | 129 ++++++++++++++++ .../net-fec-stop-pps-on-driver-remove.patch | 46 ++++++ .../net-linkwatch-use-system_unbound_wq.patch | 52 +++++++ ...n-fix-memory-leak-for-not-ip-packets.patch | 38 +++++ ...ci-add-edimax-vendor-id-to-pci_ids.h.patch | 38 +++++ ...clp-prevent-release-of-buffer-in-i-o.patch | 52 +++++++ queue-4.19/series | 17 +++ ...unrpc-fix-a-race-to-wake-a-sync-task.patch | 53 +++++++ ...ger-overflow-in-udf_bitmap_free_bloc.patch | 113 ++++++++++++++ ...211-don-t-give-key-data-to-userspace.patch | 55 +++++++ ...i_clone_pgtable-alignment-assumption.patch | 68 +++++++++ 18 files changed, 1152 insertions(+) create mode 100644 queue-4.19/bluetooth-l2cap-always-unlock-channel-in-l2cap_conle.patch create mode 100644 queue-4.19/btrfs-fix-bitmap-leak-when-loading-free-space-cache-.patch create mode 100644 queue-4.19/clocksource-drivers-sh_cmt-address-race-condition-fo.patch create mode 100644 queue-4.19/irqchip-mbigen-fix-mbigen-node-address-layout.patch create mode 100644 queue-4.19/jbd2-avoid-memleak-in-jbd2_journal_write_metadata_bu.patch create mode 100644 queue-4.19/md-raid5-avoid-bug_on-while-continue-reshape-after-r.patch create mode 100644 queue-4.19/media-uvcvideo-fix-the-bandwdith-quirk-on-usb-3.x.patch create mode 100644 queue-4.19/media-uvcvideo-ignore-empty-ts-packets.patch create mode 100644 queue-4.19/net-fec-stop-pps-on-driver-remove.patch create mode 100644 queue-4.19/net-linkwatch-use-system_unbound_wq.patch create mode 100644 queue-4.19/net-usb-qmi_wwan-fix-memory-leak-for-not-ip-packets.patch create mode 100644 queue-4.19/pci-add-edimax-vendor-id-to-pci_ids.h.patch create mode 100644 queue-4.19/s390-sclp-prevent-release-of-buffer-in-i-o.patch create mode 100644 queue-4.19/sunrpc-fix-a-race-to-wake-a-sync-task.patch create mode 100644 queue-4.19/udf-prevent-integer-overflow-in-udf_bitmap_free_bloc.patch create mode 100644 queue-4.19/wifi-nl80211-don-t-give-key-data-to-userspace.patch create mode 100644 queue-4.19/x86-mm-fix-pti_clone_pgtable-alignment-assumption.patch diff --git a/queue-4.19/bluetooth-l2cap-always-unlock-channel-in-l2cap_conle.patch b/queue-4.19/bluetooth-l2cap-always-unlock-channel-in-l2cap_conle.patch new file mode 100644 index 00000000000..78c305f0468 --- /dev/null +++ b/queue-4.19/bluetooth-l2cap-always-unlock-channel-in-l2cap_conle.patch @@ -0,0 +1,37 @@ +From f24f5e0500f606fae43f15d63a17e8d58f381b18 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 31 Jul 2024 12:19:36 +0300 +Subject: Bluetooth: l2cap: always unlock channel in l2cap_conless_channel() + +From: Dmitry Antipov + +[ Upstream commit c531e63871c0b50c8c4e62c048535a08886fba3e ] + +Add missing call to 'l2cap_chan_unlock()' on receive error handling +path in 'l2cap_conless_channel()'. + +Fixes: a24cce144b98 ("Bluetooth: Fix reference counting of global L2CAP channels") +Reported-by: syzbot+45ac74737e866894acb0@syzkaller.appspotmail.com +Closes: https://syzkaller.appspot.com/bug?extid=45ac74737e866894acb0 +Signed-off-by: Dmitry Antipov +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Sasha Levin +--- + net/bluetooth/l2cap_core.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c +index 3f9b2b4a62ffd..ca225c1325237 100644 +--- a/net/bluetooth/l2cap_core.c ++++ b/net/bluetooth/l2cap_core.c +@@ -7055,6 +7055,7 @@ static void l2cap_conless_channel(struct l2cap_conn *conn, __le16 psm, + bt_cb(skb)->l2cap.psm = psm; + + if (!chan->ops->recv(chan, skb)) { ++ l2cap_chan_unlock(chan); + l2cap_chan_put(chan); + return; + } +-- +2.43.0 + diff --git a/queue-4.19/btrfs-fix-bitmap-leak-when-loading-free-space-cache-.patch b/queue-4.19/btrfs-fix-bitmap-leak-when-loading-free-space-cache-.patch new file mode 100644 index 00000000000..c40b2ea2080 --- /dev/null +++ b/queue-4.19/btrfs-fix-bitmap-leak-when-loading-free-space-cache-.patch @@ -0,0 +1,39 @@ +From 891851e3576fda04b709331552cd566f77dbc38f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 3 Jul 2024 15:40:59 +0100 +Subject: btrfs: fix bitmap leak when loading free space cache on duplicate + entry + +From: Filipe Manana + +[ Upstream commit 320d8dc612660da84c3b70a28658bb38069e5a9a ] + +If we failed to link a free space entry because there's already a +conflicting entry for the same offset, we free the free space entry but +we don't free the associated bitmap that we had just allocated before. +Fix that by freeing the bitmap before freeing the entry. + +Reviewed-by: Johannes Thumshirn +Signed-off-by: Filipe Manana +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Sasha Levin +--- + fs/btrfs/free-space-cache.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c +index b623e9f3b4c49..88f5775792597 100644 +--- a/fs/btrfs/free-space-cache.c ++++ b/fs/btrfs/free-space-cache.c +@@ -787,6 +787,7 @@ static int __load_free_space_cache(struct btrfs_root *root, struct inode *inode, + spin_unlock(&ctl->tree_lock); + btrfs_err(fs_info, + "Duplicate entries in free space cache, dumping"); ++ kmem_cache_free(btrfs_free_space_bitmap_cachep, e->bitmap); + kmem_cache_free(btrfs_free_space_cachep, e); + goto free_cache; + } +-- +2.43.0 + diff --git a/queue-4.19/clocksource-drivers-sh_cmt-address-race-condition-fo.patch b/queue-4.19/clocksource-drivers-sh_cmt-address-race-condition-fo.patch new file mode 100644 index 00000000000..229c94e9318 --- /dev/null +++ b/queue-4.19/clocksource-drivers-sh_cmt-address-race-condition-fo.patch @@ -0,0 +1,144 @@ +From 64a03d90a66e880ec4e12ab31954c4cc2946d46d Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 2 Jul 2024 21:02:30 +0200 +Subject: clocksource/drivers/sh_cmt: Address race condition for clock events +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Niklas Söderlund + +[ Upstream commit db19d3aa77612983a02bd223b3f273f896b243cf ] + +There is a race condition in the CMT interrupt handler. In the interrupt +handler the driver sets a driver private flag, FLAG_IRQCONTEXT. This +flag is used to indicate any call to set_next_event() should not be +directly propagated to the device, but instead cached. This is done as +the interrupt handler itself reprograms the device when needed before it +completes and this avoids this operation to take place twice. + +It is unclear why this design was chosen, my suspicion is to allow the +struct clock_event_device.event_handler callback, which is called while +the FLAG_IRQCONTEXT is set, can update the next event without having to +write to the device twice. + +Unfortunately there is a race between when the FLAG_IRQCONTEXT flag is +set and later cleared where the interrupt handler have already started to +write the next event to the device. If set_next_event() is called in +this window the value is only cached in the driver but not written. This +leads to the board to misbehave, or worse lockup and produce a splat. + + rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: + rcu: 0-...!: (0 ticks this GP) idle=f5e0/0/0x0 softirq=519/519 fqs=0 (false positive?) + rcu: (detected by 1, t=6502 jiffies, g=-595, q=77 ncpus=2) + Sending NMI from CPU 1 to CPUs 0: + NMI backtrace for cpu 0 + CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.10.0-rc5-arm64-renesas-00019-g74a6f86eaf1c-dirty #20 + Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT) + pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) + pc : tick_check_broadcast_expired+0xc/0x40 + lr : cpu_idle_poll.isra.0+0x8c/0x168 + sp : ffff800081c63d70 + x29: ffff800081c63d70 x28: 00000000580000c8 x27: 00000000bfee5610 + x26: 0000000000000027 x25: 0000000000000000 x24: 0000000000000000 + x23: ffff00007fbb9100 x22: ffff8000818f1008 x21: ffff8000800ef07c + x20: ffff800081c79ec0 x19: ffff800081c70c28 x18: 0000000000000000 + x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffc2c717d8 + x14: 0000000000000000 x13: ffff000009c18080 x12: ffff8000825f7fc0 + x11: 0000000000000000 x10: ffff8000818f3cd4 x9 : 0000000000000028 + x8 : ffff800081c79ec0 x7 : ffff800081c73000 x6 : 0000000000000000 + x5 : 0000000000000000 x4 : ffff7ffffe286000 x3 : 0000000000000000 + x2 : ffff7ffffe286000 x1 : ffff800082972900 x0 : ffff8000818f1008 + Call trace: + tick_check_broadcast_expired+0xc/0x40 + do_idle+0x9c/0x280 + cpu_startup_entry+0x34/0x40 + kernel_init+0x0/0x11c + do_one_initcall+0x0/0x260 + __primary_switched+0x80/0x88 + rcu: rcu_preempt kthread timer wakeup didn't happen for 6501 jiffies! g-595 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 + rcu: Possible timer handling issue on cpu=0 timer-softirq=262 + rcu: rcu_preempt kthread starved for 6502 jiffies! g-595 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0 + rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. + rcu: RCU grace-period kthread stack dump: + task:rcu_preempt state:I stack:0 pid:15 tgid:15 ppid:2 flags:0x00000008 + Call trace: + __switch_to+0xbc/0x100 + __schedule+0x358/0xbe0 + schedule+0x48/0x148 + schedule_timeout+0xc4/0x138 + rcu_gp_fqs_loop+0x12c/0x764 + rcu_gp_kthread+0x208/0x298 + kthread+0x10c/0x110 + ret_from_fork+0x10/0x20 + +The design have been part of the driver since it was first merged in +early 2009. It becomes increasingly harder to trigger the issue the +older kernel version one tries. It only takes a few boots on v6.10-rc5, +while hundreds of boots are needed to trigger it on v5.10. + +Close the race condition by using the CMT channel lock for the two +competing sections. The channel lock was added to the driver after its +initial design. + +Signed-off-by: Niklas Söderlund +Link: https://lore.kernel.org/r/20240702190230.3825292-1-niklas.soderlund+renesas@ragnatech.se +Signed-off-by: Daniel Lezcano +Signed-off-by: Sasha Levin +--- + drivers/clocksource/sh_cmt.c | 13 ++++++++++++- + 1 file changed, 12 insertions(+), 1 deletion(-) + +diff --git a/drivers/clocksource/sh_cmt.c b/drivers/clocksource/sh_cmt.c +index 0ca8819acc4d4..278b27298ca41 100644 +--- a/drivers/clocksource/sh_cmt.c ++++ b/drivers/clocksource/sh_cmt.c +@@ -518,6 +518,7 @@ static void sh_cmt_set_next(struct sh_cmt_channel *ch, unsigned long delta) + static irqreturn_t sh_cmt_interrupt(int irq, void *dev_id) + { + struct sh_cmt_channel *ch = dev_id; ++ unsigned long flags; + + /* clear flags */ + sh_cmt_write_cmcsr(ch, sh_cmt_read_cmcsr(ch) & +@@ -548,6 +549,8 @@ static irqreturn_t sh_cmt_interrupt(int irq, void *dev_id) + + ch->flags &= ~FLAG_SKIPEVENT; + ++ raw_spin_lock_irqsave(&ch->lock, flags); ++ + if (ch->flags & FLAG_REPROGRAM) { + ch->flags &= ~FLAG_REPROGRAM; + sh_cmt_clock_event_program_verify(ch, 1); +@@ -560,6 +563,8 @@ static irqreturn_t sh_cmt_interrupt(int irq, void *dev_id) + + ch->flags &= ~FLAG_IRQCONTEXT; + ++ raw_spin_unlock_irqrestore(&ch->lock, flags); ++ + return IRQ_HANDLED; + } + +@@ -758,12 +763,18 @@ static int sh_cmt_clock_event_next(unsigned long delta, + struct clock_event_device *ced) + { + struct sh_cmt_channel *ch = ced_to_sh_cmt(ced); ++ unsigned long flags; + + BUG_ON(!clockevent_state_oneshot(ced)); ++ ++ raw_spin_lock_irqsave(&ch->lock, flags); ++ + if (likely(ch->flags & FLAG_IRQCONTEXT)) + ch->next_match_value = delta - 1; + else +- sh_cmt_set_next(ch, delta - 1); ++ __sh_cmt_set_next(ch, delta - 1); ++ ++ raw_spin_unlock_irqrestore(&ch->lock, flags); + + return 0; + } +-- +2.43.0 + diff --git a/queue-4.19/irqchip-mbigen-fix-mbigen-node-address-layout.patch b/queue-4.19/irqchip-mbigen-fix-mbigen-node-address-layout.patch new file mode 100644 index 00000000000..4324fcbf578 --- /dev/null +++ b/queue-4.19/irqchip-mbigen-fix-mbigen-node-address-layout.patch @@ -0,0 +1,89 @@ +From bd917455f436b19453677919b9dcdbf3026c78ca Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 30 Jul 2024 09:44:00 +0800 +Subject: irqchip/mbigen: Fix mbigen node address layout + +From: Yipeng Zou + +[ Upstream commit 6be6cba9c4371d27f78d900ccfe34bb880d9ee20 ] + +The mbigen interrupt chip has its per node registers located in a +contiguous region of page sized chunks. The code maps them into virtual +address space as a contiguous region and determines the address of a node +by using the node ID as index. + + mbigen chip + |-----------------|------------|--------------| + mgn_node_0 mgn_node_1 ... mgn_node_i +|--------------| |--------------| |----------------------| +[0x0000, 0x0x0FFF] [0x1000, 0x1FFF] [i*0x1000, (i+1)*0x1000 - 1] + +This works correctly up to 10 nodes, but then fails because the 11th's +array slot is used for the MGN_CLEAR registers. + + mbigen chip + |-----------|--------|--------|---------------|--------| +mgn_node_0 mgn_node_1 ... mgn_clear_register ... mgn_node_i + |-----------------| + [0xA000, 0xAFFF] + +Skip the MGN_CLEAR register space when calculating the offset for node IDs +greater than or equal to ten. + +Fixes: a6c2f87b8820 ("irqchip/mbigen: Implement the mbigen irq chip operation functions") +Signed-off-by: Yipeng Zou +Signed-off-by: Thomas Gleixner +Link: https://lore.kernel.org/all/20240730014400.1751530-1-zouyipeng@huawei.com +Signed-off-by: Sasha Levin +--- + drivers/irqchip/irq-mbigen.c | 20 ++++++++++++++++---- + 1 file changed, 16 insertions(+), 4 deletions(-) + +diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c +index c98358be0bc8b..19cf1239c7d3b 100644 +--- a/drivers/irqchip/irq-mbigen.c ++++ b/drivers/irqchip/irq-mbigen.c +@@ -75,6 +75,20 @@ struct mbigen_device { + void __iomem *base; + }; + ++static inline unsigned int get_mbigen_node_offset(unsigned int nid) ++{ ++ unsigned int offset = nid * MBIGEN_NODE_OFFSET; ++ ++ /* ++ * To avoid touched clear register in unexpected way, we need to directly ++ * skip clear register when access to more than 10 mbigen nodes. ++ */ ++ if (nid >= (REG_MBIGEN_CLEAR_OFFSET / MBIGEN_NODE_OFFSET)) ++ offset += MBIGEN_NODE_OFFSET; ++ ++ return offset; ++} ++ + static inline unsigned int get_mbigen_vec_reg(irq_hw_number_t hwirq) + { + unsigned int nid, pin; +@@ -83,8 +97,7 @@ static inline unsigned int get_mbigen_vec_reg(irq_hw_number_t hwirq) + nid = hwirq / IRQS_PER_MBIGEN_NODE + 1; + pin = hwirq % IRQS_PER_MBIGEN_NODE; + +- return pin * 4 + nid * MBIGEN_NODE_OFFSET +- + REG_MBIGEN_VEC_OFFSET; ++ return pin * 4 + get_mbigen_node_offset(nid) + REG_MBIGEN_VEC_OFFSET; + } + + static inline void get_mbigen_type_reg(irq_hw_number_t hwirq, +@@ -99,8 +112,7 @@ static inline void get_mbigen_type_reg(irq_hw_number_t hwirq, + *mask = 1 << (irq_ofst % 32); + ofst = irq_ofst / 32 * 4; + +- *addr = ofst + nid * MBIGEN_NODE_OFFSET +- + REG_MBIGEN_TYPE_OFFSET; ++ *addr = ofst + get_mbigen_node_offset(nid) + REG_MBIGEN_TYPE_OFFSET; + } + + static inline void get_mbigen_clear_reg(irq_hw_number_t hwirq, +-- +2.43.0 + diff --git a/queue-4.19/jbd2-avoid-memleak-in-jbd2_journal_write_metadata_bu.patch b/queue-4.19/jbd2-avoid-memleak-in-jbd2_journal_write_metadata_bu.patch new file mode 100644 index 00000000000..b4f54995f1f --- /dev/null +++ b/queue-4.19/jbd2-avoid-memleak-in-jbd2_journal_write_metadata_bu.patch @@ -0,0 +1,37 @@ +From 573f037891f1fe754b8b112e6127c3380f247989 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 14 May 2024 19:24:30 +0800 +Subject: jbd2: avoid memleak in jbd2_journal_write_metadata_buffer + +From: Kemeng Shi + +[ Upstream commit cc102aa24638b90e04364d64e4f58a1fa91a1976 ] + +The new_bh is from alloc_buffer_head, we should call free_buffer_head to +free it in error case. + +Signed-off-by: Kemeng Shi +Reviewed-by: Zhang Yi +Reviewed-by: Jan Kara +Link: https://patch.msgid.link/20240514112438.1269037-2-shikemeng@huaweicloud.com +Signed-off-by: Theodore Ts'o +Signed-off-by: Sasha Levin +--- + fs/jbd2/journal.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c +index 629928b19e487..08cff80f8c297 100644 +--- a/fs/jbd2/journal.c ++++ b/fs/jbd2/journal.c +@@ -430,6 +430,7 @@ int jbd2_journal_write_metadata_buffer(transaction_t *transaction, + tmp = jbd2_alloc(bh_in->b_size, GFP_NOFS); + if (!tmp) { + brelse(new_bh); ++ free_buffer_head(new_bh); + return -ENOMEM; + } + jbd_lock_bh_state(bh_in); +-- +2.43.0 + diff --git a/queue-4.19/md-raid5-avoid-bug_on-while-continue-reshape-after-r.patch b/queue-4.19/md-raid5-avoid-bug_on-while-continue-reshape-after-r.patch new file mode 100644 index 00000000000..bf1692f4b13 --- /dev/null +++ b/queue-4.19/md-raid5-avoid-bug_on-while-continue-reshape-after-r.patch @@ -0,0 +1,93 @@ +From d1bf6c100ad6f7c71e60de03cdc0bd8bc65adf64 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 11 Jun 2024 21:22:51 +0800 +Subject: md/raid5: avoid BUG_ON() while continue reshape after reassembling + +From: Yu Kuai + +[ Upstream commit 305a5170dc5cf3d395bb4c4e9239bca6d0b54b49 ] + +Currently, mdadm support --revert-reshape to abort the reshape while +reassembling, as the test 07revert-grow. However, following BUG_ON() +can be triggerred by the test: + +kernel BUG at drivers/md/raid5.c:6278! +invalid opcode: 0000 [#1] PREEMPT SMP PTI +irq event stamp: 158985 +CPU: 6 PID: 891 Comm: md0_reshape Not tainted 6.9.0-03335-g7592a0b0049a #94 +RIP: 0010:reshape_request+0x3f1/0xe60 +Call Trace: + + raid5_sync_request+0x43d/0x550 + md_do_sync+0xb7a/0x2110 + md_thread+0x294/0x2b0 + kthread+0x147/0x1c0 + ret_from_fork+0x59/0x70 + ret_from_fork_asm+0x1a/0x30 + + +Root cause is that --revert-reshape update the raid_disks from 5 to 4, +while reshape position is still set, and after reassembling the array, +reshape position will be read from super block, then during reshape the +checking of 'writepos' that is caculated by old reshape position will +fail. + +Fix this panic the easy way first, by converting the BUG_ON() to +WARN_ON(), and stop the reshape if checkings fail. + +Noted that mdadm must fix --revert-shape as well, and probably md/raid +should enhance metadata validation as well, however this means +reassemble will fail and there must be user tools to fix the wrong +metadata. + +Signed-off-by: Yu Kuai +Signed-off-by: Song Liu +Link: https://lore.kernel.org/r/20240611132251.1967786-13-yukuai1@huaweicloud.com +Signed-off-by: Sasha Levin +--- + drivers/md/raid5.c | 20 +++++++++++++------- + 1 file changed, 13 insertions(+), 7 deletions(-) + +diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c +index 4e125c84be49c..0adcc67c1a122 100644 +--- a/drivers/md/raid5.c ++++ b/drivers/md/raid5.c +@@ -5818,7 +5818,9 @@ static sector_t reshape_request(struct mddev *mddev, sector_t sector_nr, int *sk + safepos = conf->reshape_safe; + sector_div(safepos, data_disks); + if (mddev->reshape_backwards) { +- BUG_ON(writepos < reshape_sectors); ++ if (WARN_ON(writepos < reshape_sectors)) ++ return MaxSector; ++ + writepos -= reshape_sectors; + readpos += reshape_sectors; + safepos += reshape_sectors; +@@ -5836,14 +5838,18 @@ static sector_t reshape_request(struct mddev *mddev, sector_t sector_nr, int *sk + * to set 'stripe_addr' which is where we will write to. + */ + if (mddev->reshape_backwards) { +- BUG_ON(conf->reshape_progress == 0); ++ if (WARN_ON(conf->reshape_progress == 0)) ++ return MaxSector; ++ + stripe_addr = writepos; +- BUG_ON((mddev->dev_sectors & +- ~((sector_t)reshape_sectors - 1)) +- - reshape_sectors - stripe_addr +- != sector_nr); ++ if (WARN_ON((mddev->dev_sectors & ++ ~((sector_t)reshape_sectors - 1)) - ++ reshape_sectors - stripe_addr != sector_nr)) ++ return MaxSector; + } else { +- BUG_ON(writepos != sector_nr + reshape_sectors); ++ if (WARN_ON(writepos != sector_nr + reshape_sectors)) ++ return MaxSector; ++ + stripe_addr = sector_nr; + } + +-- +2.43.0 + diff --git a/queue-4.19/media-uvcvideo-fix-the-bandwdith-quirk-on-usb-3.x.patch b/queue-4.19/media-uvcvideo-fix-the-bandwdith-quirk-on-usb-3.x.patch new file mode 100644 index 00000000000..fa0731e27b8 --- /dev/null +++ b/queue-4.19/media-uvcvideo-fix-the-bandwdith-quirk-on-usb-3.x.patch @@ -0,0 +1,52 @@ +From 66eb001bc23ba889657c3c17f8d40b8feeaca9f5 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 14 Apr 2024 19:00:40 +0200 +Subject: media: uvcvideo: Fix the bandwdith quirk on USB 3.x + +From: Michal Pecio + +[ Upstream commit 9e3d55fbd160b3ca376599a68b4cddfdc67d4153 ] + +The bandwidth fixup quirk doesn't know that SuperSpeed exists and has +the same 8 service intervals per millisecond as High Speed, hence its +calculations are wrong. + +Assume that all speeds from HS up use 8 intervals per millisecond. + +No further changes are needed, updated code has been confirmed to work +with all speeds from FS to SS. + +Signed-off-by: Michal Pecio +Reviewed-by: Ricardo Ribalda +Reviewed-by: Laurent Pinchart +Link: https://lore.kernel.org/r/20240414190040.2255a0bc@foxbook +Signed-off-by: Laurent Pinchart +Signed-off-by: Sasha Levin +--- + drivers/media/usb/uvc/uvc_video.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c +index e2c1b98fb4a25..3f0796141545d 100644 +--- a/drivers/media/usb/uvc/uvc_video.c ++++ b/drivers/media/usb/uvc/uvc_video.c +@@ -212,13 +212,13 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming *stream, + /* Compute a bandwidth estimation by multiplying the frame + * size by the number of video frames per second, divide the + * result by the number of USB frames (or micro-frames for +- * high-speed devices) per second and add the UVC header size +- * (assumed to be 12 bytes long). ++ * high- and super-speed devices) per second and add the UVC ++ * header size (assumed to be 12 bytes long). + */ + bandwidth = frame->wWidth * frame->wHeight / 8 * format->bpp; + bandwidth *= 10000000 / interval + 1; + bandwidth /= 1000; +- if (stream->dev->udev->speed == USB_SPEED_HIGH) ++ if (stream->dev->udev->speed >= USB_SPEED_HIGH) + bandwidth /= 8; + bandwidth += 12; + +-- +2.43.0 + diff --git a/queue-4.19/media-uvcvideo-ignore-empty-ts-packets.patch b/queue-4.19/media-uvcvideo-ignore-empty-ts-packets.patch new file mode 100644 index 00000000000..58603a7b133 --- /dev/null +++ b/queue-4.19/media-uvcvideo-ignore-empty-ts-packets.patch @@ -0,0 +1,129 @@ +From c0543a17aa8b63ae3ceab557b6ecc8803dd50d72 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 23 Mar 2024 10:48:03 +0000 +Subject: media: uvcvideo: Ignore empty TS packets + +From: Ricardo Ribalda + +[ Upstream commit 5cd7c25f6f0576073b3d03bc4cfb1e8ca63a1195 ] + +Some SunplusIT cameras took a borderline interpretation of the UVC 1.5 +standard, and fill the PTS and SCR fields with invalid data if the +package does not contain data. + +"STC must be captured when the first video data of a video frame is put +on the USB bus." + +Some SunplusIT devices send, e.g., + +buffer: 0xa7755c00 len 000012 header:0x8c stc 00000000 sof 0000 pts 00000000 +buffer: 0xa7755c00 len 000012 header:0x8c stc 00000000 sof 0000 pts 00000000 +buffer: 0xa7755c00 len 000668 header:0x8c stc 73779dba sof 070c pts 7376d37a + +While the UVC specification meant that the first two packets shouldn't +have had the SCR bit set in the header. + +This borderline/buggy interpretation has been implemented in a variety +of devices, from directly SunplusIT and from other OEMs that rebrand +SunplusIT products. So quirking based on VID:PID will be problematic. + +All the affected modules have the following extension unit: +VideoControl Interface Descriptor: + guidExtensionCode {82066163-7050-ab49-b8cc-b3855e8d221d} + +But the vendor plans to use that GUID in the future and fix the bug, +this means that we should use heuristic to figure out the broken +packets. + +This patch takes care of this. + +lsusb of one of the affected cameras: + +Bus 001 Device 003: ID 1bcf:2a01 Sunplus Innovation Technology Inc. +Device Descriptor: + bLength 18 + bDescriptorType 1 + bcdUSB 2.01 + bDeviceClass 239 Miscellaneous Device + bDeviceSubClass 2 ? + bDeviceProtocol 1 Interface Association + bMaxPacketSize0 64 + idVendor 0x1bcf Sunplus Innovation Technology Inc. + idProduct 0x2a01 + bcdDevice 0.02 + iManufacturer 1 SunplusIT Inc + iProduct 2 HanChen Wise Camera + iSerial 3 01.00.00 + bNumConfigurations 1 + +Tested-by: HungNien Chen +Reviewed-by: Sergey Senozhatsky +Reviewed-by: Laurent Pinchart +Signed-off-by: Ricardo Ribalda +Reviewed-by: Tomasz Figa +Link: https://lore.kernel.org/r/20240323-resend-hwtimestamp-v10-2-b08e590d97c7@chromium.org +Signed-off-by: Laurent Pinchart +Signed-off-by: Sasha Levin +--- + drivers/media/usb/uvc/uvc_video.c | 31 ++++++++++++++++++++++++++++++- + 1 file changed, 30 insertions(+), 1 deletion(-) + +diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c +index c57bc62251bb8..e2c1b98fb4a25 100644 +--- a/drivers/media/usb/uvc/uvc_video.c ++++ b/drivers/media/usb/uvc/uvc_video.c +@@ -473,6 +473,7 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf, + ktime_t time; + u16 host_sof; + u16 dev_sof; ++ u32 dev_stc; + + switch (data[1] & (UVC_STREAM_PTS | UVC_STREAM_SCR)) { + case UVC_STREAM_PTS | UVC_STREAM_SCR: +@@ -517,6 +518,34 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf, + if (dev_sof == stream->clock.last_sof) + return; + ++ dev_stc = get_unaligned_le32(&data[header_size - 6]); ++ ++ /* ++ * STC (Source Time Clock) is the clock used by the camera. The UVC 1.5 ++ * standard states that it "must be captured when the first video data ++ * of a video frame is put on the USB bus". This is generally understood ++ * as requiring devices to clear the payload header's SCR bit before ++ * the first packet containing video data. ++ * ++ * Most vendors follow that interpretation, but some (namely SunplusIT ++ * on some devices) always set the `UVC_STREAM_SCR` bit, fill the SCR ++ * field with 0's,and expect that the driver only processes the SCR if ++ * there is data in the packet. ++ * ++ * Ignore all the hardware timestamp information if we haven't received ++ * any data for this frame yet, the packet contains no data, and both ++ * STC and SOF are zero. This heuristics should be safe on compliant ++ * devices. This should be safe with compliant devices, as in the very ++ * unlikely case where a UVC 1.1 device would send timing information ++ * only before the first packet containing data, and both STC and SOF ++ * happen to be zero for a particular frame, we would only miss one ++ * clock sample from many and the clock recovery algorithm wouldn't ++ * suffer from this condition. ++ */ ++ if (buf && buf->bytesused == 0 && len == header_size && ++ dev_stc == 0 && dev_sof == 0) ++ return; ++ + stream->clock.last_sof = dev_sof; + + host_sof = usb_get_current_frame_number(stream->dev->udev); +@@ -554,7 +583,7 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf, + spin_lock_irqsave(&stream->clock.lock, flags); + + sample = &stream->clock.samples[stream->clock.head]; +- sample->dev_stc = get_unaligned_le32(&data[header_size - 6]); ++ sample->dev_stc = dev_stc; + sample->dev_sof = dev_sof; + sample->host_sof = host_sof; + sample->host_time = time; +-- +2.43.0 + diff --git a/queue-4.19/net-fec-stop-pps-on-driver-remove.patch b/queue-4.19/net-fec-stop-pps-on-driver-remove.patch new file mode 100644 index 00000000000..7f823e46967 --- /dev/null +++ b/queue-4.19/net-fec-stop-pps-on-driver-remove.patch @@ -0,0 +1,46 @@ +From 5c706855430d26a3dfcaf062ae17d59125560e08 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 7 Aug 2024 10:09:56 +0200 +Subject: net: fec: Stop PPS on driver remove +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Csókás, Bence + +[ Upstream commit 8fee6d5ad5fa18c270eedb2a2cdf58dbadefb94b ] + +PPS was not stopped in `fec_ptp_stop()`, called when +the adapter was removed. Consequentially, you couldn't +safely reload the driver with the PPS signal on. + +Fixes: 32cba57ba74b ("net: fec: introduce fec_ptp_stop and use in probe fail path") +Reviewed-by: Fabio Estevam +Link: https://lore.kernel.org/netdev/CAOMZO5BzcZR8PwKKwBssQq_wAGzVgf1ffwe_nhpQJjviTdxy-w@mail.gmail.com/T/#m01dcb810bfc451a492140f6797ca77443d0cb79f +Signed-off-by: Csókás, Bence +Reviewed-by: Andrew Lunn +Reviewed-by: Frank Li +Link: https://patch.msgid.link/20240807080956.2556602-1-csokas.bence@prolan.hu +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/freescale/fec_ptp.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/drivers/net/ethernet/freescale/fec_ptp.c b/drivers/net/ethernet/freescale/fec_ptp.c +index abf0b6cddf204..a5d693f51d2b1 100644 +--- a/drivers/net/ethernet/freescale/fec_ptp.c ++++ b/drivers/net/ethernet/freescale/fec_ptp.c +@@ -635,6 +635,9 @@ void fec_ptp_stop(struct platform_device *pdev) + struct net_device *ndev = platform_get_drvdata(pdev); + struct fec_enet_private *fep = netdev_priv(ndev); + ++ if (fep->pps_enable) ++ fec_ptp_enable_pps(fep, 0); ++ + cancel_delayed_work_sync(&fep->time_keep); + if (fep->ptp_clock) + ptp_clock_unregister(fep->ptp_clock); +-- +2.43.0 + diff --git a/queue-4.19/net-linkwatch-use-system_unbound_wq.patch b/queue-4.19/net-linkwatch-use-system_unbound_wq.patch new file mode 100644 index 00000000000..6be9107a9c8 --- /dev/null +++ b/queue-4.19/net-linkwatch-use-system_unbound_wq.patch @@ -0,0 +1,52 @@ +From 858336b26397bc0d2cb8d52f46d89254630e631b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 5 Aug 2024 08:58:21 +0000 +Subject: net: linkwatch: use system_unbound_wq + +From: Eric Dumazet + +[ Upstream commit 3e7917c0cdad835a5121520fc5686d954b7a61ab ] + +linkwatch_event() grabs possibly very contended RTNL mutex. + +system_wq is not suitable for such work. + +Inspired by many noisy syzbot reports. + +3 locks held by kworker/0:7/5266: + #0: ffff888015480948 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3206 [inline] + #0: ffff888015480948 ((wq_completion)events){+.+.}-{0:0}, at: process_scheduled_works+0x90a/0x1830 kernel/workqueue.c:3312 + #1: ffffc90003f6fd00 ((linkwatch_work).work){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3207 [inline] + , at: process_scheduled_works+0x945/0x1830 kernel/workqueue.c:3312 + #2: ffffffff8fa6f208 (rtnl_mutex){+.+.}-{3:3}, at: linkwatch_event+0xe/0x60 net/core/link_watch.c:276 + +Reported-by: syzbot +Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") +Signed-off-by: Eric Dumazet +Reviewed-by: Kuniyuki Iwashima +Link: https://patch.msgid.link/20240805085821.1616528-1-edumazet@google.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + net/core/link_watch.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/net/core/link_watch.c b/net/core/link_watch.c +index e38e641e98d5b..320be467b7851 100644 +--- a/net/core/link_watch.c ++++ b/net/core/link_watch.c +@@ -135,9 +135,9 @@ static void linkwatch_schedule_work(int urgent) + * override the existing timer. + */ + if (test_bit(LW_URGENT, &linkwatch_flags)) +- mod_delayed_work(system_wq, &linkwatch_work, 0); ++ mod_delayed_work(system_unbound_wq, &linkwatch_work, 0); + else +- schedule_delayed_work(&linkwatch_work, delay); ++ queue_delayed_work(system_unbound_wq, &linkwatch_work, delay); + } + + +-- +2.43.0 + diff --git a/queue-4.19/net-usb-qmi_wwan-fix-memory-leak-for-not-ip-packets.patch b/queue-4.19/net-usb-qmi_wwan-fix-memory-leak-for-not-ip-packets.patch new file mode 100644 index 00000000000..9679647d37b --- /dev/null +++ b/queue-4.19/net-usb-qmi_wwan-fix-memory-leak-for-not-ip-packets.patch @@ -0,0 +1,38 @@ +From 6a025582b33c43389270e9435919108769bd1b4f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 1 Aug 2024 15:55:12 +0200 +Subject: net: usb: qmi_wwan: fix memory leak for not ip packets +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Daniele Palmas + +[ Upstream commit 7ab107544b777c3bd7feb9fe447367d8edd5b202 ] + +Free the unused skb when not ip packets arrive. + +Fixes: c6adf77953bc ("net: usb: qmi_wwan: add qmap mux protocol support") +Signed-off-by: Daniele Palmas +Acked-by: Bjørn Mork +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/net/usb/qmi_wwan.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c +index 3c65549a8688a..881240d939564 100644 +--- a/drivers/net/usb/qmi_wwan.c ++++ b/drivers/net/usb/qmi_wwan.c +@@ -241,6 +241,7 @@ static int qmimux_rx_fixup(struct usbnet *dev, struct sk_buff *skb) + break; + default: + /* not ip - do not know what to do */ ++ kfree_skb(skbn); + goto skip; + } + +-- +2.43.0 + diff --git a/queue-4.19/pci-add-edimax-vendor-id-to-pci_ids.h.patch b/queue-4.19/pci-add-edimax-vendor-id-to-pci_ids.h.patch new file mode 100644 index 00000000000..c5344d6e6cb --- /dev/null +++ b/queue-4.19/pci-add-edimax-vendor-id-to-pci_ids.h.patch @@ -0,0 +1,38 @@ +From 3803b20905be100cb4cf4189ac813c2c9401c9a1 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 24 Jun 2024 08:55:01 +0900 +Subject: PCI: Add Edimax Vendor ID to pci_ids.h + +From: FUJITA Tomonori + +[ Upstream commit eee5528890d54b22b46f833002355a5ee94c3bb4 ] + +Add the Edimax Vendor ID (0x1432) for an ethernet driver for Tehuti +Networks TN40xx chips. This ID can be used for Realtek 8180 and Ralink +rt28xx wireless drivers. + +Signed-off-by: FUJITA Tomonori +Acked-by: Bjorn Helgaas +Link: https://patch.msgid.link/20240623235507.108147-2-fujita.tomonori@gmail.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + include/linux/pci_ids.h | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h +index 3ac7b92b35b9d..91193284710f1 100644 +--- a/include/linux/pci_ids.h ++++ b/include/linux/pci_ids.h +@@ -2136,6 +2136,8 @@ + + #define PCI_VENDOR_ID_CHELSIO 0x1425 + ++#define PCI_VENDOR_ID_EDIMAX 0x1432 ++ + #define PCI_VENDOR_ID_ADLINK 0x144a + + #define PCI_VENDOR_ID_SAMSUNG 0x144d +-- +2.43.0 + diff --git a/queue-4.19/s390-sclp-prevent-release-of-buffer-in-i-o.patch b/queue-4.19/s390-sclp-prevent-release-of-buffer-in-i-o.patch new file mode 100644 index 00000000000..be6cb6fcd4a --- /dev/null +++ b/queue-4.19/s390-sclp-prevent-release-of-buffer-in-i-o.patch @@ -0,0 +1,52 @@ +From e4ed1e69d07be77475f8b1f465faf469ed69b156 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 20 Jun 2024 14:20:27 +0200 +Subject: s390/sclp: Prevent release of buffer in I/O + +From: Peter Oberparleiter + +[ Upstream commit bf365071ea92b9579d5a272679b74052a5643e35 ] + +When a task waiting for completion of a Store Data operation is +interrupted, an attempt is made to halt this operation. If this attempt +fails due to a hardware or firmware problem, there is a chance that the +SCLP facility might store data into buffers referenced by the original +operation at a later time. + +Handle this situation by not releasing the referenced data buffers if +the halt attempt fails. For current use cases, this might result in a +leak of few pages of memory in case of a rare hardware/firmware +malfunction. + +Reviewed-by: Heiko Carstens +Signed-off-by: Peter Oberparleiter +Signed-off-by: Alexander Gordeev +Signed-off-by: Sasha Levin +--- + drivers/s390/char/sclp_sd.c | 10 ++++++++-- + 1 file changed, 8 insertions(+), 2 deletions(-) + +diff --git a/drivers/s390/char/sclp_sd.c b/drivers/s390/char/sclp_sd.c +index 1e244f78f1929..64581433c3349 100644 +--- a/drivers/s390/char/sclp_sd.c ++++ b/drivers/s390/char/sclp_sd.c +@@ -319,8 +319,14 @@ static int sclp_sd_store_data(struct sclp_sd_data *result, u8 di) + &esize); + if (rc) { + /* Cancel running request if interrupted */ +- if (rc == -ERESTARTSYS) +- sclp_sd_sync(page, SD_EQ_HALT, di, 0, 0, NULL, NULL); ++ if (rc == -ERESTARTSYS) { ++ if (sclp_sd_sync(page, SD_EQ_HALT, di, 0, 0, NULL, NULL)) { ++ pr_warn("Could not stop Store Data request - leaking at least %zu bytes\n", ++ (size_t)dsize * PAGE_SIZE); ++ data = NULL; ++ asce = 0; ++ } ++ } + vfree(data); + goto out; + } +-- +2.43.0 + diff --git a/queue-4.19/series b/queue-4.19/series index b6e532b8703..90f16a3e0d9 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -126,3 +126,20 @@ ipv6-fix-ndisc_is_useropt-handling-for-pio.patch protect-the-fetch-of-fd-in-do_dup2-from-mispredictions.patch alsa-usb-audio-correct-surround-channels-in-uac1-channel-map.patch net-usb-sr9700-fix-uninitialized-variable-use-in-sr_mdio_read.patch +irqchip-mbigen-fix-mbigen-node-address-layout.patch +x86-mm-fix-pti_clone_pgtable-alignment-assumption.patch +net-usb-qmi_wwan-fix-memory-leak-for-not-ip-packets.patch +net-linkwatch-use-system_unbound_wq.patch +bluetooth-l2cap-always-unlock-channel-in-l2cap_conle.patch +net-fec-stop-pps-on-driver-remove.patch +md-raid5-avoid-bug_on-while-continue-reshape-after-r.patch +clocksource-drivers-sh_cmt-address-race-condition-fo.patch +pci-add-edimax-vendor-id-to-pci_ids.h.patch +udf-prevent-integer-overflow-in-udf_bitmap_free_bloc.patch +wifi-nl80211-don-t-give-key-data-to-userspace.patch +btrfs-fix-bitmap-leak-when-loading-free-space-cache-.patch +media-uvcvideo-ignore-empty-ts-packets.patch +media-uvcvideo-fix-the-bandwdith-quirk-on-usb-3.x.patch +jbd2-avoid-memleak-in-jbd2_journal_write_metadata_bu.patch +s390-sclp-prevent-release-of-buffer-in-i-o.patch +sunrpc-fix-a-race-to-wake-a-sync-task.patch diff --git a/queue-4.19/sunrpc-fix-a-race-to-wake-a-sync-task.patch b/queue-4.19/sunrpc-fix-a-race-to-wake-a-sync-task.patch new file mode 100644 index 00000000000..e3f4f8f9e26 --- /dev/null +++ b/queue-4.19/sunrpc-fix-a-race-to-wake-a-sync-task.patch @@ -0,0 +1,53 @@ +From bc5c75d2572217d6c2172157e14058c1e89d5727 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 17 Jul 2024 10:49:33 -0400 +Subject: SUNRPC: Fix a race to wake a sync task + +From: Benjamin Coddington + +[ Upstream commit ed0172af5d6fc07d1b40ca82f5ca3979300369f7 ] + +We've observed NFS clients with sync tasks sleeping in __rpc_execute +waiting on RPC_TASK_QUEUED that have not responded to a wake-up from +rpc_make_runnable(). I suspect this problem usually goes unnoticed, +because on a busy client the task will eventually be re-awoken by another +task completion or xprt event. However, if the state manager is draining +the slot table, a sync task missing a wake-up can result in a hung client. + +We've been able to prove that the waker in rpc_make_runnable() successfully +calls wake_up_bit() (ie- there's no race to tk_runstate), but the +wake_up_bit() call fails to wake the waiter. I suspect the waker is +missing the load of the bit's wait_queue_head, so waitqueue_active() is +false. There are some very helpful comments about this problem above +wake_up_bit(), prepare_to_wait(), and waitqueue_active(). + +Fix this by inserting smp_mb__after_atomic() before the wake_up_bit(), +which pairs with prepare_to_wait() calling set_current_state(). + +Signed-off-by: Benjamin Coddington +Reviewed-by: Jeff Layton +Signed-off-by: Anna Schumaker +Signed-off-by: Sasha Levin +--- + net/sunrpc/sched.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +diff --git a/net/sunrpc/sched.c b/net/sunrpc/sched.c +index 9af919364a001..92d88aa62085b 100644 +--- a/net/sunrpc/sched.c ++++ b/net/sunrpc/sched.c +@@ -349,8 +349,10 @@ static void rpc_make_runnable(struct workqueue_struct *wq, + if (RPC_IS_ASYNC(task)) { + INIT_WORK(&task->u.tk_work, rpc_async_schedule); + queue_work(wq, &task->u.tk_work); +- } else ++ } else { ++ smp_mb__after_atomic(); + wake_up_bit(&task->tk_runstate, RPC_TASK_QUEUED); ++ } + } + + /* +-- +2.43.0 + diff --git a/queue-4.19/udf-prevent-integer-overflow-in-udf_bitmap_free_bloc.patch b/queue-4.19/udf-prevent-integer-overflow-in-udf_bitmap_free_bloc.patch new file mode 100644 index 00000000000..ec1422584c9 --- /dev/null +++ b/queue-4.19/udf-prevent-integer-overflow-in-udf_bitmap_free_bloc.patch @@ -0,0 +1,113 @@ +From 2cb8bd0cd6f282890af86b583b7fbf3777f16be3 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 20 Jun 2024 10:24:13 +0300 +Subject: udf: prevent integer overflow in udf_bitmap_free_blocks() + +From: Roman Smirnov + +[ Upstream commit 56e69e59751d20993f243fb7dd6991c4e522424c ] + +An overflow may occur if the function is called with the last +block and an offset greater than zero. It is necessary to add +a check to avoid this. + +Found by Linux Verification Center (linuxtesting.org) with Svace. + +[JK: Make test cover also unalloc table freeing] + +Link: https://patch.msgid.link/20240620072413.7448-1-r.smirnov@omp.ru +Suggested-by: Jan Kara +Signed-off-by: Roman Smirnov +Signed-off-by: Jan Kara +Signed-off-by: Sasha Levin +--- + fs/udf/balloc.c | 36 +++++++++++++----------------------- + 1 file changed, 13 insertions(+), 23 deletions(-) + +diff --git a/fs/udf/balloc.c b/fs/udf/balloc.c +index 0dc98bbad9c46..ac45f25bf40cc 100644 +--- a/fs/udf/balloc.c ++++ b/fs/udf/balloc.c +@@ -22,6 +22,7 @@ + #include "udfdecl.h" + + #include ++#include + + #include "udf_i.h" + #include "udf_sb.h" +@@ -133,7 +134,6 @@ static void udf_bitmap_free_blocks(struct super_block *sb, + { + struct udf_sb_info *sbi = UDF_SB(sb); + struct buffer_head *bh = NULL; +- struct udf_part_map *partmap; + unsigned long block; + unsigned long block_group; + unsigned long bit; +@@ -142,19 +142,9 @@ static void udf_bitmap_free_blocks(struct super_block *sb, + unsigned long overflow; + + mutex_lock(&sbi->s_alloc_mutex); +- partmap = &sbi->s_partmaps[bloc->partitionReferenceNum]; +- if (bloc->logicalBlockNum + count < count || +- (bloc->logicalBlockNum + count) > partmap->s_partition_len) { +- udf_debug("%u < %d || %u + %u > %u\n", +- bloc->logicalBlockNum, 0, +- bloc->logicalBlockNum, count, +- partmap->s_partition_len); +- goto error_return; +- } +- ++ /* We make sure this cannot overflow when mounting the filesystem */ + block = bloc->logicalBlockNum + offset + + (sizeof(struct spaceBitmapDesc) << 3); +- + do { + overflow = 0; + block_group = block >> (sb->s_blocksize_bits + 3); +@@ -375,7 +365,6 @@ static void udf_table_free_blocks(struct super_block *sb, + uint32_t count) + { + struct udf_sb_info *sbi = UDF_SB(sb); +- struct udf_part_map *partmap; + uint32_t start, end; + uint32_t elen; + struct kernel_lb_addr eloc; +@@ -384,16 +373,6 @@ static void udf_table_free_blocks(struct super_block *sb, + struct udf_inode_info *iinfo; + + mutex_lock(&sbi->s_alloc_mutex); +- partmap = &sbi->s_partmaps[bloc->partitionReferenceNum]; +- if (bloc->logicalBlockNum + count < count || +- (bloc->logicalBlockNum + count) > partmap->s_partition_len) { +- udf_debug("%u < %d || %u + %u > %u\n", +- bloc->logicalBlockNum, 0, +- bloc->logicalBlockNum, count, +- partmap->s_partition_len); +- goto error_return; +- } +- + iinfo = UDF_I(table); + udf_add_free_space(sb, sbi->s_partition, count); + +@@ -668,6 +647,17 @@ void udf_free_blocks(struct super_block *sb, struct inode *inode, + { + uint16_t partition = bloc->partitionReferenceNum; + struct udf_part_map *map = &UDF_SB(sb)->s_partmaps[partition]; ++ uint32_t blk; ++ ++ if (check_add_overflow(bloc->logicalBlockNum, offset, &blk) || ++ check_add_overflow(blk, count, &blk) || ++ bloc->logicalBlockNum + count > map->s_partition_len) { ++ udf_debug("Invalid request to free blocks: (%d, %u), off %u, " ++ "len %u, partition len %u\n", ++ partition, bloc->logicalBlockNum, offset, count, ++ map->s_partition_len); ++ return; ++ } + + if (map->s_partition_flags & UDF_PART_FLAG_UNALLOC_BITMAP) { + udf_bitmap_free_blocks(sb, map->s_uspace.s_bitmap, +-- +2.43.0 + diff --git a/queue-4.19/wifi-nl80211-don-t-give-key-data-to-userspace.patch b/queue-4.19/wifi-nl80211-don-t-give-key-data-to-userspace.patch new file mode 100644 index 00000000000..6d104ffcd8b --- /dev/null +++ b/queue-4.19/wifi-nl80211-don-t-give-key-data-to-userspace.patch @@ -0,0 +1,55 @@ +From f575481899250484d7920dadc776aa37b6ffe6f4 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 27 Jun 2024 10:44:11 +0200 +Subject: wifi: nl80211: don't give key data to userspace + +From: Johannes Berg + +[ Upstream commit a7e5793035792cc46a1a4b0a783655ffa897dfe9 ] + +When a key is requested by userspace, there's really no need +to include the key data, the sequence counter is really what +userspace needs in this case. The fact that it's included is +just a historic quirk. + +Remove the key data. + +Reviewed-by: Miriam Rachel Korenblit +Link: https://patch.msgid.link/20240627104411.b6a4f097e4ea.I7e6cc976cb9e8a80ef25a3351330f313373b4578@changeid +Signed-off-by: Johannes Berg +Signed-off-by: Sasha Levin +--- + net/wireless/nl80211.c | 10 ++-------- + 1 file changed, 2 insertions(+), 8 deletions(-) + +diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c +index 15f28203445cb..ebd8449f2fcf1 100644 +--- a/net/wireless/nl80211.c ++++ b/net/wireless/nl80211.c +@@ -3383,10 +3383,7 @@ static void get_key_callback(void *c, struct key_params *params) + struct nlattr *key; + struct get_key_cookie *cookie = c; + +- if ((params->key && +- nla_put(cookie->msg, NL80211_ATTR_KEY_DATA, +- params->key_len, params->key)) || +- (params->seq && ++ if ((params->seq && + nla_put(cookie->msg, NL80211_ATTR_KEY_SEQ, + params->seq_len, params->seq)) || + (params->cipher && +@@ -3398,10 +3395,7 @@ static void get_key_callback(void *c, struct key_params *params) + if (!key) + goto nla_put_failure; + +- if ((params->key && +- nla_put(cookie->msg, NL80211_KEY_DATA, +- params->key_len, params->key)) || +- (params->seq && ++ if ((params->seq && + nla_put(cookie->msg, NL80211_KEY_SEQ, + params->seq_len, params->seq)) || + (params->cipher && +-- +2.43.0 + diff --git a/queue-4.19/x86-mm-fix-pti_clone_pgtable-alignment-assumption.patch b/queue-4.19/x86-mm-fix-pti_clone_pgtable-alignment-assumption.patch new file mode 100644 index 00000000000..004a7b1db5e --- /dev/null +++ b/queue-4.19/x86-mm-fix-pti_clone_pgtable-alignment-assumption.patch @@ -0,0 +1,68 @@ +From f558025846c3dc737a93383e1a6ed87ead131e0d Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 31 Jul 2024 18:31:05 +0200 +Subject: x86/mm: Fix pti_clone_pgtable() alignment assumption + +From: Peter Zijlstra + +[ Upstream commit 41e71dbb0e0a0fe214545fe64af031303a08524c ] + +Guenter reported dodgy crashes on an i386-nosmp build using GCC-11 +that had the form of endless traps until entry stack exhaust and then +#DF from the stack guard. + +It turned out that pti_clone_pgtable() had alignment assumptions on +the start address, notably it hard assumes start is PMD aligned. This +is true on x86_64, but very much not true on i386. + +These assumptions can cause the end condition to malfunction, leading +to a 'short' clone. Guess what happens when the user mapping has a +short copy of the entry text? + +Use the correct increment form for addr to avoid alignment +assumptions. + +Fixes: 16a3fe634f6a ("x86/mm/pti: Clone kernel-image on PTE level for 32 bit") +Reported-by: Guenter Roeck +Tested-by: Guenter Roeck +Suggested-by: Thomas Gleixner +Signed-off-by: Peter Zijlstra (Intel) +Link: https://lkml.kernel.org/r/20240731163105.GG33588@noisy.programming.kicks-ass.net +Signed-off-by: Sasha Levin +--- + arch/x86/mm/pti.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c +index 622d5968c9795..21105ae44ca18 100644 +--- a/arch/x86/mm/pti.c ++++ b/arch/x86/mm/pti.c +@@ -383,14 +383,14 @@ pti_clone_pgtable(unsigned long start, unsigned long end, + */ + *target_pmd = *pmd; + +- addr += PMD_SIZE; ++ addr = round_up(addr + 1, PMD_SIZE); + + } else if (level == PTI_CLONE_PTE) { + + /* Walk the page-table down to the pte level */ + pte = pte_offset_kernel(pmd, addr); + if (pte_none(*pte)) { +- addr += PAGE_SIZE; ++ addr = round_up(addr + 1, PAGE_SIZE); + continue; + } + +@@ -410,7 +410,7 @@ pti_clone_pgtable(unsigned long start, unsigned long end, + /* Clone the PTE */ + *target_pte = *pte; + +- addr += PAGE_SIZE; ++ addr = round_up(addr + 1, PAGE_SIZE); + + } else { + BUG(); +-- +2.43.0 + -- 2.47.3