- Kernel - mailweb.openeuler.org

[PATCH openEuler-22.03-LTS-SP1] nfsd: return -EINVAL when namelen is 0
by Li Lingfeng 24 Oct '24

24 Oct '24

mainline inclusion from mainline-v6.12-rc1 commit 22451a16b7ab7debefce660672566be887db1637 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAYQ6P Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered. [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205] dump_stack+0x9a/0xd0 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] __kasan_report.cold+0x34/0x84 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] kasan_report+0x3a/0x50 [ T1205] nfs4_client_to_reclaim+0xe9/0x260 [ T1205] ? nfsd4_release_lockowner+0x410/0x410 [ T1205] cld_pipe_downcall+0x5ca/0x760 [ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205] ? down_write_killable_nested+0x170/0x170 [ T1205] ? avc_policy_seqno+0x28/0x40 [ T1205] ? selinux_file_permission+0x1b4/0x1e0 [ T1205] rpc_pipe_write+0x84/0xb0 [ T1205] vfs_write+0x143/0x520 [ T1205] ksys_write+0xc9/0x170 [ T1205] ? __ia32_sys_read+0x50/0x50 [ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205] do_syscall_64+0x33/0x40 [ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ================================================================== Fix it by checking namelen. Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> Fixes: 74725959c33c ("nfsd: un-deprecate nfsdcld") Reviewed-by: Jeff Layton <jlayton(a)kernel.org> Reviewed-by: Scott Mayhew <smayhew(a)redhat.com> Tested-by: Scott Mayhew <smayhew(a)redhat.com> Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> Conflicts: fs/nfsd/nfs4recover.c [Commit 30a30fcc3fc1 ("nfsd: Propagate some error code returned by memdup_user()") return PTR_ERR(name.data) instead of -EFAULT] Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- fs/nfsd/nfs4recover.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/fs/nfsd/nfs4recover.c b/fs/nfsd/nfs4recover.c index 83c4e6883953..f2801eaea7c6 100644 --- a/fs/nfsd/nfs4recover.c +++ b/fs/nfsd/nfs4recover.c @@ -806,6 +806,10 @@ __cld_pipe_inprogress_downcall(const struct cld_msg_v2 __user *cmsg, ci = &cmsg->cm_u.cm_clntinfo; if (get_user(namelen, &ci->cc_name.cn_len)) return -EFAULT; + if (!namelen) { + dprintk("%s: namelen should not be zero", __func__); + return -EINVAL; + } name.data = memdup_user(&ci->cc_name.cn_id, namelen); if (IS_ERR_OR_NULL(name.data)) return -EFAULT; @@ -828,6 +832,10 @@ __cld_pipe_inprogress_downcall(const struct cld_msg_v2 __user *cmsg, cnm = &cmsg->cm_u.cm_name; if (get_user(namelen, &cnm->cn_len)) return -EFAULT; + if (!namelen) { + dprintk("%s: namelen should not be zero", __func__); + return -EINVAL; + } name.data = memdup_user(&cnm->cn_id, namelen); if (IS_ERR_OR_NULL(name.data)) return -EFAULT; -- 2.31.1

2 1

[PATCH openEuler-1.0-LTS 1/2] usb: dwc3: core: Skip setting event buffers for host only controllers
by Lin Ruifeng 24 Oct '24

24 Oct '24

From: Krishna Kurapati <quic_kriskura(a)quicinc.com> stable inclusion from stable-v4.19.321 commit 320bb9a5a6b79ba123d1e1f746edb52b41c7c1fb bugzilla: https://gitee.com/src-openeuler/kernel/issues/ CVE: CVE-2024-46675 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 89d7f962994604a3e3d480832788d06179abefc5 ] On some SoC's like SA8295P where the tertiary controller is host-only capable, GEVTADDRHI/LO, GEVTSIZ, GEVTCOUNT registers are not accessible. Trying to access them leads to a crash. For DRD/Peripheral supported controllers, event buffer setup is done again in gadget_pullup. Skip setup or cleanup of event buffers if controller is host-only capable. Suggested-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Krishna Kurapati <quic_kriskura(a)quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> Reviewed-by: Johan Hovold <johan+linaro(a)kernel.org> Reviewed-by: Bjorn Andersson <andersson(a)kernel.org> Tested-by: Johan Hovold <johan+linaro(a)kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-4-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/usb/dwc3/core.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 8e3c23568faf..aa1f69464126 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -388,6 +388,13 @@ static void dwc3_free_event_buffers(struct dwc3 *dwc) static int dwc3_alloc_event_buffers(struct dwc3 *dwc, unsigned length) { struct dwc3_event_buffer *evt; + unsigned int hw_mode; + + hw_mode = DWC3_GHWPARAMS0_MODE(dwc->hwparams.hwparams0); + if (hw_mode == DWC3_GHWPARAMS0_MODE_HOST) { + dwc->ev_buf = NULL; + return 0; + } evt = dwc3_alloc_one_event_buffer(dwc, length); if (IS_ERR(evt)) { @@ -409,6 +416,9 @@ int dwc3_event_buffers_setup(struct dwc3 *dwc) { struct dwc3_event_buffer *evt; + if (!dwc->ev_buf) + return 0; + evt = dwc->ev_buf; evt->lpos = 0; dwc3_writel(dwc->regs, DWC3_GEVNTADRLO(0), @@ -426,6 +436,9 @@ void dwc3_event_buffers_cleanup(struct dwc3 *dwc) { struct dwc3_event_buffer *evt; + if (!dwc->ev_buf) + return; + evt = dwc->ev_buf; evt->lpos = 0; -- 2.17.1

2 2

[openeuler:OLK-5.10 28544/30000] drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c:2327:6: warning: no previous prototype for 'mcp251xfd_tx_obj_write_sync'
by kernel test robot 24 Oct '24

24 Oct '24

Hi Vitor, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: 52e62ae625fcfe934330b24239cf61af5b5ce33f commit: b4eaf3e808dc2abcab55bc72df3b0d15961f33f0 [28544/30000] can: mcp251xfd: fix infinite loop when xmit fails config: x86_64-buildonly-randconfig-006-20241024 (https://download.01.org/0day-ci/archive/20241024/202410241814.11iTrBh6-lkp@…) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241024/202410241814.11iTrBh6-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202410241814.11iTrBh6-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c:2327:6: warning: no previous prototype for 'mcp251xfd_tx_obj_write_sync' [-Wmissing-prototypes] 2327 | void mcp251xfd_tx_obj_write_sync(struct work_struct *work) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ vim +/mcp251xfd_tx_obj_write_sync +2327 drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c 2326 > 2327 void mcp251xfd_tx_obj_write_sync(struct work_struct *work) 2328 { 2329 struct mcp251xfd_priv *priv = container_of(work, struct mcp251xfd_priv, 2330 tx_work); 2331 struct mcp251xfd_tx_obj *tx_obj = priv->tx_work_obj; 2332 struct mcp251xfd_tx_ring *tx_ring = priv->tx; 2333 int err; 2334 2335 err = spi_sync(priv->spi, &tx_obj->msg); 2336 if (err) 2337 mcp251xfd_tx_failure_drop(priv, tx_ring, err); 2338 } 2339 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-1.0-LTS] cgroup: Protect css->cgroup write under css_set_lock
by Chen Ridong 24 Oct '24

24 Oct '24

From: Waiman Long <longman(a)redhat.com> stable inclusion from stable-v4.19.322 commit 6760357063f593a17613e015aed2051cfd4197c6 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAYN0Z Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 57b56d16800e8961278ecff0dc755d46c4575092 ] The writing of css->cgroup associated with the cgroup root in rebind_subsystems() is currently protected only by cgroup_mutex. However, the reading of css->cgroup in both proc_cpuset_show() and proc_cgroup_show() is protected just by css_set_lock. That makes the readers susceptible to racing problems like data tearing or caching. It is also a problem that can be reported by KCSAN. This can be fixed by using READ_ONCE() and WRITE_ONCE() to access css->cgroup. Alternatively, the writing of css->cgroup can be moved under css_set_lock as well which is done by this patch. Signed-off-by: Waiman Long <longman(a)redhat.com> Signed-off-by: Tejun Heo <tj(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Chen Ridong <chenridong(a)huawei.com> --- kernel/cgroup/cgroup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c index 1339b93f7054..7b3c1491cc88 100644 --- a/kernel/cgroup/cgroup.c +++ b/kernel/cgroup/cgroup.c @@ -1717,9 +1717,9 @@ int rebind_subsystems(struct cgroup_root *dst_root, u16 ss_mask) RCU_INIT_POINTER(scgrp->subsys[ssid], NULL); rcu_assign_pointer(dcgrp->subsys[ssid], css); ss->root = dst_root; - css->cgroup = dcgrp; spin_lock_irq(&css_set_lock); + css->cgroup = dcgrp; WARN_ON(!list_empty(&dcgrp->e_csets[ss->id])); list_for_each_entry_safe(cset, cset_pos, &scgrp->e_csets[ss->id], e_cset_node[ss->id]) { -- 2.34.1

2 2

[PATCH OLK-6.6] ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate()
by Zhang Kunbo 24 Oct '24

24 Oct '24

From: Dan Carpenter <alexander.sverdlin(a)gmail.com> stable inclusion from stable-v6.6.54 commit 66e78ade976dbd9bea09166aa8d66afc0963cde4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYPJL CVE: CVE-2024-47686 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit c7f06284a6427475e3df742215535ec3f6cd9662 ] The psc->div[] array has psc->num_div elements. These values come from when we call clk_hw_register_div(). It's adc_divisors and ARRAY_SIZE(adc_divisors)) and so on. So this condition needs to be >= instead of > to prevent an out of bounds read. Fixes: 9645ccc7bd7a ("ep93xx: clock: convert in-place to COMMON_CLK") Signed-off-by: Dan Carpenter <dan.carpenter(a)linaro.org> Acked-by: Alexander Sverdlin <alexander.sverdlin(a)gmail.com> Reviewed-by: Nikita Shubin <nikita.shubin(a)maquefel.me> Signed-off-by: Alexander Sverdlin <alexander.sverdlin(a)gmail.com> Link: https://lore.kernel.org/r/1caf01ad4c0a8069535813c26c7f0b8ea011155e.camel@li… Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhang Kunbo <zhangkunbo(a)huawei.com> --- arch/arm/mach-ep93xx/clock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-ep93xx/clock.c b/arch/arm/mach-ep93xx/clock.c index 85a496ddc619..e9f72a529b50 100644 --- a/arch/arm/mach-ep93xx/clock.c +++ b/arch/arm/mach-ep93xx/clock.c @@ -359,7 +359,7 @@ static unsigned long ep93xx_div_recalc_rate(struct clk_hw *hw, u32 val = __raw_readl(psc->reg); u8 index = (val & psc->mask) >> psc->shift; - if (index > psc->num_div) + if (index >= psc->num_div) return 0; return DIV_ROUND_UP_ULL(parent_rate, psc->div[index]); -- 2.34.1

2 1

[openeuler:OLK-5.10 24216/30000] drivers/net/dsa/mv88e6xxx/chip.c:2320:25: error: implicit declaration of function 'mv88e6xxx_g2_eeprom_wait'; did you mean 'mv88e6xxx_g2_pvt_write'?
by kernel test robot 24 Oct '24

24 Oct '24

Hi Fabio, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: 5faf5aae71283199f69c2a60ed91ab2847f3ffd8 commit: 02956abc74ede6549249eb21e5b319b92dd147f3 [24216/30000] net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent config: x86_64-buildonly-randconfig-006-20241024 (https://download.01.org/0day-ci/archive/20241024/202410241622.JPCqkyC5-lkp@…) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241024/202410241622.JPCqkyC5-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202410241622.JPCqkyC5-lkp@intel.com/ All errors (new ones prefixed by >>): drivers/net/dsa/mv88e6xxx/chip.c: In function 'mv88e6xxx_hardware_reset': >> drivers/net/dsa/mv88e6xxx/chip.c:2320:25: error: implicit declaration of function 'mv88e6xxx_g2_eeprom_wait'; did you mean 'mv88e6xxx_g2_pvt_write'? [-Werror=implicit-function-declaration] 2320 | mv88e6xxx_g2_eeprom_wait(chip); | ^~~~~~~~~~~~~~~~~~~~~~~~ | mv88e6xxx_g2_pvt_write cc1: some warnings being treated as errors vim +2320 drivers/net/dsa/mv88e6xxx/chip.c 2306 2307 static void mv88e6xxx_hardware_reset(struct mv88e6xxx_chip *chip) 2308 { 2309 struct gpio_desc *gpiod = chip->reset; 2310 2311 /* If there is a GPIO connected to the reset pin, toggle it */ 2312 if (gpiod) { 2313 /* If the switch has just been reset and not yet completed 2314 * loading EEPROM, the reset may interrupt the I2C transaction 2315 * mid-byte, causing the first EEPROM read after the reset 2316 * from the wrong location resulting in the switch booting 2317 * to wrong mode and inoperable. 2318 */ 2319 if (chip->info->ops->get_eeprom) > 2320 mv88e6xxx_g2_eeprom_wait(chip); 2321 2322 gpiod_set_value_cansleep(gpiod, 1); 2323 usleep_range(10000, 20000); 2324 gpiod_set_value_cansleep(gpiod, 0); 2325 usleep_range(10000, 20000); 2326 2327 if (chip->info->ops->get_eeprom) 2328 mv88e6xxx_g2_eeprom_wait(chip); 2329 } 2330 } 2331 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6] wifi: mac80211: fix NULL dereference at band check in starting tx ba session
by Dong Chenchen 24 Oct '24

24 Oct '24

From: Zong-Zhe Yang <kevin_yang(a)realtek.com> mainline inclusion from mainline-v6.11-rc1 commit 021d53a3d87eeb9dbba524ac515651242a2a7e3b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAMMA0 CVE: CVE-2024-43911 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In MLD connection, link_data/link_conf are dynamically allocated. They don't point to vif->bss_conf. So, there will be no chanreq assigned to vif->bss_conf and then the chan will be NULL. Tweak the code to check ht_supported/vht_supported/has_he/has_eht on sta deflink. Crash log (with rtw89 version under MLO development): [ 9890.526087] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 9890.526102] #PF: supervisor read access in kernel mode [ 9890.526105] #PF: error_code(0x0000) - not-present page [ 9890.526109] PGD 0 P4D 0 [ 9890.526114] Oops: 0000 [#1] PREEMPT SMP PTI [ 9890.526119] CPU: 2 PID: 6367 Comm: kworker/u16:2 Kdump: loaded Tainted: G OE 6.9.0 #1 [ 9890.526123] Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB3WW (2.73 ) 11/28/2018 [ 9890.526126] Workqueue: phy2 rtw89_core_ba_work [rtw89_core] [ 9890.526203] RIP: 0010:ieee80211_start_tx_ba_session (net/mac80211/agg-tx.c:618 (discriminator 1)) mac80211 [ 9890.526279] Code: f7 e8 d5 93 3e ea 48 83 c4 28 89 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 49 8b 84 24 e0 f1 ff ff 48 8b 80 90 1b 00 00 <83> 38 03 0f 84 37 fe ff ff bb ea ff ff ff eb cc 49 8b 84 24 10 f3 All code ======== 0: f7 e8 imul %eax 2: d5 (bad) 3: 93 xchg %eax,%ebx 4: 3e ea ds (bad) 6: 48 83 c4 28 add $0x28,%rsp a: 89 d8 mov %ebx,%eax c: 5b pop %rbx d: 41 5c pop %r12 f: 41 5d pop %r13 11: 41 5e pop %r14 13: 41 5f pop %r15 15: 5d pop %rbp 16: c3 retq 17: cc int3 18: cc int3 19: cc int3 1a: cc int3 1b: 49 8b 84 24 e0 f1 ff mov -0xe20(%r12),%rax 22: ff 23: 48 8b 80 90 1b 00 00 mov 0x1b90(%rax),%rax 2a:* 83 38 03 cmpl $0x3,(%rax) <-- trapping instruction 2d: 0f 84 37 fe ff ff je 0xfffffffffffffe6a 33: bb ea ff ff ff mov $0xffffffea,%ebx 38: eb cc jmp 0x6 3a: 49 rex.WB 3b: 8b .byte 0x8b 3c: 84 24 10 test %ah,(%rax,%rdx,1) 3f: f3 repz Code starting with the faulting instruction =========================================== 0: 83 38 03 cmpl $0x3,(%rax) 3: 0f 84 37 fe ff ff je 0xfffffffffffffe40 9: bb ea ff ff ff mov $0xffffffea,%ebx e: eb cc jmp 0xffffffffffffffdc 10: 49 rex.WB 11: 8b .byte 0x8b 12: 84 24 10 test %ah,(%rax,%rdx,1) 15: f3 repz [ 9890.526285] RSP: 0018:ffffb8db09013d68 EFLAGS: 00010246 [ 9890.526291] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9308e0d656c8 [ 9890.526295] RDX: 0000000000000000 RSI: ffffffffab99460b RDI: ffffffffab9a7685 [ 9890.526300] RBP: ffffb8db09013db8 R08: 0000000000000000 R09: 0000000000000873 [ 9890.526304] R10: ffff9308e0d64800 R11: 0000000000000002 R12: ffff9308e5ff6e70 [ 9890.526308] R13: ffff930952500e20 R14: ffff9309192a8c00 R15: 0000000000000000 [ 9890.526313] FS: 0000000000000000(0000) GS:ffff930b4e700000(0000) knlGS:0000000000000000 [ 9890.526316] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 9890.526318] CR2: 0000000000000000 CR3: 0000000391c58005 CR4: 00000000001706f0 [ 9890.526321] Call Trace: [ 9890.526324] <TASK> [ 9890.526327] ? show_regs (arch/x86/kernel/dumpstack.c:479) [ 9890.526335] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 9890.526340] ? page_fault_oops (arch/x86/mm/fault.c:713) [ 9890.526347] ? search_module_extables (kernel/module/main.c:3256 (discriminator 3)) [ 9890.526353] ? ieee80211_start_tx_ba_session (net/mac80211/agg-tx.c:618 (discriminator 1)) mac80211 Signed-off-by: Zong-Zhe Yang <kevin_yang(a)realtek.com> Link: https://patch.msgid.link/20240617115217.22344-1-kevin_yang@realtek.com Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Conflicts: net/mac80211/agg-tx.c [Conflicts due to different line numbers] Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/mac80211/agg-tx.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/net/mac80211/agg-tx.c b/net/mac80211/agg-tx.c index 0a69e47f1c55..444edd6364c5 100644 --- a/net/mac80211/agg-tx.c +++ b/net/mac80211/agg-tx.c @@ -616,7 +616,9 @@ int ieee80211_start_tx_ba_session(struct ieee80211_sta *pubsta, u16 tid, return -EINVAL; if (!pubsta->deflink.ht_cap.ht_supported && - sta->sdata->vif.bss_conf.chandef.chan->band != NL80211_BAND_6GHZ) + !pubsta->deflink.vht_cap.vht_supported && + !pubsta->deflink.he_cap.has_he && + !pubsta->deflink.eht_cap.has_eht) return -EINVAL; if (WARN_ON_ONCE(!local->ops->ampdu_action)) -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] wifi: mac80211: fix NULL dereference at band check in starting tx ba session
by Dong Chenchen 24 Oct '24

24 Oct '24

From: Zong-Zhe Yang <kevin_yang(a)realtek.com> mainline inclusion from mainline-v6.11-rc1 commit 021d53a3d87eeb9dbba524ac515651242a2a7e3b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAMMA0 CVE: CVE-2024-43911 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In MLD connection, link_data/link_conf are dynamically allocated. They don't point to vif->bss_conf. So, there will be no chanreq assigned to vif->bss_conf and then the chan will be NULL. Tweak the code to check ht_supported/vht_supported/has_he/has_eht on sta deflink. Crash log (with rtw89 version under MLO development): [ 9890.526087] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 9890.526102] #PF: supervisor read access in kernel mode [ 9890.526105] #PF: error_code(0x0000) - not-present page [ 9890.526109] PGD 0 P4D 0 [ 9890.526114] Oops: 0000 [#1] PREEMPT SMP PTI [ 9890.526119] CPU: 2 PID: 6367 Comm: kworker/u16:2 Kdump: loaded Tainted: G OE 6.9.0 #1 [ 9890.526123] Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB3WW (2.73 ) 11/28/2018 [ 9890.526126] Workqueue: phy2 rtw89_core_ba_work [rtw89_core] [ 9890.526203] RIP: 0010:ieee80211_start_tx_ba_session (net/mac80211/agg-tx.c:618 (discriminator 1)) mac80211 [ 9890.526279] Code: f7 e8 d5 93 3e ea 48 83 c4 28 89 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 49 8b 84 24 e0 f1 ff ff 48 8b 80 90 1b 00 00 <83> 38 03 0f 84 37 fe ff ff bb ea ff ff ff eb cc 49 8b 84 24 10 f3 All code ======== 0: f7 e8 imul %eax 2: d5 (bad) 3: 93 xchg %eax,%ebx 4: 3e ea ds (bad) 6: 48 83 c4 28 add $0x28,%rsp a: 89 d8 mov %ebx,%eax c: 5b pop %rbx d: 41 5c pop %r12 f: 41 5d pop %r13 11: 41 5e pop %r14 13: 41 5f pop %r15 15: 5d pop %rbp 16: c3 retq 17: cc int3 18: cc int3 19: cc int3 1a: cc int3 1b: 49 8b 84 24 e0 f1 ff mov -0xe20(%r12),%rax 22: ff 23: 48 8b 80 90 1b 00 00 mov 0x1b90(%rax),%rax 2a:* 83 38 03 cmpl $0x3,(%rax) <-- trapping instruction 2d: 0f 84 37 fe ff ff je 0xfffffffffffffe6a 33: bb ea ff ff ff mov $0xffffffea,%ebx 38: eb cc jmp 0x6 3a: 49 rex.WB 3b: 8b .byte 0x8b 3c: 84 24 10 test %ah,(%rax,%rdx,1) 3f: f3 repz Code starting with the faulting instruction =========================================== 0: 83 38 03 cmpl $0x3,(%rax) 3: 0f 84 37 fe ff ff je 0xfffffffffffffe40 9: bb ea ff ff ff mov $0xffffffea,%ebx e: eb cc jmp 0xffffffffffffffdc 10: 49 rex.WB 11: 8b .byte 0x8b 12: 84 24 10 test %ah,(%rax,%rdx,1) 15: f3 repz [ 9890.526285] RSP: 0018:ffffb8db09013d68 EFLAGS: 00010246 [ 9890.526291] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9308e0d656c8 [ 9890.526295] RDX: 0000000000000000 RSI: ffffffffab99460b RDI: ffffffffab9a7685 [ 9890.526300] RBP: ffffb8db09013db8 R08: 0000000000000000 R09: 0000000000000873 [ 9890.526304] R10: ffff9308e0d64800 R11: 0000000000000002 R12: ffff9308e5ff6e70 [ 9890.526308] R13: ffff930952500e20 R14: ffff9309192a8c00 R15: 0000000000000000 [ 9890.526313] FS: 0000000000000000(0000) GS:ffff930b4e700000(0000) knlGS:0000000000000000 [ 9890.526316] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 9890.526318] CR2: 0000000000000000 CR3: 0000000391c58005 CR4: 00000000001706f0 [ 9890.526321] Call Trace: [ 9890.526324] <TASK> [ 9890.526327] ? show_regs (arch/x86/kernel/dumpstack.c:479) [ 9890.526335] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 9890.526340] ? page_fault_oops (arch/x86/mm/fault.c:713) [ 9890.526347] ? search_module_extables (kernel/module/main.c:3256 (discriminator 3)) [ 9890.526353] ? ieee80211_start_tx_ba_session (net/mac80211/agg-tx.c:618 (discriminator 1)) mac80211 Signed-off-by: Zong-Zhe Yang <kevin_yang(a)realtek.com> Link: https://patch.msgid.link/20240617115217.22344-1-kevin_yang@realtek.com Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Conflicts: net/mac80211/agg-tx.c [commit a1de64078bf7 add eht_cap to response with EHT, and commit 046d2e7c50e3 add struct ieee80211_link_sta, which lead to context conflicts.] Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/mac80211/agg-tx.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/mac80211/agg-tx.c b/net/mac80211/agg-tx.c index 92e5812daf89..433009b3e8ab 100644 --- a/net/mac80211/agg-tx.c +++ b/net/mac80211/agg-tx.c @@ -599,7 +599,8 @@ int ieee80211_start_tx_ba_session(struct ieee80211_sta *pubsta, u16 tid, return -EINVAL; if (!pubsta->ht_cap.ht_supported && - sta->sdata->vif.bss_conf.chandef.chan->band != NL80211_BAND_6GHZ) + !pubsta->vht_cap.vht_supported && + !pubsta->he_cap.has_he) return -EINVAL; if (WARN_ON_ONCE(!local->ops->ampdu_action)) -- 2.25.1

2 3

[PATCH OLK-5.10 0/1] fix CVE-2024-49954
by Liao Chen 24 Oct '24

24 Oct '24

fix CVE-2024-49954 Thomas Gleixner (1): [Backport] static_call: Replace pointless WARN_ON() in static_call_module_notify() kernel/static_call_inline.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.34.1

2 4

[PATCH openEuler-22.03-LTS-SP1 0/1] fix CVE-2024-49954
by Liao Chen 24 Oct '24

24 Oct '24

fix CVE-2024-49954 Thomas Gleixner (1): [Backport] static_call: Replace pointless WARN_ON() in static_call_module_notify() kernel/static_call_inline.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.34.1

2 2

2025

2024

2023

2022

2021

2020

2019

Kernel