March 2023 - Linux-stable-mirror

Re: [PATCH v2] PCI: hv: Fix the definition of vector in hv_compose_msi_msg()

by Boqun Feng

[Cc stable] On Thu, Oct 27, 2022 at 01:52:56PM -0700, Dexuan Cui wrote: > The local variable 'vector' must be u32 rather than u8: see the > struct hv_msi_desc3. > > 'vector_count' should be u16 rather than u8: see struct hv_msi_desc, > hv_msi_desc2 and hv_msi_desc3. > Dexuan, I think this patch should only be in 5.15, because... > Fixes: a2bad844a67b ("PCI: hv: Fix interrupt mapping for multi-MSI") ^^^ this commit is already in 5.15.y (commit id 92dcb50f7f09). Upstream id e70af8d040d2b7904dca93d942ba23fb722e21b1 Cc: <stable(a)vger.kernel.org> # 5.15.x Regards, Boqun > Signed-off-by: Dexuan Cui <decui(a)microsoft.com> > Cc: Jeffrey Hugo <quic_jhugo(a)quicinc.com> > Cc: Carl Vanderlip <quic_carlv(a)quicinc.com> > --- > > v1 was posted here (sorry, I forgot to follow this up...): > https://lwn.net/ml/linux-kernel/20220815185505.7626-1-decui@microsoft.com/ > > Changes in v2: > Added the explicit "(u8)" cast in hv_compose_msi_msg(). > Added and improved the comments. > Fixed a typo in the subject in v1: s/definiton/definition > > drivers/pci/controller/pci-hyperv.c | 22 ++++++++++++++++------ > 1 file changed, 16 insertions(+), 6 deletions(-) > > diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c > index e7c6f6629e7c..ba64284eaf9f 100644 > --- a/drivers/pci/controller/pci-hyperv.c > +++ b/drivers/pci/controller/pci-hyperv.c > @@ -1614,7 +1614,7 @@ static void hv_pci_compose_compl(void *context, struct pci_response *resp, > > static u32 hv_compose_msi_req_v1( > struct pci_create_interrupt *int_pkt, const struct cpumask *affinity, > - u32 slot, u8 vector, u8 vector_count) > + u32 slot, u8 vector, u16 vector_count) > { > int_pkt->message_type.type = PCI_CREATE_INTERRUPT_MESSAGE; > int_pkt->wslot.slot = slot; > @@ -1642,7 +1642,7 @@ static int hv_compose_msi_req_get_cpu(const struct cpumask *affinity) > > static u32 hv_compose_msi_req_v2( > struct pci_create_interrupt2 *int_pkt, const struct cpumask *affinity, > - u32 slot, u8 vector, u8 vector_count) > + u32 slot, u8 vector, u16 vector_count) > { > int cpu; > > @@ -1661,7 +1661,7 @@ static u32 hv_compose_msi_req_v2( > > static u32 hv_compose_msi_req_v3( > struct pci_create_interrupt3 *int_pkt, const struct cpumask *affinity, > - u32 slot, u32 vector, u8 vector_count) > + u32 slot, u32 vector, u16 vector_count) > { > int cpu; > > @@ -1701,7 +1701,12 @@ static void hv_compose_msi_msg(struct irq_data *data, struct msi_msg *msg) > struct compose_comp_ctxt comp; > struct tran_int_desc *int_desc; > struct msi_desc *msi_desc; > - u8 vector, vector_count; > + /* > + * vector_count should be u16: see hv_msi_desc, hv_msi_desc2 > + * and hv_msi_desc3. vector must be u32: see hv_msi_desc3. > + */ > + u16 vector_count; > + u32 vector; > struct { > struct pci_packet pci_pkt; > union { > @@ -1767,6 +1772,11 @@ static void hv_compose_msi_msg(struct irq_data *data, struct msi_msg *msg) > vector_count = 1; > } > > + /* > + * hv_compose_msi_req_v1 and v2 are for x86 only, meaning 'vector' > + * can't exceed u8. Cast 'vector' down to u8 for v1/v2 explicitly > + * for better readability. > + */ > memset(&ctxt, 0, sizeof(ctxt)); > init_completion(&comp.comp_pkt.host_event); > ctxt.pci_pkt.completion_func = hv_pci_compose_compl; > @@ -1777,7 +1787,7 @@ static void hv_compose_msi_msg(struct irq_data *data, struct msi_msg *msg) > size = hv_compose_msi_req_v1(&ctxt.int_pkts.v1, > dest, > hpdev->desc.win_slot.slot, > - vector, > + (u8)vector, > vector_count); > break; > > @@ -1786,7 +1796,7 @@ static void hv_compose_msi_msg(struct irq_data *data, struct msi_msg *msg) > size = hv_compose_msi_req_v2(&ctxt.int_pkts.v2, > dest, > hpdev->desc.win_slot.slot, > - vector, > + (u8)vector, > vector_count); > break; > > -- > 2.25.1 >

1 year

4
9
0 0

[PATCH v3 1/2] mtd: rawnand: stm32_fmc2: remove unsupported EDO mode

by Christophe Kerello

Remove the EDO mode support from as the FMC2 controller does not support the feature. Signed-off-by: Christophe Kerello <christophe.kerello(a)foss.st.com> Fixes: 2cd457f328c1 ("mtd: rawnand: stm32_fmc2: add STM32 FMC2 NAND flash controller driver") Cc: stable(a)vger.kernel.org #v5.4+ Reviewed-by: Tudor Ambarus <tudor.ambarus(a)linaro.org> --- Changes in v3: - The commit message has been reworked - Cc to stable added - Tudor Reviewed-by added drivers/mtd/nand/raw/stm32_fmc2_nand.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/mtd/nand/raw/stm32_fmc2_nand.c b/drivers/mtd/nand/raw/stm32_fmc2_nand.c index 5d627048c420..3abb63d00a0b 100644 --- a/drivers/mtd/nand/raw/stm32_fmc2_nand.c +++ b/drivers/mtd/nand/raw/stm32_fmc2_nand.c @@ -1531,6 +1531,9 @@ static int stm32_fmc2_nfc_setup_interface(struct nand_chip *chip, int chipnr, if (IS_ERR(sdrt)) return PTR_ERR(sdrt); + if (sdrt->tRC_min < 30000) + return -EOPNOTSUPP; + if (chipnr == NAND_DATA_IFACE_CHECK_ONLY) return 0; -- 2.25.1

1 year

2
1
0 0

[PATCH v3 2/2] mtd: rawnand: stm32_fmc2: use timings.mode instead of checking tRC_min

by Christophe Kerello

Use timings.mode value instead of checking tRC_min timing for EDO mode support. Signed-off-by: Christophe Kerello <christophe.kerello(a)foss.st.com> Fixes: 2cd457f328c1 ("mtd: rawnand: stm32_fmc2: add STM32 FMC2 NAND flash controller driver") Cc: stable(a)vger.kernel.org #v5.10+ Reviewed-by: Tudor Ambarus <tudor.ambarus(a)linaro.org> --- Changes in v3: - Fixes added - Cc to stable added - Tudor Reviewed-by added drivers/mtd/nand/raw/stm32_fmc2_nand.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/stm32_fmc2_nand.c b/drivers/mtd/nand/raw/stm32_fmc2_nand.c index 3abb63d00a0b..9e74bcd90aaa 100644 --- a/drivers/mtd/nand/raw/stm32_fmc2_nand.c +++ b/drivers/mtd/nand/raw/stm32_fmc2_nand.c @@ -1531,7 +1531,7 @@ static int stm32_fmc2_nfc_setup_interface(struct nand_chip *chip, int chipnr, if (IS_ERR(sdrt)) return PTR_ERR(sdrt); - if (sdrt->tRC_min < 30000) + if (conf->timings.mode > 3) return -EOPNOTSUPP; if (chipnr == NAND_DATA_IFACE_CHECK_ONLY) -- 2.25.1

1 year

2
1
0 0

[PATCH v2] mtdblock: tolerate corrected bit-flips

by Bang Li

mtd_read() may return -EUCLEAN in case of corrected bit-flips.This particular condition should not be treated like an error. Signed-off-by: Bang Li <libang.linuxer(a)gmail.com> Fixes: e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()") Cc: <stable(a)vger.kernel.org> # v3.7 --- Changes since v1: - Resend this patch with Cc and Fixes tags --- drivers/mtd/mtdblock.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/mtd/mtdblock.c b/drivers/mtd/mtdblock.c index 1e94e7d10b8b..a0a1194dc1d9 100644 --- a/drivers/mtd/mtdblock.c +++ b/drivers/mtd/mtdblock.c @@ -153,7 +153,7 @@ static int do_cached_write (struct mtdblk_dev *mtdblk, unsigned long pos, mtdblk->cache_state = STATE_EMPTY; ret = mtd_read(mtd, sect_start, sect_size, &retlen, mtdblk->cache_data); - if (ret) + if (ret && !mtd_is_bitflip(ret)) return ret; if (retlen != sect_size) return -EIO; @@ -188,8 +188,12 @@ static int do_cached_read (struct mtdblk_dev *mtdblk, unsigned long pos, pr_debug("mtdblock: read on \"%s\" at 0x%lx, size 0x%x\n", mtd->name, pos, len); - if (!sect_size) - return mtd_read(mtd, pos, len, &retlen, buf); + if (!sect_size) { + ret = mtd_read(mtd, pos, len, &retlen, buf); + if (ret && !mtd_is_bitflip(ret)) + return ret; + return 0; + } while (len > 0) { unsigned long sect_start = (pos/sect_size)*sect_size; @@ -209,7 +213,7 @@ static int do_cached_read (struct mtdblk_dev *mtdblk, unsigned long pos, memcpy (buf, mtdblk->cache_data + offset, size); } else { ret = mtd_read(mtd, pos, size, &retlen, buf); - if (ret) + if (ret && !mtd_is_bitflip(ret)) return ret; if (retlen != size) return -EIO; -- 2.25.1

1 year

3
2
0 0

[PATCH v5 0/2] kexec: Fix kexec_file_load for llvm16

by Ricardo Ribalda

When upreving llvm I realised that kexec stopped working on my test platform. This patch fixes it. Signed-off-by: Ricardo Ribalda <ribalda(a)chromium.org> --- Changes in v5: - Add warning when multiple text sections are found. Thanks Simon! - Add Fixes tag. - Link to v4: https://lore.kernel.org/r/20230321-kexec_clang16-v4-0-1340518f98e9@chromium… Changes in v4: - Add Cc: stable - Add linker script for x86 - Add a warning when the kernel image has overlapping sections. - Link to v3: https://lore.kernel.org/r/20230321-kexec_clang16-v3-0-5f016c8d0e87@chromium… Changes in v3: - Fix initial value. Thanks Ross! - Link to v2: https://lore.kernel.org/r/20230321-kexec_clang16-v2-0-d10e5d517869@chromium… Changes in v2: - Fix if condition. Thanks Steven!. - Update Philipp email. Thanks Baoquan. - Link to v1: https://lore.kernel.org/r/20230321-kexec_clang16-v1-0-a768fc2c7c4d@chromium… --- Ricardo Ribalda (2): kexec: Support purgatories with .text.hot sections x86/purgatory: Add linker script arch/x86/purgatory/.gitignore | 2 ++ arch/x86/purgatory/Makefile | 20 +++++++++---- arch/x86/purgatory/kexec-purgatory.S | 2 +- arch/x86/purgatory/purgatory.lds.S | 57 ++++++++++++++++++++++++++++++++++++ kernel/kexec_file.c | 14 ++++++++- 5 files changed, 87 insertions(+), 8 deletions(-) --- base-commit: 17214b70a159c6547df9ae204a6275d983146f6b change-id: 20230321-kexec_clang16-4510c23d129c Best regards, -- Ricardo Ribalda <ribalda(a)chromium.org>

1 year

3
3
0 0

net: dsa: mv88e6xxx: Request for stable inclusion

by Fabio Estevam

Hi, I am running kernel 6.1 on a system with a mv88e6320 and can easily trigger a flood of "mv88e6085 30be0000.ethernet-1:00: VTU member violation for vid 10, source port 5" messages. When this happens, the Ethernet audio that passes through the switch causes a loud noise in the speaker. Backporting the following commits to 6.1 solves the problem: 4bf24ad09bc0 ("net: dsa: mv88e6xxx: read FID when handling ATU violations") 8646384d80f3 ("net: dsa: mv88e6xxx: replace ATU violation prints with trace points") 9e3d9ae52b56 ("net: dsa: mv88e6xxx: replace VTU violation prints with trace points") Please apply them to 6.1-stable tree. Thanks, Fabio Estevam

1 year

3
4
0 0

[PATCH] wifi: rtw89: fix potential race condition between napi_init and napi_enable

by Ping-Ke Shih

A race condition can happen if netdev is registered, but NAPI isn't initialized yet, and meanwhile user space starts the netdev that will enable NAPI. Then, it hits BUG_ON(): kernel BUG at net/core/dev.c:6423! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 417 Comm: iwd Not tainted 6.2.7-slab-dirty #3 eb0f5a8a9d91 Hardware name: LENOVO 21DL/LNVNB161216, BIOS JPCN20WW(V1.06) 09/20/2022 RIP: 0010:napi_enable+0x3f/0x50 Code: 48 89 c2 48 83 e2 f6 f6 81 89 08 00 00 02 74 0d 48 83 ... RSP: 0018:ffffada1414f3548 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa01425802080 RCX: 0000000000000000 RDX: 00000000000002ff RSI: ffffada14e50c614 RDI: ffffa01425808dc0 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000100 R12: ffffa01425808f58 R13: 0000000000000000 R14: ffffa01423498940 R15: 0000000000000001 FS: 00007f5577c0a740(0000) GS:ffffa0169fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5577a19972 CR3: 0000000125a7a000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> rtw89_pci_ops_start+0x1c/0x70 [rtw89_pci 6cbc75429515c181cbc386478d5cfb32ffc5a0f8] rtw89_core_start+0xbe/0x160 [rtw89_core fe07ecb874820b6d778370d4acb6ef8a37847f22] rtw89_ops_start+0x26/0x40 [rtw89_core fe07ecb874820b6d778370d4acb6ef8a37847f22] drv_start+0x42/0x100 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2] ieee80211_do_open+0x311/0x7d0 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2] ieee80211_open+0x6a/0x90 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2] __dev_open+0xe0/0x180 __dev_change_flags+0x1da/0x250 dev_change_flags+0x26/0x70 do_setlink+0x37c/0x12c0 ? ep_poll_callback+0x246/0x290 ? __nla_validate_parse+0x61/0xd00 ? __wake_up_common_lock+0x8f/0xd0 To fix this, follow Jonas' suggestion to switch the order of these functions and move register netdev to be the last step of PCI probe. Also, correct the error handling of rtw89_core_register_hw(). Fixes: e3ec7017f6a2 ("rtw89: add Realtek 802.11ax driver") Cc: stable(a)vger.kernel.org Reported-by: Hyeonggon Yoo <42.hyeyoo(a)gmail.com> Link: https://lore.kernel.org/linux-wireless/CAOiHx=n7EwK2B9CnBR07FVA=sEzFagb8TkS… Suggested-by: Jonas Gorski <jonas.gorski(a)gmail.com> Tested-by: Larry Finger<Larry.Finger(a)lwfinger.net> Reviewed-by: Larry Finger<Larry.Finger(a)lwfinger.net> Signed-off-by: Ping-Ke Shih <pkshih(a)realtek.com> --- drivers/net/wireless/realtek/rtw89/core.c | 10 +++++++--- drivers/net/wireless/realtek/rtw89/pci.c | 19 ++++++++++--------- 2 files changed, 17 insertions(+), 12 deletions(-) diff --git a/drivers/net/wireless/realtek/rtw89/core.c b/drivers/net/wireless/realtek/rtw89/core.c index 489fa7a86160d..1efe008706669 100644 --- a/drivers/net/wireless/realtek/rtw89/core.c +++ b/drivers/net/wireless/realtek/rtw89/core.c @@ -3434,18 +3434,22 @@ static int rtw89_core_register_hw(struct rtw89_dev *rtwdev) ret = ieee80211_register_hw(hw); if (ret) { rtw89_err(rtwdev, "failed to register hw\n"); - goto err; + goto err_free_supported_band; } ret = rtw89_regd_init(rtwdev, rtw89_regd_notifier); if (ret) { rtw89_err(rtwdev, "failed to init regd\n"); - goto err; + goto err_unregister_hw; } return 0; -err: +err_unregister_hw: + ieee80211_unregister_hw(hw); +err_free_supported_band: + rtw89_core_clr_supported_band(rtwdev); + return ret; } diff --git a/drivers/net/wireless/realtek/rtw89/pci.c b/drivers/net/wireless/realtek/rtw89/pci.c index ec8bb5f10482e..4025aabe06042 100644 --- a/drivers/net/wireless/realtek/rtw89/pci.c +++ b/drivers/net/wireless/realtek/rtw89/pci.c @@ -3874,25 +3874,26 @@ int rtw89_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id) rtw89_pci_link_cfg(rtwdev); rtw89_pci_l1ss_cfg(rtwdev); - ret = rtw89_core_register(rtwdev); - if (ret) { - rtw89_err(rtwdev, "failed to register core\n"); - goto err_clear_resource; - } - rtw89_core_napi_init(rtwdev); ret = rtw89_pci_request_irq(rtwdev, pdev); if (ret) { rtw89_err(rtwdev, "failed to request pci irq\n"); - goto err_unregister; + goto err_deinit_napi; + } + + ret = rtw89_core_register(rtwdev); + if (ret) { + rtw89_err(rtwdev, "failed to register core\n"); + goto err_free_irq; } return 0; -err_unregister: +err_free_irq: + rtw89_pci_free_irq(rtwdev, pdev); +err_deinit_napi: rtw89_core_napi_deinit(rtwdev); - rtw89_core_unregister(rtwdev); err_clear_resource: rtw89_pci_clear_resource(rtwdev, pdev); err_declaim_pci: -- 2.25.1

1 year

2
1
0 0

[PATCH v2 4.19 0/3] Backport patches to fix threadgroup_rwsem <-> cpus_read_lock() deadlock

by Cai Xinchen

I am very sorry. My gcc version is 7.5 and it does not report error. We have a deadlock problem which can be solved by commit 4f7e7236435ca ("cgroup: Fix threadgroup_rwsem <-> cpus_read_lock() deadlock"). However, it makes lock order of cpus_read_lock and cpuset_mutex wrong in v4.19. The call sequence is as follows: cgroup_procs_write() cgroup_procs_write_start() get_online_cpus(); // cpus_read_lock() percpu_down_write(&cgroup_threadgroup_rwsem) cgroup_attach_task cgroup_migrate cgroup_migrate_execute ss->attach (cpust_attach) mutex_lock(&cpuset_mutex) it seems hard to make cpus_read_lock is locked before cgroup_threadgroup_rwsem and cpuset_mutex is locked before cpus_read_lock unless backport the commit d74b27d63a8beb ("cgroup/cpuset: Change cpuset_rwsem and hotplug lock order") Changes in v2: * Add #include <linux/cpu.h> in kernel/cgroup/cgroup.c to avoid some compile error. * Exchange get_online_cpus() location in cpuset_attach to keep cpu_hotplug_lock->cpuset_mutex order, although it will be remove by ("cgroup: Fix threadgroup_rwsem <-> cpus_read_lock() deadlock") Juri Lelli (1): cgroup/cpuset: Change cpuset_rwsem and hotplug lock order Tejun Heo (1): cgroup: Fix threadgroup_rwsem <-> cpus_read_lock() deadlock Tetsuo Handa (1): cgroup: Add missing cpus_read_lock() to cgroup_attach_task_all() include/linux/cpuset.h | 8 +++---- kernel/cgroup/cgroup-v1.c | 3 +++ kernel/cgroup/cgroup.c | 50 +++++++++++++++++++++++++++++++++++---- kernel/cgroup/cpuset.c | 25 ++++++++++++-------- 4 files changed, 67 insertions(+), 19 deletions(-) -- 2.17.1

1 year

2
4
0 0

[PATCH 4.14.y] net: sched: cbq: dont intepret cls results when asked to drop

by Harshit Mogalapalli

From: Jamal Hadi Salim <jhs(a)mojatatu.com> [ Upstream commit caa4b35b4317d5147b3ab0fbdc9c075c7d2e9c12 ] If asked to drop a packet via TC_ACT_SHOT it is unsafe to assume that res.class contains a valid pointer Sample splat reported by Kyle Zeng [ 5.405624] 0: reclassify loop, rule prio 0, protocol 800 [ 5.406326] ================================================================== [ 5.407240] BUG: KASAN: slab-out-of-bounds in cbq_enqueue+0x54b/0xea0 [ 5.407987] Read of size 1 at addr ffff88800e3122aa by task poc/299 [ 5.408731] [ 5.408897] CPU: 0 PID: 299 Comm: poc Not tainted 5.10.155+ #15 [ 5.409516] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 5.410439] Call Trace: [ 5.410764] dump_stack+0x87/0xcd [ 5.411153] print_address_description+0x7a/0x6b0 [ 5.411687] ? vprintk_func+0xb9/0xc0 [ 5.411905] ? printk+0x76/0x96 [ 5.412110] ? cbq_enqueue+0x54b/0xea0 [ 5.412323] kasan_report+0x17d/0x220 [ 5.412591] ? cbq_enqueue+0x54b/0xea0 [ 5.412803] __asan_report_load1_noabort+0x10/0x20 [ 5.413119] cbq_enqueue+0x54b/0xea0 [ 5.413400] ? __kasan_check_write+0x10/0x20 [ 5.413679] __dev_queue_xmit+0x9c0/0x1db0 [ 5.413922] dev_queue_xmit+0xc/0x10 [ 5.414136] ip_finish_output2+0x8bc/0xcd0 [ 5.414436] __ip_finish_output+0x472/0x7a0 [ 5.414692] ip_finish_output+0x5c/0x190 [ 5.414940] ip_output+0x2d8/0x3c0 [ 5.415150] ? ip_mc_finish_output+0x320/0x320 [ 5.415429] __ip_queue_xmit+0x753/0x1760 [ 5.415664] ip_queue_xmit+0x47/0x60 [ 5.415874] __tcp_transmit_skb+0x1ef9/0x34c0 [ 5.416129] tcp_connect+0x1f5e/0x4cb0 [ 5.416347] tcp_v4_connect+0xc8d/0x18c0 [ 5.416577] __inet_stream_connect+0x1ae/0xb40 [ 5.416836] ? local_bh_enable+0x11/0x20 [ 5.417066] ? lock_sock_nested+0x175/0x1d0 [ 5.417309] inet_stream_connect+0x5d/0x90 [ 5.417548] ? __inet_stream_connect+0xb40/0xb40 [ 5.417817] __sys_connect+0x260/0x2b0 [ 5.418037] __x64_sys_connect+0x76/0x80 [ 5.418267] do_syscall_64+0x31/0x50 [ 5.418477] entry_SYSCALL_64_after_hwframe+0x61/0xc6 [ 5.418770] RIP: 0033:0x473bb7 [ 5.418952] Code: 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2a 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 18 89 54 24 0c 48 89 34 24 89 [ 5.420046] RSP: 002b:00007fffd20eb0f8 EFLAGS: 00000246 ORIG_RAX: 000000000000002a [ 5.420472] RAX: ffffffffffffffda RBX: 00007fffd20eb578 RCX: 0000000000473bb7 [ 5.420872] RDX: 0000000000000010 RSI: 00007fffd20eb110 RDI: 0000000000000007 [ 5.421271] RBP: 00007fffd20eb150 R08: 0000000000000001 R09: 0000000000000004 [ 5.421671] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 [ 5.422071] R13: 00007fffd20eb568 R14: 00000000004fc740 R15: 0000000000000002 [ 5.422471] [ 5.422562] Allocated by task 299: [ 5.422782] __kasan_kmalloc+0x12d/0x160 [ 5.423007] kasan_kmalloc+0x5/0x10 [ 5.423208] kmem_cache_alloc_trace+0x201/0x2e0 [ 5.423492] tcf_proto_create+0x65/0x290 [ 5.423721] tc_new_tfilter+0x137e/0x1830 [ 5.423957] rtnetlink_rcv_msg+0x730/0x9f0 [ 5.424197] netlink_rcv_skb+0x166/0x300 [ 5.424428] rtnetlink_rcv+0x11/0x20 [ 5.424639] netlink_unicast+0x673/0x860 [ 5.424870] netlink_sendmsg+0x6af/0x9f0 [ 5.425100] __sys_sendto+0x58d/0x5a0 [ 5.425315] __x64_sys_sendto+0xda/0xf0 [ 5.425539] do_syscall_64+0x31/0x50 [ 5.425764] entry_SYSCALL_64_after_hwframe+0x61/0xc6 [ 5.426065] [ 5.426157] The buggy address belongs to the object at ffff88800e312200 [ 5.426157] which belongs to the cache kmalloc-128 of size 128 [ 5.426955] The buggy address is located 42 bytes to the right of [ 5.426955] 128-byte region [ffff88800e312200, ffff88800e312280) [ 5.427688] The buggy address belongs to the page: [ 5.427992] page:000000009875fabc refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xe312 [ 5.428562] flags: 0x100000000000200(slab) [ 5.428812] raw: 0100000000000200 dead000000000100 dead000000000122 ffff888007843680 [ 5.429325] raw: 0000000000000000 0000000000100010 00000001ffffffff ffff88800e312401 [ 5.429875] page dumped because: kasan: bad access detected [ 5.430214] page->mem_cgroup:ffff88800e312401 [ 5.430471] [ 5.430564] Memory state around the buggy address: [ 5.430846] ffff88800e312180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 5.431267] ffff88800e312200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc [ 5.431705] >ffff88800e312280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 5.432123] ^ [ 5.432391] ffff88800e312300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc [ 5.432810] ffff88800e312380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 5.433229] ================================================================== [ 5.433648] Disabling lock debugging due to kernel taint Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Kyle Zeng <zengyhkyle(a)gmail.com> Signed-off-by: Jamal Hadi Salim <jhs(a)mojatatu.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> [Harshit: backport for 4.14.y] Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli(a)oracle.com> --- Only compile and boot tested. This is marked as Fix for CVE-2023-23454. Would be nice if any net developer review this before merging this to stable. --- net/sched/sch_cbq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/sched/sch_cbq.c b/net/sched/sch_cbq.c index dea125d8aac7..8b75a9572d1f 100644 --- a/net/sched/sch_cbq.c +++ b/net/sched/sch_cbq.c @@ -236,6 +236,8 @@ cbq_classify(struct sk_buff *skb, struct Qdisc *sch, int *qerr) result = tcf_classify(skb, fl, &res, true); if (!fl || result < 0) goto fallback; + if (result == TC_ACT_SHOT) + return NULL; cl = (void *)res.class; if (!cl) { @@ -255,8 +257,6 @@ cbq_classify(struct sk_buff *skb, struct Qdisc *sch, int *qerr) case TC_ACT_STOLEN: case TC_ACT_TRAP: *qerr = NET_XMIT_SUCCESS | __NET_XMIT_STOLEN; - case TC_ACT_SHOT: - return NULL; case TC_ACT_RECLASSIFY: return cbq_reclassify(skb, cl); } -- 2.38.1

1 year

2
1
0 0

[PATCH 4.19/5.4/5.10 0/1] gfs2: Always check inode size of inline inodes

by Fedor Pchelkin

Kernel bug in iomap_read_inline_data() fixed by the following patch is hit on older stables 4.19/5.4/5.10. The patch failed to be initially backported into stable branches older than 5.15 due to the upstream commit 7db354444ad8 ("gfs2: Cosmetic gfs2_dinode_{in,out} cleanup"). Now it can be cleanly applied to the 4.19/5.4/5.10 stable branches.

1 year

2
3
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2023