From f07b20968526c0671a01c93ff102cff5a76ed587 Mon Sep 17 00:00:00 2001 From: Sasha Levin Date: Sun, 11 Aug 2024 08:55:10 -0400 Subject: [PATCH] Fixes for 5.10 Signed-off-by: Sasha Levin --- ...ate-alarm-sysfs-attribute-atomically.patch | 79 +++++++ ...alarm-sysfs-attribute-through-psy-co.patch | 95 ++++++++ ...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 ++++++++++++ ...he-null-pointer-dereference-to-ras_m.patch | 44 ++++ ...x-the-null-pointer-dereference-in-ap.patch | 105 +++++++++ ...bigen-fix-mbigen-node-address-layout.patch | 89 ++++++++ ...ak-in-jbd2_journal_write_metadata_bu.patch | 37 +++ queue-5.10/l2tp-fix-lockdep-splat.patch | 216 ++++++++++++++++++ ...lete-safemode_timer-in-mddev_suspend.patch | 48 ++++ ...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 +++++++++++ ...fix-a-possible-memory-leak-in-bcm_sf.patch | 50 ++++ .../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 +++ ...ection-of-chip-version-11-early-rtl8.patch | 41 ++++ ...-fix-rcu_torture_fwd_cb_cr-data-race.patch | 50 ++++ ...clp-prevent-release-of-buffer-in-i-o.patch | 52 +++++ ...null-ptr-deref-in-reuseport_add_sock.patch | 169 ++++++++++++++ ...node-and-hashent-out-of-sctp_ep_comm.patch | 212 +++++++++++++++++ ...x-send_signal-test-with-nested-confi.patch | 120 ++++++++++ queue-5.10/series | 30 +++ ...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 +++++ ...mm-fix-pti_clone_entry_text-for-i386.patch | 42 ++++ ...i_clone_pgtable-alignment-assumption.patch | 68 ++++++ 31 files changed, 2436 insertions(+) create mode 100644 queue-5.10/acpi-battery-create-alarm-sysfs-attribute-atomically.patch create mode 100644 queue-5.10/acpi-sbs-manage-alarm-sysfs-attribute-through-psy-co.patch create mode 100644 queue-5.10/bluetooth-l2cap-always-unlock-channel-in-l2cap_conle.patch create mode 100644 queue-5.10/btrfs-fix-bitmap-leak-when-loading-free-space-cache-.patch create mode 100644 queue-5.10/clocksource-drivers-sh_cmt-address-race-condition-fo.patch create mode 100644 queue-5.10/drm-amdgpu-fix-the-null-pointer-dereference-to-ras_m.patch create mode 100644 queue-5.10/drm-amdgpu-pm-fix-the-null-pointer-dereference-in-ap.patch create mode 100644 queue-5.10/irqchip-mbigen-fix-mbigen-node-address-layout.patch create mode 100644 queue-5.10/jbd2-avoid-memleak-in-jbd2_journal_write_metadata_bu.patch create mode 100644 queue-5.10/l2tp-fix-lockdep-splat.patch create mode 100644 queue-5.10/md-do-not-delete-safemode_timer-in-mddev_suspend.patch create mode 100644 queue-5.10/md-raid5-avoid-bug_on-while-continue-reshape-after-r.patch create mode 100644 queue-5.10/media-uvcvideo-fix-the-bandwdith-quirk-on-usb-3.x.patch create mode 100644 queue-5.10/media-uvcvideo-ignore-empty-ts-packets.patch create mode 100644 queue-5.10/net-dsa-bcm_sf2-fix-a-possible-memory-leak-in-bcm_sf.patch create mode 100644 queue-5.10/net-fec-stop-pps-on-driver-remove.patch create mode 100644 queue-5.10/net-linkwatch-use-system_unbound_wq.patch create mode 100644 queue-5.10/net-usb-qmi_wwan-fix-memory-leak-for-not-ip-packets.patch create mode 100644 queue-5.10/pci-add-edimax-vendor-id-to-pci_ids.h.patch create mode 100644 queue-5.10/r8169-remove-detection-of-chip-version-11-early-rtl8.patch create mode 100644 queue-5.10/rcutorture-fix-rcu_torture_fwd_cb_cr-data-race.patch create mode 100644 queue-5.10/s390-sclp-prevent-release-of-buffer-in-i-o.patch create mode 100644 queue-5.10/sctp-fix-null-ptr-deref-in-reuseport_add_sock.patch create mode 100644 queue-5.10/sctp-move-hlist_node-and-hashent-out-of-sctp_ep_comm.patch create mode 100644 queue-5.10/selftests-bpf-fix-send_signal-test-with-nested-confi.patch create mode 100644 queue-5.10/sunrpc-fix-a-race-to-wake-a-sync-task.patch create mode 100644 queue-5.10/udf-prevent-integer-overflow-in-udf_bitmap_free_bloc.patch create mode 100644 queue-5.10/wifi-nl80211-don-t-give-key-data-to-userspace.patch create mode 100644 queue-5.10/x86-mm-fix-pti_clone_entry_text-for-i386.patch create mode 100644 queue-5.10/x86-mm-fix-pti_clone_pgtable-alignment-assumption.patch diff --git a/queue-5.10/acpi-battery-create-alarm-sysfs-attribute-atomically.patch b/queue-5.10/acpi-battery-create-alarm-sysfs-attribute-atomically.patch new file mode 100644 index 00000000000..d7c96daea0b --- /dev/null +++ b/queue-5.10/acpi-battery-create-alarm-sysfs-attribute-atomically.patch @@ -0,0 +1,79 @@ +From 1eb3654ed63f8fd02ff1e49e96d7078bbc50abf8 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 9 Jun 2024 09:27:16 +0200 +Subject: ACPI: battery: create alarm sysfs attribute atomically +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Thomas Weißschuh + +[ Upstream commit a231eed10ed5a290129fda36ad7bcc263c53ff7d ] + +Let the power supply core register the attribute. +This ensures that the attribute is created before the device is +announced to userspace, avoid a race condition. + +Signed-off-by: Thomas Weißschuh +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Sasha Levin +--- + drivers/acpi/battery.c | 16 ++++++++++++---- + 1 file changed, 12 insertions(+), 4 deletions(-) + +diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c +index 8b43efe97da5d..2e1462b8929c0 100644 +--- a/drivers/acpi/battery.c ++++ b/drivers/acpi/battery.c +@@ -670,12 +670,18 @@ static ssize_t acpi_battery_alarm_store(struct device *dev, + return count; + } + +-static const struct device_attribute alarm_attr = { ++static struct device_attribute alarm_attr = { + .attr = {.name = "alarm", .mode = 0644}, + .show = acpi_battery_alarm_show, + .store = acpi_battery_alarm_store, + }; + ++static struct attribute *acpi_battery_attrs[] = { ++ &alarm_attr.attr, ++ NULL ++}; ++ATTRIBUTE_GROUPS(acpi_battery); ++ + /* + * The Battery Hooking API + * +@@ -812,7 +818,10 @@ static void __exit battery_hook_exit(void) + + static int sysfs_add_battery(struct acpi_battery *battery) + { +- struct power_supply_config psy_cfg = { .drv_data = battery, }; ++ struct power_supply_config psy_cfg = { ++ .drv_data = battery, ++ .attr_grp = acpi_battery_groups, ++ }; + bool full_cap_broken = false; + + if (!ACPI_BATTERY_CAPACITY_VALID(battery->full_charge_capacity) && +@@ -857,7 +866,7 @@ static int sysfs_add_battery(struct acpi_battery *battery) + return result; + } + battery_hook_add_battery(battery); +- return device_create_file(&battery->bat->dev, &alarm_attr); ++ return 0; + } + + static void sysfs_remove_battery(struct acpi_battery *battery) +@@ -868,7 +877,6 @@ static void sysfs_remove_battery(struct acpi_battery *battery) + return; + } + battery_hook_remove_battery(battery); +- device_remove_file(&battery->bat->dev, &alarm_attr); + power_supply_unregister(battery->bat); + battery->bat = NULL; + mutex_unlock(&battery->sysfs_lock); +-- +2.43.0 + diff --git a/queue-5.10/acpi-sbs-manage-alarm-sysfs-attribute-through-psy-co.patch b/queue-5.10/acpi-sbs-manage-alarm-sysfs-attribute-through-psy-co.patch new file mode 100644 index 00000000000..57aa4b94411 --- /dev/null +++ b/queue-5.10/acpi-sbs-manage-alarm-sysfs-attribute-through-psy-co.patch @@ -0,0 +1,95 @@ +From 4692f8d8a196ebdf4ffb7dd6997dad5c5e03ddd9 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 9 Jun 2024 13:13:28 +0200 +Subject: ACPI: SBS: manage alarm sysfs attribute through psy core +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Thomas Weißschuh + +[ Upstream commit 6bad28cfc30988a845fb3f59a99f4b8a4ce8fe95 ] + +Let the power supply core register the attribute. + +This ensures that the attribute is created before the device is +announced to userspace, avoiding a race condition. + +Signed-off-by: Thomas Weißschuh +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Sasha Levin +--- + drivers/acpi/sbs.c | 23 ++++++++++++----------- + 1 file changed, 12 insertions(+), 11 deletions(-) + +diff --git a/drivers/acpi/sbs.c b/drivers/acpi/sbs.c +index e6d9f4de28000..54396cb8930a4 100644 +--- a/drivers/acpi/sbs.c ++++ b/drivers/acpi/sbs.c +@@ -77,7 +77,6 @@ struct acpi_battery { + u16 spec; + u8 id; + u8 present:1; +- u8 have_sysfs_alarm:1; + }; + + #define to_acpi_battery(x) power_supply_get_drvdata(x) +@@ -462,12 +461,18 @@ static ssize_t acpi_battery_alarm_store(struct device *dev, + return count; + } + +-static const struct device_attribute alarm_attr = { ++static struct device_attribute alarm_attr = { + .attr = {.name = "alarm", .mode = 0644}, + .show = acpi_battery_alarm_show, + .store = acpi_battery_alarm_store, + }; + ++static struct attribute *acpi_battery_attrs[] = { ++ &alarm_attr.attr, ++ NULL ++}; ++ATTRIBUTE_GROUPS(acpi_battery); ++ + /* -------------------------------------------------------------------------- + Driver Interface + -------------------------------------------------------------------------- */ +@@ -509,7 +514,10 @@ static int acpi_battery_read(struct acpi_battery *battery) + static int acpi_battery_add(struct acpi_sbs *sbs, int id) + { + struct acpi_battery *battery = &sbs->battery[id]; +- struct power_supply_config psy_cfg = { .drv_data = battery, }; ++ struct power_supply_config psy_cfg = { ++ .drv_data = battery, ++ .attr_grp = acpi_battery_groups, ++ }; + int result; + + battery->id = id; +@@ -539,10 +547,6 @@ static int acpi_battery_add(struct acpi_sbs *sbs, int id) + goto end; + } + +- result = device_create_file(&battery->bat->dev, &alarm_attr); +- if (result) +- goto end; +- battery->have_sysfs_alarm = 1; + end: + printk(KERN_INFO PREFIX "%s [%s]: Battery Slot [%s] (battery %s)\n", + ACPI_SBS_DEVICE_NAME, acpi_device_bid(sbs->device), +@@ -554,11 +558,8 @@ static void acpi_battery_remove(struct acpi_sbs *sbs, int id) + { + struct acpi_battery *battery = &sbs->battery[id]; + +- if (battery->bat) { +- if (battery->have_sysfs_alarm) +- device_remove_file(&battery->bat->dev, &alarm_attr); ++ if (battery->bat) + power_supply_unregister(battery->bat); +- } + } + + static int acpi_charger_add(struct acpi_sbs *sbs) +-- +2.43.0 + diff --git a/queue-5.10/bluetooth-l2cap-always-unlock-channel-in-l2cap_conle.patch b/queue-5.10/bluetooth-l2cap-always-unlock-channel-in-l2cap_conle.patch new file mode 100644 index 00000000000..82f09319bb0 --- /dev/null +++ b/queue-5.10/bluetooth-l2cap-always-unlock-channel-in-l2cap_conle.patch @@ -0,0 +1,37 @@ +From 79aeb950cd4d20966fb2518d421e100cd7c603ef 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 9cc034e6074c1..23fc03f7bf312 100644 +--- a/net/bluetooth/l2cap_core.c ++++ b/net/bluetooth/l2cap_core.c +@@ -7762,6 +7762,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-5.10/btrfs-fix-bitmap-leak-when-loading-free-space-cache-.patch b/queue-5.10/btrfs-fix-bitmap-leak-when-loading-free-space-cache-.patch new file mode 100644 index 00000000000..c05568ce510 --- /dev/null +++ b/queue-5.10/btrfs-fix-bitmap-leak-when-loading-free-space-cache-.patch @@ -0,0 +1,39 @@ +From 7586b3f56087629155fc2369544a61b4b25bbe4f 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 4989c60b1df9c..af52c9e005b3c 100644 +--- a/fs/btrfs/free-space-cache.c ++++ b/fs/btrfs/free-space-cache.c +@@ -798,6 +798,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-5.10/clocksource-drivers-sh_cmt-address-race-condition-fo.patch b/queue-5.10/clocksource-drivers-sh_cmt-address-race-condition-fo.patch new file mode 100644 index 00000000000..317f058a39c --- /dev/null +++ b/queue-5.10/clocksource-drivers-sh_cmt-address-race-condition-fo.patch @@ -0,0 +1,144 @@ +From a0623487287a5407606a43360a18ddf76f0729c2 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 66e4872ab34f9..26dbf01d2ec5e 100644 +--- a/drivers/clocksource/sh_cmt.c ++++ b/drivers/clocksource/sh_cmt.c +@@ -530,6 +530,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) & +@@ -560,6 +561,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); +@@ -572,6 +575,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; + } + +@@ -770,12 +775,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-5.10/drm-amdgpu-fix-the-null-pointer-dereference-to-ras_m.patch b/queue-5.10/drm-amdgpu-fix-the-null-pointer-dereference-to-ras_m.patch new file mode 100644 index 00000000000..944e014410f --- /dev/null +++ b/queue-5.10/drm-amdgpu-fix-the-null-pointer-dereference-to-ras_m.patch @@ -0,0 +1,44 @@ +From b485a7af62ee9c6319a8282c6c1b87e5dc959490 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 11 May 2024 15:48:02 +0800 +Subject: drm/amdgpu: Fix the null pointer dereference to ras_manager + +From: Ma Jun + +[ Upstream commit 4c11d30c95576937c6c35e6f29884761f2dddb43 ] + +Check ras_manager before using it + +Signed-off-by: Ma Jun +Reviewed-by: Lijo Lazar +Signed-off-by: Alex Deucher +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 7 +++++-- + 1 file changed, 5 insertions(+), 2 deletions(-) + +diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c +index e971d2b9e3c00..56f10679a26d1 100644 +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c +@@ -1351,12 +1351,15 @@ static void amdgpu_ras_interrupt_process_handler(struct work_struct *work) + int amdgpu_ras_interrupt_dispatch(struct amdgpu_device *adev, + struct ras_dispatch_if *info) + { +- struct ras_manager *obj = amdgpu_ras_find_obj(adev, &info->head); +- struct ras_ih_data *data = &obj->ih_data; ++ struct ras_manager *obj; ++ struct ras_ih_data *data; + ++ obj = amdgpu_ras_find_obj(adev, &info->head); + if (!obj) + return -EINVAL; + ++ data = &obj->ih_data; ++ + if (data->inuse == 0) + return 0; + +-- +2.43.0 + diff --git a/queue-5.10/drm-amdgpu-pm-fix-the-null-pointer-dereference-in-ap.patch b/queue-5.10/drm-amdgpu-pm-fix-the-null-pointer-dereference-in-ap.patch new file mode 100644 index 00000000000..d30ef6d3a5e --- /dev/null +++ b/queue-5.10/drm-amdgpu-pm-fix-the-null-pointer-dereference-in-ap.patch @@ -0,0 +1,105 @@ +From 208a309942013dfebc6302ee5124c5acd3d08ccf Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 9 May 2024 15:51:35 +0800 +Subject: drm/amdgpu/pm: Fix the null pointer dereference in + apply_state_adjust_rules + +From: Ma Jun + +[ Upstream commit d19fb10085a49b77578314f69fff21562f7cd054 ] + +Check the pointer value to fix potential null pointer +dereference + +Acked-by: Yang Wang +Signed-off-by: Ma Jun +Signed-off-by: Alex Deucher +Signed-off-by: Sasha Levin +--- + .../gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c | 7 +++++-- + .../gpu/drm/amd/pm/powerplay/hwmgr/smu8_hwmgr.c | 14 ++++++++------ + .../gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c | 7 +++++-- + 3 files changed, 18 insertions(+), 10 deletions(-) + +diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c +index 7931528bc864b..5e72b7555edae 100644 +--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c ++++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c +@@ -2983,8 +2983,7 @@ static int smu7_apply_state_adjust_rules(struct pp_hwmgr *hwmgr, + const struct pp_power_state *current_ps) + { + struct amdgpu_device *adev = hwmgr->adev; +- struct smu7_power_state *smu7_ps = +- cast_phw_smu7_power_state(&request_ps->hardware); ++ struct smu7_power_state *smu7_ps; + uint32_t sclk; + uint32_t mclk; + struct PP_Clocks minimum_clocks = {0}; +@@ -2998,6 +2997,10 @@ static int smu7_apply_state_adjust_rules(struct pp_hwmgr *hwmgr, + int32_t count; + int32_t stable_pstate_sclk = 0, stable_pstate_mclk = 0; + ++ smu7_ps = cast_phw_smu7_power_state(&request_ps->hardware); ++ if (!smu7_ps) ++ return -EINVAL; ++ + data->battery_state = (PP_StateUILabel_Battery == + request_ps->classification.ui_label); + +diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu8_hwmgr.c b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu8_hwmgr.c +index 35ed47ebaf09d..35d0ff57a5960 100644 +--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu8_hwmgr.c ++++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu8_hwmgr.c +@@ -1051,16 +1051,18 @@ static int smu8_apply_state_adjust_rules(struct pp_hwmgr *hwmgr, + struct pp_power_state *prequest_ps, + const struct pp_power_state *pcurrent_ps) + { +- struct smu8_power_state *smu8_ps = +- cast_smu8_power_state(&prequest_ps->hardware); +- +- const struct smu8_power_state *smu8_current_ps = +- cast_const_smu8_power_state(&pcurrent_ps->hardware); +- ++ struct smu8_power_state *smu8_ps; ++ const struct smu8_power_state *smu8_current_ps; + struct smu8_hwmgr *data = hwmgr->backend; + struct PP_Clocks clocks = {0, 0, 0, 0}; + bool force_high; + ++ smu8_ps = cast_smu8_power_state(&prequest_ps->hardware); ++ smu8_current_ps = cast_const_smu8_power_state(&pcurrent_ps->hardware); ++ ++ if (!smu8_ps || !smu8_current_ps) ++ return -EINVAL; ++ + smu8_ps->need_dfs_bypass = true; + + data->battery_state = (PP_StateUILabel_Battery == prequest_ps->classification.ui_label); +diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c +index 4dc27ec4d012d..10678b5199957 100644 +--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c ++++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c +@@ -3232,8 +3232,7 @@ static int vega10_apply_state_adjust_rules(struct pp_hwmgr *hwmgr, + const struct pp_power_state *current_ps) + { + struct amdgpu_device *adev = hwmgr->adev; +- struct vega10_power_state *vega10_ps = +- cast_phw_vega10_power_state(&request_ps->hardware); ++ struct vega10_power_state *vega10_ps; + uint32_t sclk; + uint32_t mclk; + struct PP_Clocks minimum_clocks = {0}; +@@ -3251,6 +3250,10 @@ static int vega10_apply_state_adjust_rules(struct pp_hwmgr *hwmgr, + uint32_t stable_pstate_sclk = 0, stable_pstate_mclk = 0; + uint32_t latency; + ++ vega10_ps = cast_phw_vega10_power_state(&request_ps->hardware); ++ if (!vega10_ps) ++ return -EINVAL; ++ + data->battery_state = (PP_StateUILabel_Battery == + request_ps->classification.ui_label); + +-- +2.43.0 + diff --git a/queue-5.10/irqchip-mbigen-fix-mbigen-node-address-layout.patch b/queue-5.10/irqchip-mbigen-fix-mbigen-node-address-layout.patch new file mode 100644 index 00000000000..11bb82b7796 --- /dev/null +++ b/queue-5.10/irqchip-mbigen-fix-mbigen-node-address-layout.patch @@ -0,0 +1,89 @@ +From 77088414e8e7f6565b40824199ff068f9bf7de3e 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 ff7627b577726..192950e9909b9 100644 +--- a/drivers/irqchip/irq-mbigen.c ++++ b/drivers/irqchip/irq-mbigen.c +@@ -64,6 +64,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; +@@ -72,8 +86,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, +@@ -88,8 +101,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-5.10/jbd2-avoid-memleak-in-jbd2_journal_write_metadata_bu.patch b/queue-5.10/jbd2-avoid-memleak-in-jbd2_journal_write_metadata_bu.patch new file mode 100644 index 00000000000..d70d80fd749 --- /dev/null +++ b/queue-5.10/jbd2-avoid-memleak-in-jbd2_journal_write_metadata_bu.patch @@ -0,0 +1,37 @@ +From ab3d150de595178b6cd55b6f7a4852a3e2cc9706 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 4ae4b85ea1877..205e6c7c2fd0c 100644 +--- a/fs/jbd2/journal.c ++++ b/fs/jbd2/journal.c +@@ -412,6 +412,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; + } + spin_lock(&jh_in->b_state_lock); +-- +2.43.0 + diff --git a/queue-5.10/l2tp-fix-lockdep-splat.patch b/queue-5.10/l2tp-fix-lockdep-splat.patch new file mode 100644 index 00000000000..3492a338963 --- /dev/null +++ b/queue-5.10/l2tp-fix-lockdep-splat.patch @@ -0,0 +1,216 @@ +From 45dbc74efe44ff2eead96d19944d3b9200bc573d Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 6 Aug 2024 17:06:26 +0100 +Subject: l2tp: fix lockdep splat + +From: James Chapman + +[ Upstream commit 86a41ea9fd79ddb6145cb8ebf5aeafceabca6f7d ] + +When l2tp tunnels use a socket provided by userspace, we can hit +lockdep splats like the below when data is transmitted through another +(unrelated) userspace socket which then gets routed over l2tp. + +This issue was previously discussed here: +https://lore.kernel.org/netdev/87sfialu2n.fsf@cloudflare.com/ + +The solution is to have lockdep treat socket locks of l2tp tunnel +sockets separately than those of standard INET sockets. To do so, use +a different lockdep subclass where lock nesting is possible. + + ============================================ + WARNING: possible recursive locking detected + 6.10.0+ #34 Not tainted + -------------------------------------------- + iperf3/771 is trying to acquire lock: + ffff8881027601d8 (slock-AF_INET/1){+.-.}-{2:2}, at: l2tp_xmit_skb+0x243/0x9d0 + + but task is already holding lock: + ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10 + + other info that might help us debug this: + Possible unsafe locking scenario: + + CPU0 + ---- + lock(slock-AF_INET/1); + lock(slock-AF_INET/1); + + *** DEADLOCK *** + + May be due to missing lock nesting notation + + 10 locks held by iperf3/771: + #0: ffff888102650258 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x1a/0x40 + #1: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0 + #2: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130 + #3: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: process_backlog+0x28b/0x9f0 + #4: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0xf9/0x260 + #5: ffff888102650d98 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1848/0x1e10 + #6: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: __ip_queue_xmit+0x4b/0xbc0 + #7: ffffffff822ac220 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x17a/0x1130 + #8: ffffffff822ac1e0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0xcc/0x1450 + #9: ffff888101f33258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock#2){+...}-{2:2}, at: __dev_queue_xmit+0x513/0x1450 + + stack backtrace: + CPU: 2 UID: 0 PID: 771 Comm: iperf3 Not tainted 6.10.0+ #34 + Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 + Call Trace: + + dump_stack_lvl+0x69/0xa0 + dump_stack+0xc/0x20 + __lock_acquire+0x135d/0x2600 + ? srso_alias_return_thunk+0x5/0xfbef5 + lock_acquire+0xc4/0x2a0 + ? l2tp_xmit_skb+0x243/0x9d0 + ? __skb_checksum+0xa3/0x540 + _raw_spin_lock_nested+0x35/0x50 + ? l2tp_xmit_skb+0x243/0x9d0 + l2tp_xmit_skb+0x243/0x9d0 + l2tp_eth_dev_xmit+0x3c/0xc0 + dev_hard_start_xmit+0x11e/0x420 + sch_direct_xmit+0xc3/0x640 + __dev_queue_xmit+0x61c/0x1450 + ? ip_finish_output2+0xf4c/0x1130 + ip_finish_output2+0x6b6/0x1130 + ? srso_alias_return_thunk+0x5/0xfbef5 + ? __ip_finish_output+0x217/0x380 + ? srso_alias_return_thunk+0x5/0xfbef5 + __ip_finish_output+0x217/0x380 + ip_output+0x99/0x120 + __ip_queue_xmit+0xae4/0xbc0 + ? srso_alias_return_thunk+0x5/0xfbef5 + ? srso_alias_return_thunk+0x5/0xfbef5 + ? tcp_options_write.constprop.0+0xcb/0x3e0 + ip_queue_xmit+0x34/0x40 + __tcp_transmit_skb+0x1625/0x1890 + __tcp_send_ack+0x1b8/0x340 + tcp_send_ack+0x23/0x30 + __tcp_ack_snd_check+0xa8/0x530 + ? srso_alias_return_thunk+0x5/0xfbef5 + tcp_rcv_established+0x412/0xd70 + tcp_v4_do_rcv+0x299/0x420 + tcp_v4_rcv+0x1991/0x1e10 + ip_protocol_deliver_rcu+0x50/0x220 + ip_local_deliver_finish+0x158/0x260 + ip_local_deliver+0xc8/0xe0 + ip_rcv+0xe5/0x1d0 + ? __pfx_ip_rcv+0x10/0x10 + __netif_receive_skb_one_core+0xce/0xe0 + ? process_backlog+0x28b/0x9f0 + __netif_receive_skb+0x34/0xd0 + ? process_backlog+0x28b/0x9f0 + process_backlog+0x2cb/0x9f0 + __napi_poll.constprop.0+0x61/0x280 + net_rx_action+0x332/0x670 + ? srso_alias_return_thunk+0x5/0xfbef5 + ? find_held_lock+0x2b/0x80 + ? srso_alias_return_thunk+0x5/0xfbef5 + ? srso_alias_return_thunk+0x5/0xfbef5 + handle_softirqs+0xda/0x480 + ? __dev_queue_xmit+0xa2c/0x1450 + do_softirq+0xa1/0xd0 + + + __local_bh_enable_ip+0xc8/0xe0 + ? __dev_queue_xmit+0xa2c/0x1450 + __dev_queue_xmit+0xa48/0x1450 + ? ip_finish_output2+0xf4c/0x1130 + ip_finish_output2+0x6b6/0x1130 + ? srso_alias_return_thunk+0x5/0xfbef5 + ? __ip_finish_output+0x217/0x380 + ? srso_alias_return_thunk+0x5/0xfbef5 + __ip_finish_output+0x217/0x380 + ip_output+0x99/0x120 + __ip_queue_xmit+0xae4/0xbc0 + ? srso_alias_return_thunk+0x5/0xfbef5 + ? srso_alias_return_thunk+0x5/0xfbef5 + ? tcp_options_write.constprop.0+0xcb/0x3e0 + ip_queue_xmit+0x34/0x40 + __tcp_transmit_skb+0x1625/0x1890 + tcp_write_xmit+0x766/0x2fb0 + ? __entry_text_end+0x102ba9/0x102bad + ? srso_alias_return_thunk+0x5/0xfbef5 + ? __might_fault+0x74/0xc0 + ? srso_alias_return_thunk+0x5/0xfbef5 + __tcp_push_pending_frames+0x56/0x190 + tcp_push+0x117/0x310 + tcp_sendmsg_locked+0x14c1/0x1740 + tcp_sendmsg+0x28/0x40 + inet_sendmsg+0x5d/0x90 + sock_write_iter+0x242/0x2b0 + vfs_write+0x68d/0x800 + ? __pfx_sock_write_iter+0x10/0x10 + ksys_write+0xc8/0xf0 + __x64_sys_write+0x3d/0x50 + x64_sys_call+0xfaf/0x1f50 + do_syscall_64+0x6d/0x140 + entry_SYSCALL_64_after_hwframe+0x76/0x7e + RIP: 0033:0x7f4d143af992 + Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 e9 01 cc ff ff 41 54 b8 02 00 00 0 + RSP: 002b:00007ffd65032058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 + RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4d143af992 + RDX: 0000000000000025 RSI: 00007f4d143f3bcc RDI: 0000000000000005 + RBP: 00007f4d143f2b28 R08: 0000000000000000 R09: 0000000000000000 + R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4d143f3bcc + R13: 0000000000000005 R14: 0000000000000000 R15: 00007ffd650323f0 + + +Fixes: 0b2c59720e65 ("l2tp: close all race conditions in l2tp_tunnel_register()") +Suggested-by: Eric Dumazet +Reported-by: syzbot+6acef9e0a4d1f46c83d4@syzkaller.appspotmail.com +Closes: https://syzkaller.appspot.com/bug?extid=6acef9e0a4d1f46c83d4 +CC: gnault@redhat.com +CC: cong.wang@bytedance.com +Signed-off-by: James Chapman +Signed-off-by: Tom Parkin +Link: https://patch.msgid.link/20240806160626.1248317-1-jchapman@katalix.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + net/l2tp/l2tp_core.c | 15 +++++++++++++-- + 1 file changed, 13 insertions(+), 2 deletions(-) + +diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c +index a4b793d1b7d76..b6dcfca740c1c 100644 +--- a/net/l2tp/l2tp_core.c ++++ b/net/l2tp/l2tp_core.c +@@ -88,6 +88,11 @@ + /* Default trace flags */ + #define L2TP_DEFAULT_DEBUG_FLAGS 0 + ++#define L2TP_DEPTH_NESTING 2 ++#if L2TP_DEPTH_NESTING == SINGLE_DEPTH_NESTING ++#error "L2TP requires its own lockdep subclass" ++#endif ++ + /* Private data stored for received packets in the skb. + */ + struct l2tp_skb_cb { +@@ -1041,7 +1046,13 @@ static int l2tp_xmit_core(struct l2tp_session *session, struct sk_buff *skb, uns + IPCB(skb)->flags &= ~(IPSKB_XFRM_TUNNEL_SIZE | IPSKB_XFRM_TRANSFORMED | IPSKB_REROUTED); + nf_reset_ct(skb); + +- bh_lock_sock_nested(sk); ++ /* L2TP uses its own lockdep subclass to avoid lockdep splats caused by ++ * nested socket calls on the same lockdep socket class. This can ++ * happen when data from a user socket is routed over l2tp, which uses ++ * another userspace socket. ++ */ ++ spin_lock_nested(&sk->sk_lock.slock, L2TP_DEPTH_NESTING); ++ + if (sock_owned_by_user(sk)) { + kfree_skb(skb); + ret = NET_XMIT_DROP; +@@ -1093,7 +1104,7 @@ static int l2tp_xmit_core(struct l2tp_session *session, struct sk_buff *skb, uns + ret = l2tp_xmit_queue(tunnel, skb, &inet->cork.fl); + + out_unlock: +- bh_unlock_sock(sk); ++ spin_unlock(&sk->sk_lock.slock); + + return ret; + } +-- +2.43.0 + diff --git a/queue-5.10/md-do-not-delete-safemode_timer-in-mddev_suspend.patch b/queue-5.10/md-do-not-delete-safemode_timer-in-mddev_suspend.patch new file mode 100644 index 00000000000..62f05f9404c --- /dev/null +++ b/queue-5.10/md-do-not-delete-safemode_timer-in-mddev_suspend.patch @@ -0,0 +1,48 @@ +From 49f5655707543c79857ed79ac3b4e42bfe104929 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 8 May 2024 17:20:53 +0800 +Subject: md: do not delete safemode_timer in mddev_suspend + +From: Li Nan + +[ Upstream commit a8768a134518e406d41799a3594aeb74e0889cf7 ] + +The deletion of safemode_timer in mddev_suspend() is redundant and +potentially harmful now. If timer is about to be woken up but gets +deleted, 'in_sync' will remain 0 until the next write, causing array +to stay in the 'active' state instead of transitioning to 'clean'. + +Commit 0d9f4f135eb6 ("MD: Add del_timer_sync to mddev_suspend (fix +nasty panic))" introduced this deletion for dm, because if timer fired +after dm is destroyed, the resource which the timer depends on might +have been freed. + +However, commit 0dd84b319352 ("md: call __md_stop_writes in md_stop") +added __md_stop_writes() to md_stop(), which is called before freeing +resource. Timer is deleted in __md_stop_writes(), and the origin issue +is resolved. Therefore, delete safemode_timer can be removed safely now. + +Signed-off-by: Li Nan +Reviewed-by: Yu Kuai +Signed-off-by: Song Liu +Link: https://lore.kernel.org/r/20240508092053.1447930-1-linan666@huaweicloud.com +Signed-off-by: Sasha Levin +--- + drivers/md/md.c | 1 - + 1 file changed, 1 deletion(-) + +diff --git a/drivers/md/md.c b/drivers/md/md.c +index 67ceab4573be4..f1f029243e0cb 100644 +--- a/drivers/md/md.c ++++ b/drivers/md/md.c +@@ -524,7 +524,6 @@ void mddev_suspend(struct mddev *mddev) + clear_bit_unlock(MD_ALLOW_SB_UPDATE, &mddev->flags); + wait_event(mddev->sb_wait, !test_bit(MD_UPDATING_SB, &mddev->flags)); + +- del_timer_sync(&mddev->safemode_timer); + /* restrict memory reclaim I/O during raid array is suspend */ + mddev->noio_flag = memalloc_noio_save(); + } +-- +2.43.0 + diff --git a/queue-5.10/md-raid5-avoid-bug_on-while-continue-reshape-after-r.patch b/queue-5.10/md-raid5-avoid-bug_on-while-continue-reshape-after-r.patch new file mode 100644 index 00000000000..916d5440c1e --- /dev/null +++ b/queue-5.10/md-raid5-avoid-bug_on-while-continue-reshape-after-r.patch @@ -0,0 +1,93 @@ +From 6de17278be23526900a5dc2ac84de0406d2e1926 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 66167c4c7bc9e..7cdc6f20f5043 100644 +--- a/drivers/md/raid5.c ++++ b/drivers/md/raid5.c +@@ -6005,7 +6005,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; +@@ -6023,14 +6025,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-5.10/media-uvcvideo-fix-the-bandwdith-quirk-on-usb-3.x.patch b/queue-5.10/media-uvcvideo-fix-the-bandwdith-quirk-on-usb-3.x.patch new file mode 100644 index 00000000000..818030958f1 --- /dev/null +++ b/queue-5.10/media-uvcvideo-fix-the-bandwdith-quirk-on-usb-3.x.patch @@ -0,0 +1,52 @@ +From 66ce8e0753aa7669e26cb378f3d2effe9c2e11b9 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 9a4c730943a90..288f097e2e6f2 100644 +--- a/drivers/media/usb/uvc/uvc_video.c ++++ b/drivers/media/usb/uvc/uvc_video.c +@@ -207,13 +207,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-5.10/media-uvcvideo-ignore-empty-ts-packets.patch b/queue-5.10/media-uvcvideo-ignore-empty-ts-packets.patch new file mode 100644 index 00000000000..ca74cf039dd --- /dev/null +++ b/queue-5.10/media-uvcvideo-ignore-empty-ts-packets.patch @@ -0,0 +1,129 @@ +From 56daf9335b7b720f6effd84f2a23cc80b2635bc6 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 03dfe96bcebac..9a4c730943a90 100644 +--- a/drivers/media/usb/uvc/uvc_video.c ++++ b/drivers/media/usb/uvc/uvc_video.c +@@ -468,6 +468,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: +@@ -512,6 +513,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); +@@ -549,7 +578,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-5.10/net-dsa-bcm_sf2-fix-a-possible-memory-leak-in-bcm_sf.patch b/queue-5.10/net-dsa-bcm_sf2-fix-a-possible-memory-leak-in-bcm_sf.patch new file mode 100644 index 00000000000..609918a1daa --- /dev/null +++ b/queue-5.10/net-dsa-bcm_sf2-fix-a-possible-memory-leak-in-bcm_sf.patch @@ -0,0 +1,50 @@ +From 94e8ed45c3541ab9d5cd6d81fe4c1bb4c8c4fa90 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 6 Aug 2024 10:13:27 +0900 +Subject: net: dsa: bcm_sf2: Fix a possible memory leak in + bcm_sf2_mdio_register() + +From: Joe Hattori + +[ Upstream commit e3862093ee93fcfbdadcb7957f5f8974fffa806a ] + +bcm_sf2_mdio_register() calls of_phy_find_device() and then +phy_device_remove() in a loop to remove existing PHY devices. +of_phy_find_device() eventually calls bus_find_device(), which calls +get_device() on the returned struct device * to increment the refcount. +The current implementation does not decrement the refcount, which causes +memory leak. + +This commit adds the missing phy_device_free() call to decrement the +refcount via put_device() to balance the refcount. + +Fixes: 771089c2a485 ("net: dsa: bcm_sf2: Ensure that MDIO diversion is used") +Signed-off-by: Joe Hattori +Tested-by: Florian Fainelli +Reviewed-by: Florian Fainelli +Link: https://patch.msgid.link/20240806011327.3817861-1-joe@pf.is.s.u-tokyo.ac.jp +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/dsa/bcm_sf2.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c +index a5849663f65c3..d0f94a5fae5ae 100644 +--- a/drivers/net/dsa/bcm_sf2.c ++++ b/drivers/net/dsa/bcm_sf2.c +@@ -558,8 +558,10 @@ static int bcm_sf2_mdio_register(struct dsa_switch *ds) + of_remove_property(child, prop); + + phydev = of_phy_find_device(child); +- if (phydev) ++ if (phydev) { + phy_device_remove(phydev); ++ phy_device_free(phydev); ++ } + } + + err = mdiobus_register(priv->slave_mii_bus); +-- +2.43.0 + diff --git a/queue-5.10/net-fec-stop-pps-on-driver-remove.patch b/queue-5.10/net-fec-stop-pps-on-driver-remove.patch new file mode 100644 index 00000000000..2afaf07d2b6 --- /dev/null +++ b/queue-5.10/net-fec-stop-pps-on-driver-remove.patch @@ -0,0 +1,46 @@ +From df09d8f6645781c49eba4c004c7ba7c7a76ec849 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 780fbb3e1ed06..84e0855069a84 100644 +--- a/drivers/net/ethernet/freescale/fec_ptp.c ++++ b/drivers/net/ethernet/freescale/fec_ptp.c +@@ -640,6 +640,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-5.10/net-linkwatch-use-system_unbound_wq.patch b/queue-5.10/net-linkwatch-use-system_unbound_wq.patch new file mode 100644 index 00000000000..bcbfe3a5b82 --- /dev/null +++ b/queue-5.10/net-linkwatch-use-system_unbound_wq.patch @@ -0,0 +1,52 @@ +From 5b21740550594df6e945868a28a79b36aa413893 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 1a455847da54f..0311d4d309e1b 100644 +--- a/net/core/link_watch.c ++++ b/net/core/link_watch.c +@@ -138,9 +138,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-5.10/net-usb-qmi_wwan-fix-memory-leak-for-not-ip-packets.patch b/queue-5.10/net-usb-qmi_wwan-fix-memory-leak-for-not-ip-packets.patch new file mode 100644 index 00000000000..5ededa00054 --- /dev/null +++ b/queue-5.10/net-usb-qmi_wwan-fix-memory-leak-for-not-ip-packets.patch @@ -0,0 +1,38 @@ +From 697a0a77a7834dd68e5524179874c9b5370aff64 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 d2a8238e144a6..47cc54a64b56d 100644 +--- a/drivers/net/usb/qmi_wwan.c ++++ b/drivers/net/usb/qmi_wwan.c +@@ -216,6 +216,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-5.10/pci-add-edimax-vendor-id-to-pci_ids.h.patch b/queue-5.10/pci-add-edimax-vendor-id-to-pci_ids.h.patch new file mode 100644 index 00000000000..f504830c1e7 --- /dev/null +++ b/queue-5.10/pci-add-edimax-vendor-id-to-pci_ids.h.patch @@ -0,0 +1,38 @@ +From 4afa4d41b08c67e65b42948271324d4abf3afab6 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 80744a7b5e333..b2418bfda4a98 100644 +--- a/include/linux/pci_ids.h ++++ b/include/linux/pci_ids.h +@@ -2137,6 +2137,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-5.10/r8169-remove-detection-of-chip-version-11-early-rtl8.patch b/queue-5.10/r8169-remove-detection-of-chip-version-11-early-rtl8.patch new file mode 100644 index 00000000000..c4e305b4401 --- /dev/null +++ b/queue-5.10/r8169-remove-detection-of-chip-version-11-early-rtl8.patch @@ -0,0 +1,41 @@ +From 1c40610b961f8a4ddc71c0b9849e67434ac633fb Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 27 May 2024 21:20:16 +0200 +Subject: r8169: remove detection of chip version 11 (early RTL8168b) + +From: Heiner Kallweit + +[ Upstream commit 982300c115d229565d7af8e8b38aa1ee7bb1f5bd ] + +This early RTL8168b version was the first PCIe chip version, and it's +quite quirky. Last sign of life is from more than 15 yrs ago. +Let's remove detection of this chip version, we'll see whether anybody +complains. If not, support for this chip version can be removed a few +kernel versions later. + +Signed-off-by: Heiner Kallweit +Link: https://lore.kernel.org/r/875cdcf4-843c-420a-ad5d-417447b68572@gmail.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/realtek/r8169_main.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c +index 4c588fc43eb9b..76fe940aec122 100644 +--- a/drivers/net/ethernet/realtek/r8169_main.c ++++ b/drivers/net/ethernet/realtek/r8169_main.c +@@ -2018,7 +2018,9 @@ static enum mac_version rtl8169_get_mac_version(u16 xid, bool gmii) + /* 8168B family. */ + { 0x7cf, 0x380, RTL_GIGA_MAC_VER_12 }, + { 0x7c8, 0x380, RTL_GIGA_MAC_VER_17 }, +- { 0x7c8, 0x300, RTL_GIGA_MAC_VER_11 }, ++ /* This one is very old and rare, let's see if anybody complains. ++ * { 0x7c8, 0x300, RTL_GIGA_MAC_VER_11 }, ++ */ + + /* 8101 family. */ + { 0x7c8, 0x448, RTL_GIGA_MAC_VER_39 }, +-- +2.43.0 + diff --git a/queue-5.10/rcutorture-fix-rcu_torture_fwd_cb_cr-data-race.patch b/queue-5.10/rcutorture-fix-rcu_torture_fwd_cb_cr-data-race.patch new file mode 100644 index 00000000000..3eb19a0e480 --- /dev/null +++ b/queue-5.10/rcutorture-fix-rcu_torture_fwd_cb_cr-data-race.patch @@ -0,0 +1,50 @@ +From 54764d35149404ce9ae766237800cf6fd1870f39 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 5 Apr 2024 12:02:11 -0700 +Subject: rcutorture: Fix rcu_torture_fwd_cb_cr() data race + +From: Paul E. McKenney + +[ Upstream commit 6040072f4774a575fa67b912efe7722874be337b ] + +On powerpc systems, spinlock acquisition does not order prior stores +against later loads. This means that this statement: + + rfcp->rfc_next = NULL; + +Can be reordered to follow this statement: + + WRITE_ONCE(*rfcpp, rfcp); + +Which is then a data race with rcu_torture_fwd_prog_cr(), specifically, +this statement: + + rfcpn = READ_ONCE(rfcp->rfc_next) + +KCSAN located this data race, which represents a real failure on powerpc. + +Signed-off-by: Paul E. McKenney +Acked-by: Marco Elver +Cc: Andrey Konovalov +Cc: +Signed-off-by: Sasha Levin +--- + kernel/rcu/rcutorture.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c +index 9f505688291e5..5c4bdbe76df04 100644 +--- a/kernel/rcu/rcutorture.c ++++ b/kernel/rcu/rcutorture.c +@@ -1867,7 +1867,7 @@ static void rcu_torture_fwd_cb_cr(struct rcu_head *rhp) + spin_lock_irqsave(&rfp->rcu_fwd_lock, flags); + rfcpp = rfp->rcu_fwd_cb_tail; + rfp->rcu_fwd_cb_tail = &rfcp->rfc_next; +- WRITE_ONCE(*rfcpp, rfcp); ++ smp_store_release(rfcpp, rfcp); + WRITE_ONCE(rfp->n_launders_cb, rfp->n_launders_cb + 1); + i = ((jiffies - rfp->rcu_fwd_startat) / (HZ / FWD_CBS_HIST_DIV)); + if (i >= ARRAY_SIZE(rfp->n_launders_hist)) +-- +2.43.0 + diff --git a/queue-5.10/s390-sclp-prevent-release-of-buffer-in-i-o.patch b/queue-5.10/s390-sclp-prevent-release-of-buffer-in-i-o.patch new file mode 100644 index 00000000000..2480e1c424f --- /dev/null +++ b/queue-5.10/s390-sclp-prevent-release-of-buffer-in-i-o.patch @@ -0,0 +1,52 @@ +From 32445ad329e50b57985376a9399a870537f32eee 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-5.10/sctp-fix-null-ptr-deref-in-reuseport_add_sock.patch b/queue-5.10/sctp-fix-null-ptr-deref-in-reuseport_add_sock.patch new file mode 100644 index 00000000000..694c66c43a8 --- /dev/null +++ b/queue-5.10/sctp-fix-null-ptr-deref-in-reuseport_add_sock.patch @@ -0,0 +1,169 @@ +From acbbc079ade092561ec0a20faa0439282b423dc2 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 31 Jul 2024 16:46:24 -0700 +Subject: sctp: Fix null-ptr-deref in reuseport_add_sock(). + +From: Kuniyuki Iwashima + +[ Upstream commit 9ab0faa7f9ffe31296dbb9bbe6f76c72c14eea18 ] + +syzbot reported a null-ptr-deref while accessing sk2->sk_reuseport_cb in +reuseport_add_sock(). [0] + +The repro first creates a listener with SO_REUSEPORT. Then, it creates +another listener on the same port and concurrently closes the first +listener. + +The second listen() calls reuseport_add_sock() with the first listener as +sk2, where sk2->sk_reuseport_cb is not expected to be cleared concurrently, +but the close() does clear it by reuseport_detach_sock(). + +The problem is SCTP does not properly synchronise reuseport_alloc(), +reuseport_add_sock(), and reuseport_detach_sock(). + +The caller of reuseport_alloc() and reuseport_{add,detach}_sock() must +provide synchronisation for sockets that are classified into the same +reuseport group. + +Otherwise, such sockets form multiple identical reuseport groups, and +all groups except one would be silently dead. + + 1. Two sockets call listen() concurrently + 2. No socket in the same group found in sctp_ep_hashtable[] + 3. Two sockets call reuseport_alloc() and form two reuseport groups + 4. Only one group hit first in __sctp_rcv_lookup_endpoint() receives + incoming packets + +Also, the reported null-ptr-deref could occur. + +TCP/UDP guarantees that would not happen by holding the hash bucket lock. + +Let's apply the locking strategy to __sctp_hash_endpoint() and +__sctp_unhash_endpoint(). + +[0]: +Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI +KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] +CPU: 1 UID: 0 PID: 10230 Comm: syz-executor119 Not tainted 6.10.0-syzkaller-12585-g301927d2d2eb #0 +Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 +RIP: 0010:reuseport_add_sock+0x27e/0x5e0 net/core/sock_reuseport.c:350 +Code: 00 0f b7 5d 00 bf 01 00 00 00 89 de e8 1b a4 ff f7 83 fb 01 0f 85 a3 01 00 00 e8 6d a0 ff f7 49 8d 7e 12 48 89 f8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 0f 85 4b 02 00 00 41 0f b7 5e 12 49 8d 7e 14 +RSP: 0018:ffffc9000b947c98 EFLAGS: 00010202 +RAX: 0000000000000002 RBX: ffff8880252ddf98 RCX: ffff888079478000 +RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000012 +RBP: 0000000000000001 R08: ffffffff8993e18d R09: 1ffffffff1fef385 +R10: dffffc0000000000 R11: fffffbfff1fef386 R12: ffff8880252ddac0 +R13: dffffc0000000000 R14: 0000000000000000 R15: 0000000000000000 +FS: 00007f24e45b96c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 +CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +CR2: 00007ffcced5f7b8 CR3: 00000000241be000 CR4: 00000000003506f0 +DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 + DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +Call Trace: + + __sctp_hash_endpoint net/sctp/input.c:762 [inline] + sctp_hash_endpoint+0x52a/0x600 net/sctp/input.c:790 + sctp_listen_start net/sctp/socket.c:8570 [inline] + sctp_inet_listen+0x767/0xa20 net/sctp/socket.c:8625 + __sys_listen_socket net/socket.c:1883 [inline] + __sys_listen+0x1b7/0x230 net/socket.c:1894 + __do_sys_listen net/socket.c:1902 [inline] + __se_sys_listen net/socket.c:1900 [inline] + __x64_sys_listen+0x5a/0x70 net/socket.c:1900 + do_syscall_x64 arch/x86/entry/common.c:52 [inline] + do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 + entry_SYSCALL_64_after_hwframe+0x77/0x7f +RIP: 0033:0x7f24e46039b9 +Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 1a 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 +RSP: 002b:00007f24e45b9228 EFLAGS: 00000246 ORIG_RAX: 0000000000000032 +RAX: ffffffffffffffda RBX: 00007f24e468e428 RCX: 00007f24e46039b9 +RDX: 00007f24e46039b9 RSI: 0000000000000003 RDI: 0000000000000004 +RBP: 00007f24e468e420 R08: 00007f24e45b96c0 R09: 00007f24e45b96c0 +R10: 00007f24e45b96c0 R11: 0000000000000246 R12: 00007f24e468e42c +R13: 00007f24e465a5dc R14: 0020000000000001 R15: 00007ffcced5f7d8 + +Modules linked in: + +Fixes: 6ba845740267 ("sctp: process sk_reuseport in sctp_get_port_local") +Reported-by: syzbot+e6979a5d2f10ecb700e4@syzkaller.appspotmail.com +Closes: https://syzkaller.appspot.com/bug?extid=e6979a5d2f10ecb700e4 +Tested-by: syzbot+e6979a5d2f10ecb700e4@syzkaller.appspotmail.com +Signed-off-by: Kuniyuki Iwashima +Acked-by: Xin Long +Link: https://patch.msgid.link/20240731234624.94055-1-kuniyu@amazon.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + net/sctp/input.c | 19 +++++++++++-------- + 1 file changed, 11 insertions(+), 8 deletions(-) + +diff --git a/net/sctp/input.c b/net/sctp/input.c +index 17df756418eae..8fe1a74f0618d 100644 +--- a/net/sctp/input.c ++++ b/net/sctp/input.c +@@ -723,15 +723,19 @@ static int __sctp_hash_endpoint(struct sctp_endpoint *ep) + struct sock *sk = ep->base.sk; + struct net *net = sock_net(sk); + struct sctp_hashbucket *head; ++ int err = 0; + + ep->hashent = sctp_ep_hashfn(net, ep->base.bind_addr.port); + head = &sctp_ep_hashtable[ep->hashent]; + ++ write_lock(&head->lock); + if (sk->sk_reuseport) { + bool any = sctp_is_ep_boundall(sk); + struct sctp_endpoint *ep2; + struct list_head *list; +- int cnt = 0, err = 1; ++ int cnt = 0; ++ ++ err = 1; + + list_for_each(list, &ep->base.bind_addr.address_list) + cnt++; +@@ -749,24 +753,24 @@ static int __sctp_hash_endpoint(struct sctp_endpoint *ep) + if (!err) { + err = reuseport_add_sock(sk, sk2, any); + if (err) +- return err; ++ goto out; + break; + } else if (err < 0) { +- return err; ++ goto out; + } + } + + if (err) { + err = reuseport_alloc(sk, any); + if (err) +- return err; ++ goto out; + } + } + +- write_lock(&head->lock); + hlist_add_head(&ep->node, &head->chain); ++out: + write_unlock(&head->lock); +- return 0; ++ return err; + } + + /* Add an endpoint to the hash. Local BH-safe. */ +@@ -791,10 +795,9 @@ static void __sctp_unhash_endpoint(struct sctp_endpoint *ep) + + head = &sctp_ep_hashtable[ep->hashent]; + ++ write_lock(&head->lock); + if (rcu_access_pointer(sk->sk_reuseport_cb)) + reuseport_detach_sock(sk); +- +- write_lock(&head->lock); + hlist_del_init(&ep->node); + write_unlock(&head->lock); + } +-- +2.43.0 + diff --git a/queue-5.10/sctp-move-hlist_node-and-hashent-out-of-sctp_ep_comm.patch b/queue-5.10/sctp-move-hlist_node-and-hashent-out-of-sctp_ep_comm.patch new file mode 100644 index 00000000000..e79599450a4 --- /dev/null +++ b/queue-5.10/sctp-move-hlist_node-and-hashent-out-of-sctp_ep_comm.patch @@ -0,0 +1,212 @@ +From b54713acb7220f8795e34cd1e6b021d98674b4be Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 21 Dec 2021 16:40:30 -0500 +Subject: sctp: move hlist_node and hashent out of sctp_ep_common + +From: Xin Long + +[ Upstream commit 3d3b2f57d4447e6e9f4096ad01d0e4129f7bc7e9 ] + +Struct sctp_ep_common is included in both asoc and ep, but hlist_node +and hashent are only needed by ep after asoc_hashtable was dropped by +Commit b5eff7128366 ("sctp: drop the old assoc hashtable of sctp"). + +So it is better to move hlist_node and hashent from sctp_ep_common to +sctp_endpoint, and it saves some space for each asoc. + +Signed-off-by: Xin Long +Signed-off-by: David S. Miller +Stable-dep-of: 9ab0faa7f9ff ("sctp: Fix null-ptr-deref in reuseport_add_sock().") +Signed-off-by: Sasha Levin +--- + include/net/sctp/sctp.h | 4 ++-- + include/net/sctp/structs.h | 8 ++++---- + net/sctp/input.c | 27 ++++++++++----------------- + net/sctp/proc.c | 10 ++++------ + net/sctp/socket.c | 6 +++--- + 5 files changed, 23 insertions(+), 32 deletions(-) + +diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h +index 33475d061823e..6d89a7f3f6a4c 100644 +--- a/include/net/sctp/sctp.h ++++ b/include/net/sctp/sctp.h +@@ -506,8 +506,8 @@ static inline int sctp_ep_hashfn(struct net *net, __u16 lport) + return (net_hash_mix(net) + lport) & (sctp_ep_hashsize - 1); + } + +-#define sctp_for_each_hentry(epb, head) \ +- hlist_for_each_entry(epb, head, node) ++#define sctp_for_each_hentry(ep, head) \ ++ hlist_for_each_entry(ep, head, node) + + /* Is a socket of this style? */ + #define sctp_style(sk, style) __sctp_style((sk), (SCTP_SOCKET_##style)) +diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h +index be59e8df0bffc..108eb62cdc2c5 100644 +--- a/include/net/sctp/structs.h ++++ b/include/net/sctp/structs.h +@@ -1218,10 +1218,6 @@ enum sctp_endpoint_type { + */ + + struct sctp_ep_common { +- /* Fields to help us manage our entries in the hash tables. */ +- struct hlist_node node; +- int hashent; +- + /* Runtime type information. What kind of endpoint is this? */ + enum sctp_endpoint_type type; + +@@ -1273,6 +1269,10 @@ struct sctp_endpoint { + /* Common substructure for endpoint and association. */ + struct sctp_ep_common base; + ++ /* Fields to help us manage our entries in the hash tables. */ ++ struct hlist_node node; ++ int hashent; ++ + /* Associations: A list of current associations and mappings + * to the data consumers for each association. This + * may be in the form of a hash table or other +diff --git a/net/sctp/input.c b/net/sctp/input.c +index 8f3aab6a4458b..17df756418eae 100644 +--- a/net/sctp/input.c ++++ b/net/sctp/input.c +@@ -723,23 +723,21 @@ static int __sctp_hash_endpoint(struct sctp_endpoint *ep) + struct sock *sk = ep->base.sk; + struct net *net = sock_net(sk); + struct sctp_hashbucket *head; +- struct sctp_ep_common *epb; + +- epb = &ep->base; +- epb->hashent = sctp_ep_hashfn(net, epb->bind_addr.port); +- head = &sctp_ep_hashtable[epb->hashent]; ++ ep->hashent = sctp_ep_hashfn(net, ep->base.bind_addr.port); ++ head = &sctp_ep_hashtable[ep->hashent]; + + if (sk->sk_reuseport) { + bool any = sctp_is_ep_boundall(sk); +- struct sctp_ep_common *epb2; ++ struct sctp_endpoint *ep2; + struct list_head *list; + int cnt = 0, err = 1; + + list_for_each(list, &ep->base.bind_addr.address_list) + cnt++; + +- sctp_for_each_hentry(epb2, &head->chain) { +- struct sock *sk2 = epb2->sk; ++ sctp_for_each_hentry(ep2, &head->chain) { ++ struct sock *sk2 = ep2->base.sk; + + if (!net_eq(sock_net(sk2), net) || sk2 == sk || + !uid_eq(sock_i_uid(sk2), sock_i_uid(sk)) || +@@ -766,7 +764,7 @@ static int __sctp_hash_endpoint(struct sctp_endpoint *ep) + } + + write_lock(&head->lock); +- hlist_add_head(&epb->node, &head->chain); ++ hlist_add_head(&ep->node, &head->chain); + write_unlock(&head->lock); + return 0; + } +@@ -788,19 +786,16 @@ static void __sctp_unhash_endpoint(struct sctp_endpoint *ep) + { + struct sock *sk = ep->base.sk; + struct sctp_hashbucket *head; +- struct sctp_ep_common *epb; + +- epb = &ep->base; ++ ep->hashent = sctp_ep_hashfn(sock_net(sk), ep->base.bind_addr.port); + +- epb->hashent = sctp_ep_hashfn(sock_net(sk), epb->bind_addr.port); +- +- head = &sctp_ep_hashtable[epb->hashent]; ++ head = &sctp_ep_hashtable[ep->hashent]; + + if (rcu_access_pointer(sk->sk_reuseport_cb)) + reuseport_detach_sock(sk); + + write_lock(&head->lock); +- hlist_del_init(&epb->node); ++ hlist_del_init(&ep->node); + write_unlock(&head->lock); + } + +@@ -833,7 +828,6 @@ static struct sctp_endpoint *__sctp_rcv_lookup_endpoint( + const union sctp_addr *paddr) + { + struct sctp_hashbucket *head; +- struct sctp_ep_common *epb; + struct sctp_endpoint *ep; + struct sock *sk; + __be16 lport; +@@ -843,8 +837,7 @@ static struct sctp_endpoint *__sctp_rcv_lookup_endpoint( + hash = sctp_ep_hashfn(net, ntohs(lport)); + head = &sctp_ep_hashtable[hash]; + read_lock(&head->lock); +- sctp_for_each_hentry(epb, &head->chain) { +- ep = sctp_ep(epb); ++ sctp_for_each_hentry(ep, &head->chain) { + if (sctp_endpoint_is_match(ep, net, laddr)) + goto hit; + } +diff --git a/net/sctp/proc.c b/net/sctp/proc.c +index 963b94517ec20..ec00ee75d59a6 100644 +--- a/net/sctp/proc.c ++++ b/net/sctp/proc.c +@@ -161,7 +161,6 @@ static void *sctp_eps_seq_next(struct seq_file *seq, void *v, loff_t *pos) + static int sctp_eps_seq_show(struct seq_file *seq, void *v) + { + struct sctp_hashbucket *head; +- struct sctp_ep_common *epb; + struct sctp_endpoint *ep; + struct sock *sk; + int hash = *(loff_t *)v; +@@ -171,18 +170,17 @@ static int sctp_eps_seq_show(struct seq_file *seq, void *v) + + head = &sctp_ep_hashtable[hash]; + read_lock_bh(&head->lock); +- sctp_for_each_hentry(epb, &head->chain) { +- ep = sctp_ep(epb); +- sk = epb->sk; ++ sctp_for_each_hentry(ep, &head->chain) { ++ sk = ep->base.sk; + if (!net_eq(sock_net(sk), seq_file_net(seq))) + continue; + seq_printf(seq, "%8pK %8pK %-3d %-3d %-4d %-5d %5u %5lu ", ep, sk, + sctp_sk(sk)->type, sk->sk_state, hash, +- epb->bind_addr.port, ++ ep->base.bind_addr.port, + from_kuid_munged(seq_user_ns(seq), sock_i_uid(sk)), + sock_i_ino(sk)); + +- sctp_seq_dump_local_addrs(seq, epb); ++ sctp_seq_dump_local_addrs(seq, &ep->base); + seq_printf(seq, "\n"); + } + read_unlock_bh(&head->lock); +diff --git a/net/sctp/socket.c b/net/sctp/socket.c +index 79cf4cda2cf6d..5053d813e91cf 100644 +--- a/net/sctp/socket.c ++++ b/net/sctp/socket.c +@@ -5193,14 +5193,14 @@ int sctp_for_each_endpoint(int (*cb)(struct sctp_endpoint *, void *), + void *p) { + int err = 0; + int hash = 0; +- struct sctp_ep_common *epb; ++ struct sctp_endpoint *ep; + struct sctp_hashbucket *head; + + for (head = sctp_ep_hashtable; hash < sctp_ep_hashsize; + hash++, head++) { + read_lock_bh(&head->lock); +- sctp_for_each_hentry(epb, &head->chain) { +- err = cb(sctp_ep(epb), p); ++ sctp_for_each_hentry(ep, &head->chain) { ++ err = cb(ep, p); + if (err) + break; + } +-- +2.43.0 + diff --git a/queue-5.10/selftests-bpf-fix-send_signal-test-with-nested-confi.patch b/queue-5.10/selftests-bpf-fix-send_signal-test-with-nested-confi.patch new file mode 100644 index 00000000000..9abb32763e0 --- /dev/null +++ b/queue-5.10/selftests-bpf-fix-send_signal-test-with-nested-confi.patch @@ -0,0 +1,120 @@ +From d1ca8c40061b3b612e8cd77306110d40647e3497 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 5 Jun 2024 13:12:03 -0700 +Subject: selftests/bpf: Fix send_signal test with nested CONFIG_PARAVIRT + +From: Yonghong Song + +[ Upstream commit 7015843afcaf68c132784c89528dfddc0005e483 ] + +Alexei reported that send_signal test may fail with nested CONFIG_PARAVIRT +configs. In this particular case, the base VM is AMD with 166 cpus, and I +run selftests with regular qemu on top of that and indeed send_signal test +failed. I also tried with an Intel box with 80 cpus and there is no issue. + +The main qemu command line includes: + + -enable-kvm -smp 16 -cpu host + +The failure log looks like: + + $ ./test_progs -t send_signal + [ 48.501588] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [test_progs:2225] + [ 48.503622] Modules linked in: bpf_testmod(O) + [ 48.503622] CPU: 9 PID: 2225 Comm: test_progs Tainted: G O 6.9.0-08561-g2c1713a8f1c9-dirty #69 + [ 48.507629] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 + [ 48.511635] RIP: 0010:handle_softirqs+0x71/0x290 + [ 48.511635] Code: [...] 10 0a 00 00 00 31 c0 65 66 89 05 d5 f4 fa 7e fb bb ff ff ff ff <49> c7 c2 cb + [ 48.518527] RSP: 0018:ffffc90000310fa0 EFLAGS: 00000246 + [ 48.519579] RAX: 0000000000000000 RBX: 00000000ffffffff RCX: 00000000000006e0 + [ 48.522526] RDX: 0000000000000006 RSI: ffff88810791ae80 RDI: 0000000000000000 + [ 48.523587] RBP: ffffc90000fabc88 R08: 00000005a0af4f7f R09: 0000000000000000 + [ 48.525525] R10: 0000000561d2f29c R11: 0000000000006534 R12: 0000000000000280 + [ 48.528525] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 + [ 48.528525] FS: 00007f2f2885cd00(0000) GS:ffff888237c40000(0000) knlGS:0000000000000000 + [ 48.531600] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 + [ 48.535520] CR2: 00007f2f287059f0 CR3: 0000000106a28002 CR4: 00000000003706f0 + [ 48.537538] Call Trace: + [ 48.537538] + [ 48.537538] ? watchdog_timer_fn+0x1cd/0x250 + [ 48.539590] ? lockup_detector_update_enable+0x50/0x50 + [ 48.539590] ? __hrtimer_run_queues+0xff/0x280 + [ 48.542520] ? hrtimer_interrupt+0x103/0x230 + [ 48.544524] ? __sysvec_apic_timer_interrupt+0x4f/0x140 + [ 48.545522] ? sysvec_apic_timer_interrupt+0x3a/0x90 + [ 48.547612] ? asm_sysvec_apic_timer_interrupt+0x1a/0x20 + [ 48.547612] ? handle_softirqs+0x71/0x290 + [ 48.547612] irq_exit_rcu+0x63/0x80 + [ 48.551585] sysvec_apic_timer_interrupt+0x75/0x90 + [ 48.552521] + [ 48.553529] + [ 48.553529] asm_sysvec_apic_timer_interrupt+0x1a/0x20 + [ 48.555609] RIP: 0010:finish_task_switch.isra.0+0x90/0x260 + [ 48.556526] Code: [...] 9f 58 0a 00 00 48 85 db 0f 85 89 01 00 00 4c 89 ff e8 53 d9 bd 00 fb 66 90 <4d> 85 ed 74 + [ 48.562524] RSP: 0018:ffffc90000fabd38 EFLAGS: 00000282 + [ 48.563589] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83385620 + [ 48.563589] RDX: ffff888237c73ae4 RSI: 0000000000000000 RDI: ffff888237c6fd00 + [ 48.568521] RBP: ffffc90000fabd68 R08: 0000000000000000 R09: 0000000000000000 + [ 48.569528] R10: 0000000000000001 R11: 0000000000000000 R12: ffff8881009d0000 + [ 48.573525] R13: ffff8881024e5400 R14: ffff88810791ae80 R15: ffff888237c6fd00 + [ 48.575614] ? finish_task_switch.isra.0+0x8d/0x260 + [ 48.576523] __schedule+0x364/0xac0 + [ 48.577535] schedule+0x2e/0x110 + [ 48.578555] pipe_read+0x301/0x400 + [ 48.579589] ? destroy_sched_domains_rcu+0x30/0x30 + [ 48.579589] vfs_read+0x2b3/0x2f0 + [ 48.579589] ksys_read+0x8b/0xc0 + [ 48.583590] do_syscall_64+0x3d/0xc0 + [ 48.583590] entry_SYSCALL_64_after_hwframe+0x4b/0x53 + [ 48.586525] RIP: 0033:0x7f2f28703fa1 + [ 48.587592] Code: [...] 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 80 3d c5 23 14 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 + [ 48.593534] RSP: 002b:00007ffd90f8cf88 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 + [ 48.595589] RAX: ffffffffffffffda RBX: 00007ffd90f8d5e8 RCX: 00007f2f28703fa1 + [ 48.595589] RDX: 0000000000000001 RSI: 00007ffd90f8cfb0 RDI: 0000000000000006 + [ 48.599592] RBP: 00007ffd90f8d2f0 R08: 0000000000000064 R09: 0000000000000000 + [ 48.602527] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 + [ 48.603589] R13: 00007ffd90f8d608 R14: 00007f2f288d8000 R15: 0000000000f6bdb0 + [ 48.605527] + +In the test, two processes are communicating through pipe. Further debugging +with strace found that the above splat is triggered as read() syscall could +not receive the data even if the corresponding write() syscall in another +process successfully wrote data into the pipe. + +The failed subtest is "send_signal_perf". The corresponding perf event has +sample_period 1 and config PERF_COUNT_SW_CPU_CLOCK. sample_period 1 means every +overflow event will trigger a call to the BPF program. So I suspect this may +overwhelm the system. So I increased the sample_period to 100,000 and the test +passed. The sample_period 10,000 still has the test failed. + +In other parts of selftest, e.g., [1], sample_freq is used instead. So I +decided to use sample_freq = 1,000 since the test can pass as well. + + [1] https://lore.kernel.org/bpf/20240604070700.3032142-1-song@kernel.org/ + +Reported-by: Alexei Starovoitov +Signed-off-by: Yonghong Song +Signed-off-by: Daniel Borkmann +Link: https://lore.kernel.org/bpf/20240605201203.2603846-1-yonghong.song@linux.dev +Signed-off-by: Sasha Levin +--- + tools/testing/selftests/bpf/prog_tests/send_signal.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/tools/testing/selftests/bpf/prog_tests/send_signal.c b/tools/testing/selftests/bpf/prog_tests/send_signal.c +index 75b72c751772b..0b6349070824b 100644 +--- a/tools/testing/selftests/bpf/prog_tests/send_signal.c ++++ b/tools/testing/selftests/bpf/prog_tests/send_signal.c +@@ -155,7 +155,8 @@ static void test_send_signal_tracepoint(bool signal_thread) + static void test_send_signal_perf(bool signal_thread) + { + struct perf_event_attr attr = { +- .sample_period = 1, ++ .freq = 1, ++ .sample_freq = 1000, + .type = PERF_TYPE_SOFTWARE, + .config = PERF_COUNT_SW_CPU_CLOCK, + }; +-- +2.43.0 + diff --git a/queue-5.10/series b/queue-5.10/series index fb8bb074aa8..f54adfd17b2 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -258,3 +258,33 @@ r8169-don-t-increment-tx_dropped-in-case-of-netdev_tx_busy.patch mptcp-fix-duplicate-data-handling.patch netfilter-ipset-add-list-flush-to-cancel_gc.patch genirq-allow-irq_chip-registration-functions-to-take.patch +irqchip-mbigen-fix-mbigen-node-address-layout.patch +x86-mm-fix-pti_clone_pgtable-alignment-assumption.patch +x86-mm-fix-pti_clone_entry_text-for-i386.patch +sctp-move-hlist_node-and-hashent-out-of-sctp_ep_comm.patch +sctp-fix-null-ptr-deref-in-reuseport_add_sock.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-dsa-bcm_sf2-fix-a-possible-memory-leak-in-bcm_sf.patch +l2tp-fix-lockdep-splat.patch +net-fec-stop-pps-on-driver-remove.patch +rcutorture-fix-rcu_torture_fwd_cb_cr-data-race.patch +md-do-not-delete-safemode_timer-in-mddev_suspend.patch +md-raid5-avoid-bug_on-while-continue-reshape-after-r.patch +clocksource-drivers-sh_cmt-address-race-condition-fo.patch +acpi-battery-create-alarm-sysfs-attribute-atomically.patch +acpi-sbs-manage-alarm-sysfs-attribute-through-psy-co.patch +r8169-remove-detection-of-chip-version-11-early-rtl8.patch +selftests-bpf-fix-send_signal-test-with-nested-confi.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 +drm-amdgpu-fix-the-null-pointer-dereference-to-ras_m.patch +drm-amdgpu-pm-fix-the-null-pointer-dereference-in-ap.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-5.10/sunrpc-fix-a-race-to-wake-a-sync-task.patch b/queue-5.10/sunrpc-fix-a-race-to-wake-a-sync-task.patch new file mode 100644 index 00000000000..c1e38e9845b --- /dev/null +++ b/queue-5.10/sunrpc-fix-a-race-to-wake-a-sync-task.patch @@ -0,0 +1,53 @@ +From 50b91acb644c39081ddb1ea1392d0c7e78a8e57e 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 a4c9d410eb8d5..f4b1b7fee2c05 100644 +--- a/net/sunrpc/sched.c ++++ b/net/sunrpc/sched.c +@@ -348,8 +348,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-5.10/udf-prevent-integer-overflow-in-udf_bitmap_free_bloc.patch b/queue-5.10/udf-prevent-integer-overflow-in-udf_bitmap_free_bloc.patch new file mode 100644 index 00000000000..9bdc95100b0 --- /dev/null +++ b/queue-5.10/udf-prevent-integer-overflow-in-udf_bitmap_free_bloc.patch @@ -0,0 +1,113 @@ +From 492d45ef5f42d2618f23f321341698e8f3b4f7f7 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 c4c18eeacb60c..aa73ab1b50a52 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" +@@ -144,7 +145,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; +@@ -153,19 +153,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); +@@ -395,7 +385,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; +@@ -404,16 +393,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); + +@@ -688,6 +667,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-5.10/wifi-nl80211-don-t-give-key-data-to-userspace.patch b/queue-5.10/wifi-nl80211-don-t-give-key-data-to-userspace.patch new file mode 100644 index 00000000000..0f784821661 --- /dev/null +++ b/queue-5.10/wifi-nl80211-don-t-give-key-data-to-userspace.patch @@ -0,0 +1,55 @@ +From fa78fee31731d98a0b035d189d737d4f428839e6 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 846e40dc00bb6..f9ad7de710cb4 100644 +--- a/net/wireless/nl80211.c ++++ b/net/wireless/nl80211.c +@@ -3968,10 +3968,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 && +@@ -3983,10 +3980,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-5.10/x86-mm-fix-pti_clone_entry_text-for-i386.patch b/queue-5.10/x86-mm-fix-pti_clone_entry_text-for-i386.patch new file mode 100644 index 00000000000..2722b4c3506 --- /dev/null +++ b/queue-5.10/x86-mm-fix-pti_clone_entry_text-for-i386.patch @@ -0,0 +1,42 @@ +From aef449f30c87ac1e0b5e3ac6b94323c70d6fd0a8 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 1 Aug 2024 12:42:25 +0200 +Subject: x86/mm: Fix pti_clone_entry_text() for i386 + +From: Peter Zijlstra + +[ Upstream commit 3db03fb4995ef85fc41e86262ead7b4852f4bcf0 ] + +While x86_64 has PMD aligned text sections, i386 does not have this +luxery. Notably ALIGN_ENTRY_TEXT_END is empty and _etext has PAGE +alignment. + +This means that text on i386 can be page granular at the tail end, +which in turn means that the PTI text clones should consistently +account for this. + +Make pti_clone_entry_text() consistent with pti_clone_kernel_text(). + +Fixes: 16a3fe634f6a ("x86/mm/pti: Clone kernel-image on PTE level for 32 bit") +Signed-off-by: Peter Zijlstra (Intel) +Signed-off-by: Sasha Levin +--- + arch/x86/mm/pti.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c +index 59c13fdb8da0f..50e31d14351bf 100644 +--- a/arch/x86/mm/pti.c ++++ b/arch/x86/mm/pti.c +@@ -497,7 +497,7 @@ static void pti_clone_entry_text(void) + { + pti_clone_pgtable((unsigned long) __entry_text_start, + (unsigned long) __entry_text_end, +- PTI_CLONE_PMD); ++ PTI_LEVEL_KERNEL_IMAGE); + } + + /* +-- +2.43.0 + diff --git a/queue-5.10/x86-mm-fix-pti_clone_pgtable-alignment-assumption.patch b/queue-5.10/x86-mm-fix-pti_clone_pgtable-alignment-assumption.patch new file mode 100644 index 00000000000..5eae99827cb --- /dev/null +++ b/queue-5.10/x86-mm-fix-pti_clone_pgtable-alignment-assumption.patch @@ -0,0 +1,68 @@ +From 1f6ad91b20dfe3ebcbace5401eab7e0a844b2962 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 1aab92930569a..59c13fdb8da0f 100644 +--- a/arch/x86/mm/pti.c ++++ b/arch/x86/mm/pti.c +@@ -374,14 +374,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; + } + +@@ -401,7 +401,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