mailweb.openeuler.org
Manage this list

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

Kernel

Threads by month
  • ----- 2025 -----
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2021 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2020 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2019 -----
  • December
kernel@openeuler.org

  • 44 participants
  • 21205 discussions
[PATCH openEuler-1.0-LTS] iio: health: afe4404: Fix oob read in afe4404_[read|write]_raw
by Lin Ruifeng 01 Nov '24

01 Nov '24
From: Wei Yongjun <weiyongjun1(a)huawei.com> stable inclusion from stable-v4.19.268 commit f5575041ec15310bdc50c42b8b22118cc900226e bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYREK CVE: CVE-2022-49032 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit fc92d9e3de0b2d30a3ccc08048a5fad533e4672b ] KASAN report out-of-bounds read as follows: BUG: KASAN: global-out-of-bounds in afe4404_read_raw+0x2ce/0x380 Read of size 4 at addr ffffffffc00e4658 by task cat/278 Call Trace: afe4404_read_raw iio_read_channel_info dev_attr_show The buggy address belongs to the variable: afe4404_channel_leds+0x18/0xffffffffffffe9c0 This issue can be reproduce by singe command: $ cat /sys/bus/i2c/devices/0-0058/iio\:device0/in_intensity6_raw The array size of afe4404_channel_leds and afe4404_channel_offdacs are less than channels, so access with chan->address cause OOB read in afe4404_[read|write]_raw. Fix it by moving access before use them. Fixes: b36e8257641a ("iio: health/afe440x: Use regmap fields") Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com> Acked-by: Andrew Davis <afd(a)ti.com> Link: https://lore.kernel.org/r/20221107152010.95937-1-weiyongjun@huaweicloud.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/iio/health/afe4404.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/iio/health/afe4404.c b/drivers/iio/health/afe4404.c index 11910922e655..56ff178bd07e 100644 --- a/drivers/iio/health/afe4404.c +++ b/drivers/iio/health/afe4404.c @@ -256,20 +256,20 @@ static int afe4404_read_raw(struct iio_dev *indio_dev, int *val, int *val2, long mask) { struct afe4404_data *afe = iio_priv(indio_dev); - unsigned int value_reg = afe4404_channel_values[chan->address]; - unsigned int led_field = afe4404_channel_leds[chan->address]; - unsigned int offdac_field = afe4404_channel_offdacs[chan->address]; + unsigned int value_reg, led_field, offdac_field; int ret; switch (chan->type) { case IIO_INTENSITY: switch (mask) { case IIO_CHAN_INFO_RAW: + value_reg = afe4404_channel_values[chan->address]; ret = regmap_read(afe->regmap, value_reg, val); if (ret) return ret; return IIO_VAL_INT; case IIO_CHAN_INFO_OFFSET: + offdac_field = afe4404_channel_offdacs[chan->address]; ret = regmap_field_read(afe->fields[offdac_field], val); if (ret) return ret; @@ -279,6 +279,7 @@ static int afe4404_read_raw(struct iio_dev *indio_dev, case IIO_CURRENT: switch (mask) { case IIO_CHAN_INFO_RAW: + led_field = afe4404_channel_leds[chan->address]; ret = regmap_field_read(afe->fields[led_field], val); if (ret) return ret; @@ -301,19 +302,20 @@ static int afe4404_write_raw(struct iio_dev *indio_dev, int val, int val2, long mask) { struct afe4404_data *afe = iio_priv(indio_dev); - unsigned int led_field = afe4404_channel_leds[chan->address]; - unsigned int offdac_field = afe4404_channel_offdacs[chan->address]; + unsigned int led_field, offdac_field; switch (chan->type) { case IIO_INTENSITY: switch (mask) { case IIO_CHAN_INFO_OFFSET: + offdac_field = afe4404_channel_offdacs[chan->address]; return regmap_field_write(afe->fields[offdac_field], val); } break; case IIO_CURRENT: switch (mask) { case IIO_CHAN_INFO_RAW: + led_field = afe4404_channel_leds[chan->address]; return regmap_field_write(afe->fields[led_field], val); } break; -- 2.17.1
2 1
0 0
[PATCH openEuler-1.0-LTS] serial: protect uart_port_dtr_rts() in uart_shutdown() too
by Yi Yang 01 Nov '24

01 Nov '24
From: "Jiri Slaby (SUSE)" <jirislaby(a)kernel.org> mainline inclusion from mainline-v6.12-rc1 commit 602babaa84d627923713acaf5f7e9a4369e77473 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYREU CVE: CVE-2024-50058 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected "uart_port_dtr_rts(uport, false);" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks. Signed-off-by: Jiri Slaby (SUSE) <jirislaby(a)kernel.org> Cc: Peter Hurley <peter(a)hurleysoftware.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Link: https://lore.kernel.org/r/20240805102046.307511-3-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/tty/serial/serial_core.c [Conflicts due to 5d4203990737("tty: Convert ->dtr_rts() to take bool argument") and 027b57170bf8("serial: core: Fix initializing and restoring termios speed") not merged] Signed-off-by: Yi Yang <yiyang13(a)huawei.com> --- drivers/tty/serial/serial_core.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c index 3faf643de752..537bcd7c4941 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -287,11 +287,13 @@ static void uart_shutdown(struct tty_struct *tty, struct uart_state *state) /* * Turn off DTR and RTS early. */ - if (uport && uart_console(uport) && tty) - uport->cons->cflag = tty->termios.c_cflag; + if (uport) { + if (uart_console(uport) && tty) + uport->cons->cflag = tty->termios.c_cflag; - if (!tty || C_HUPCL(tty)) - uart_port_dtr_rts(uport, 0); + if (!tty || C_HUPCL(tty)) + uart_port_dtr_rts(uport, 0); + } uart_port_shutdown(port); } -- 2.25.1
2 1
0 0
[PATCH OLK-5.10] serial: protect uart_port_dtr_rts() in uart_shutdown() too
by Yi Yang 01 Nov '24

01 Nov '24
From: "Jiri Slaby (SUSE)" <jirislaby(a)kernel.org> mainline inclusion from mainline-v6.12-rc1 commit 602babaa84d627923713acaf5f7e9a4369e77473 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYREU CVE: CVE-2024-50058 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected "uart_port_dtr_rts(uport, false);" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks. Signed-off-by: Jiri Slaby (SUSE) <jirislaby(a)kernel.org> Cc: Peter Hurley <peter(a)hurleysoftware.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Link: https://lore.kernel.org/r/20240805102046.307511-3-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/tty/serial/serial_core.c [Conflicts due to 5d4203990737("tty: Convert ->dtr_rts() to take bool argument") not merged] Signed-off-by: Yi Yang <yiyang13(a)huawei.com> --- drivers/tty/serial/serial_core.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c index c7adcf97e2a3..6d7d448d0fbf 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -286,14 +286,16 @@ static void uart_shutdown(struct tty_struct *tty, struct uart_state *state) /* * Turn off DTR and RTS early. */ - if (uport && uart_console(uport) && tty) { - uport->cons->cflag = tty->termios.c_cflag; - uport->cons->ispeed = tty->termios.c_ispeed; - uport->cons->ospeed = tty->termios.c_ospeed; - } + if (uport) { + if (uart_console(uport) && tty) { + uport->cons->cflag = tty->termios.c_cflag; + uport->cons->ispeed = tty->termios.c_ispeed; + uport->cons->ospeed = tty->termios.c_ospeed; + } - if (!tty || C_HUPCL(tty)) - uart_port_dtr_rts(uport, 0); + if (!tty || C_HUPCL(tty)) + uart_port_dtr_rts(uport, 0); + } uart_port_shutdown(port); } -- 2.25.1
2 1
0 0
[PATCH openEuler-22.03-LTS-SP1] serial: protect uart_port_dtr_rts() in uart_shutdown() too
by Yi Yang 01 Nov '24

01 Nov '24
From: "Jiri Slaby (SUSE)" <jirislaby(a)kernel.org> mainline inclusion from mainline-v6.12-rc1 commit 602babaa84d627923713acaf5f7e9a4369e77473 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYREU CVE: CVE-2024-50058 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected "uart_port_dtr_rts(uport, false);" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks. Signed-off-by: Jiri Slaby (SUSE) <jirislaby(a)kernel.org> Cc: Peter Hurley <peter(a)hurleysoftware.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Link: https://lore.kernel.org/r/20240805102046.307511-3-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/tty/serial/serial_core.c [Conflicts due to 5d4203990737("tty: Convert ->dtr_rts() to take bool argument") not merged] Signed-off-by: Yi Yang <yiyang13(a)huawei.com> --- drivers/tty/serial/serial_core.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c index 827bb6b2369e..47312fe902cb 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -286,14 +286,16 @@ static void uart_shutdown(struct tty_struct *tty, struct uart_state *state) /* * Turn off DTR and RTS early. */ - if (uport && uart_console(uport) && tty) { - uport->cons->cflag = tty->termios.c_cflag; - uport->cons->ispeed = tty->termios.c_ispeed; - uport->cons->ospeed = tty->termios.c_ospeed; - } + if (uport) { + if (uart_console(uport) && tty) { + uport->cons->cflag = tty->termios.c_cflag; + uport->cons->ispeed = tty->termios.c_ispeed; + uport->cons->ospeed = tty->termios.c_ospeed; + } - if (!tty || C_HUPCL(tty)) - uart_port_dtr_rts(uport, 0); + if (!tty || C_HUPCL(tty)) + uart_port_dtr_rts(uport, 0); + } uart_port_shutdown(port); } -- 2.25.1
2 1
0 0
[openeuler:OLK-5.10 18689/30000] drivers/ub/urma/ubcore/ubcore_dp.c:26:5: warning: no previous prototype for 'ubcore_post_jetty_send_wr'
by kernel test robot 01 Nov '24

01 Nov '24
Hi Yizhen, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: c78205e40443cde6028b0539f30a00fda4167edd commit: 33800c2820ab85fe02800e33f6b3287130278bdf [18689/30000] ub: ubcore add data plane ops api. config: arm64-randconfig-003-20241029 (https://download.01.org/0day-ci/archive/20241101/202411010813.TGMdTWRa-lkp@…) compiler: aarch64-linux-gcc (GCC) 14.1.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241101/202411010813.TGMdTWRa-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/202411010813.TGMdTWRa-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/ub/urma/ubcore/ubcore_dp.c:26:5: warning: no previous prototype for 'ubcore_post_jetty_send_wr' [-Wmissing-prototypes] 26 | int ubcore_post_jetty_send_wr(struct ubcore_jetty *jetty, const struct ubcore_jfs_wr *wr, | ^~~~~~~~~~~~~~~~~~~~~~~~~ >> drivers/ub/urma/ubcore/ubcore_dp.c:42:5: warning: no previous prototype for 'ubcore_post_jetty_recv_wr' [-Wmissing-prototypes] 42 | int ubcore_post_jetty_recv_wr(struct ubcore_jetty *jetty, const struct ubcore_jfr_wr *wr, | ^~~~~~~~~~~~~~~~~~~~~~~~~ >> drivers/ub/urma/ubcore/ubcore_dp.c:58:5: warning: no previous prototype for 'ubcore_post_jfs_wr' [-Wmissing-prototypes] 58 | int ubcore_post_jfs_wr(struct ubcore_jfs *jfs, const struct ubcore_jfs_wr *wr, | ^~~~~~~~~~~~~~~~~~ >> drivers/ub/urma/ubcore/ubcore_dp.c:74:5: warning: no previous prototype for 'ubcore_post_jfr_wr' [-Wmissing-prototypes] 74 | int ubcore_post_jfr_wr(struct ubcore_jfr *jfr, const struct ubcore_jfr_wr *wr, | ^~~~~~~~~~~~~~~~~~ >> drivers/ub/urma/ubcore/ubcore_dp.c:90:5: warning: no previous prototype for 'ubcore_poll_jfc' [-Wmissing-prototypes] 90 | int ubcore_poll_jfc(struct ubcore_jfc *jfc, int cr_cnt, struct ubcore_cr *cr) | ^~~~~~~~~~~~~~~ drivers/ub/urma/ubcore/ubcore_dp.c:105:5: warning: no previous prototype for 'ubcore_rearm_jfc' [-Wmissing-prototypes] 105 | int ubcore_rearm_jfc(struct ubcore_jfc *jfc, bool solicited_only) | ^~~~~~~~~~~~~~~~ vim +/ubcore_post_jetty_send_wr +26 drivers/ub/urma/ubcore/ubcore_dp.c 25 > 26 int ubcore_post_jetty_send_wr(struct ubcore_jetty *jetty, const struct ubcore_jfs_wr *wr, 27 struct ubcore_jfs_wr **bad_wr) 28 { 29 struct ubcore_ops *dev_ops; 30 31 if (jetty == NULL || jetty->ub_dev == NULL || jetty->ub_dev->ops == NULL || 32 jetty->ub_dev->ops->post_jetty_send_wr == NULL || wr == NULL || bad_wr == NULL) { 33 ubcore_log_err("Invalid parameter"); 34 return -EINVAL; 35 } 36 37 dev_ops = jetty->ub_dev->ops; 38 return dev_ops->post_jetty_send_wr(jetty, wr, bad_wr); 39 } 40 EXPORT_SYMBOL(ubcore_post_jetty_send_wr); 41 > 42 int ubcore_post_jetty_recv_wr(struct ubcore_jetty *jetty, const struct ubcore_jfr_wr *wr, 43 struct ubcore_jfr_wr **bad_wr) 44 { 45 struct ubcore_ops *dev_ops; 46 47 if (jetty == NULL || jetty->ub_dev == NULL || jetty->ub_dev->ops == NULL || 48 jetty->ub_dev->ops->post_jetty_recv_wr == NULL || wr == NULL || bad_wr == NULL) { 49 ubcore_log_err("Invalid parameter"); 50 return -EINVAL; 51 } 52 53 dev_ops = jetty->ub_dev->ops; 54 return dev_ops->post_jetty_recv_wr(jetty, wr, bad_wr); 55 } 56 EXPORT_SYMBOL(ubcore_post_jetty_recv_wr); 57 > 58 int ubcore_post_jfs_wr(struct ubcore_jfs *jfs, const struct ubcore_jfs_wr *wr, 59 struct ubcore_jfs_wr **bad_wr) 60 { 61 struct ubcore_ops *dev_ops; 62 63 if (jfs == NULL || jfs->ub_dev == NULL || jfs->ub_dev->ops == NULL || 64 jfs->ub_dev->ops->post_jfs_wr == NULL || wr == NULL || bad_wr == NULL) { 65 ubcore_log_err("Invalid parameter"); 66 return -EINVAL; 67 } 68 69 dev_ops = jfs->ub_dev->ops; 70 return dev_ops->post_jfs_wr(jfs, wr, bad_wr); 71 } 72 EXPORT_SYMBOL(ubcore_post_jfs_wr); 73 > 74 int ubcore_post_jfr_wr(struct ubcore_jfr *jfr, const struct ubcore_jfr_wr *wr, 75 struct ubcore_jfr_wr **bad_wr) 76 { 77 struct ubcore_ops *dev_ops; 78 79 if (jfr == NULL || jfr->ub_dev == NULL || jfr->ub_dev->ops == NULL || 80 jfr->ub_dev->ops->post_jfr_wr == NULL || wr == NULL || bad_wr == NULL) { 81 ubcore_log_err("Invalid parameter"); 82 return -EINVAL; 83 } 84 85 dev_ops = jfr->ub_dev->ops; 86 return dev_ops->post_jfr_wr(jfr, wr, bad_wr); 87 } 88 EXPORT_SYMBOL(ubcore_post_jfr_wr); 89 > 90 int ubcore_poll_jfc(struct ubcore_jfc *jfc, int cr_cnt, struct ubcore_cr *cr) 91 { 92 struct ubcore_ops *dev_ops; 93 94 if (jfc == NULL || jfc->ub_dev == NULL || jfc->ub_dev->ops == NULL || 95 jfc->ub_dev->ops->poll_jfc == NULL || cr == NULL) { 96 ubcore_log_err("Invalid parameter"); 97 return -EINVAL; 98 } 99 100 dev_ops = jfc->ub_dev->ops; 101 return dev_ops->poll_jfc(jfc, cr_cnt, cr); 102 } 103 EXPORT_SYMBOL(ubcore_poll_jfc); 104 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[openeuler:OLK-5.10 18663/30000] drivers/ub/urma/ubcore/ubcore_tp.c:40:17: warning: no previous prototype for 'ubcore_get_mtu'
by kernel test robot 01 Nov '24

01 Nov '24
Hi Yizhen, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: c78205e40443cde6028b0539f30a00fda4167edd commit: 832e9fe8cf1ed02211ff43bd4f3f16ddc2d69969 [18663/30000] ub: ubcore add create/delete tp table api config: arm64-randconfig-003-20241029 (https://download.01.org/0day-ci/archive/20241101/202411010411.aKWhEHwD-lkp@…) compiler: aarch64-linux-gcc (GCC) 14.1.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241101/202411010411.aKWhEHwD-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/202411010411.aKWhEHwD-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/ub/urma/ubcore/ubcore_tp.c:40:17: warning: no previous prototype for 'ubcore_get_mtu' [-Wmissing-prototypes] 40 | enum ubcore_mtu ubcore_get_mtu(int mtu) | ^~~~~~~~~~~~~~ drivers/ub/urma/ubcore/ubcore_tp.c:75:19: warning: no previous prototype for 'ubcore_create_vtp' [-Wmissing-prototypes] 75 | struct ubcore_tp *ubcore_create_vtp(struct ubcore_device *dev, const union ubcore_eid *remote_eid, | ^~~~~~~~~~~~~~~~~ drivers/ub/urma/ubcore/ubcore_tp.c:83:5: warning: no previous prototype for 'ubcore_destroy_vtp' [-Wmissing-prototypes] 83 | int ubcore_destroy_vtp(struct ubcore_tp *vtp) | ^~~~~~~~~~~~~~~~~~ vim +/ubcore_get_mtu +40 drivers/ub/urma/ubcore/ubcore_tp.c c75b0bccca77778 Yizhen Fan 2023-09-14 39 c75b0bccca77778 Yizhen Fan 2023-09-14 @40 enum ubcore_mtu ubcore_get_mtu(int mtu) c75b0bccca77778 Yizhen Fan 2023-09-14 41 { c75b0bccca77778 Yizhen Fan 2023-09-14 42 mtu = mtu - UB_PROTOCOL_HEAD_BYTES; c75b0bccca77778 Yizhen Fan 2023-09-14 43 c75b0bccca77778 Yizhen Fan 2023-09-14 44 if (mtu >= ubcore_mtu_enum_to_int(UBCORE_MTU_8192)) c75b0bccca77778 Yizhen Fan 2023-09-14 45 return UBCORE_MTU_8192; c75b0bccca77778 Yizhen Fan 2023-09-14 46 if (mtu >= ubcore_mtu_enum_to_int(UBCORE_MTU_4096)) c75b0bccca77778 Yizhen Fan 2023-09-14 47 return UBCORE_MTU_4096; c75b0bccca77778 Yizhen Fan 2023-09-14 48 else if (mtu >= ubcore_mtu_enum_to_int(UBCORE_MTU_2048)) c75b0bccca77778 Yizhen Fan 2023-09-14 49 return UBCORE_MTU_2048; c75b0bccca77778 Yizhen Fan 2023-09-14 50 else if (mtu >= ubcore_mtu_enum_to_int(UBCORE_MTU_1024)) c75b0bccca77778 Yizhen Fan 2023-09-14 51 return UBCORE_MTU_1024; c75b0bccca77778 Yizhen Fan 2023-09-14 52 else if (mtu >= ubcore_mtu_enum_to_int(UBCORE_MTU_512)) c75b0bccca77778 Yizhen Fan 2023-09-14 53 return UBCORE_MTU_512; c75b0bccca77778 Yizhen Fan 2023-09-14 54 else if (mtu >= ubcore_mtu_enum_to_int(UBCORE_MTU_256)) c75b0bccca77778 Yizhen Fan 2023-09-14 55 return UBCORE_MTU_256; c75b0bccca77778 Yizhen Fan 2023-09-14 56 else c75b0bccca77778 Yizhen Fan 2023-09-14 57 return 0; c75b0bccca77778 Yizhen Fan 2023-09-14 58 } c75b0bccca77778 Yizhen Fan 2023-09-14 59 EXPORT_SYMBOL(ubcore_get_mtu); c75b0bccca77778 Yizhen Fan 2023-09-14 60 :::::: The code at line 40 was first introduced by commit :::::: c75b0bccca77778d5663004cb19d3dd31ef71f0a ub: ubcore add get_mtu and other APIs that will be used by the driver. :::::: TO: Yizhen Fan <fanyizhen(a)huawei.com> :::::: CC: fanyizhen1995 <en_0015767(a)163.com> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[openeuler:openEuler-1.0-LTS 15253/23924] arch/arm64/kernel/mpam/mpam_resctrl.c:358:1: warning: conflicting types for 'mpam_get_raw_resctrl_resource' due to enum/integer mismatch; have 'struct raw_resctrl_resource *(enum resctrl_resource_level)'
by kernel test robot 01 Nov '24

01 Nov '24
tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: e73db5f1f4d00d788085541fcfcb33402ee9221c commit: a453ee059c9d7c7372b6f413ef152b9ea8ee800e [15253/23924] arm64/mpam: Init resctrl resources' info from resctrl_res selected config: arm64-randconfig-001-20241029 (https://download.01.org/0day-ci/archive/20241101/202411010258.ysot0OR8-lkp@…) compiler: aarch64-linux-gcc (GCC) 14.1.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241101/202411010258.ysot0OR8-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/202411010258.ysot0OR8-lkp@intel.com/ All warnings (new ones prefixed by >>): >> arch/arm64/kernel/mpam/mpam_resctrl.c:358:1: warning: conflicting types for 'mpam_get_raw_resctrl_resource' due to enum/integer mismatch; have 'struct raw_resctrl_resource *(enum resctrl_resource_level)' [-Wenum-int-mismatch] 358 | mpam_get_raw_resctrl_resource(enum resctrl_resource_level level) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from arch/arm64/kernel/mpam/mpam_resctrl.c:47: arch/arm64/kernel/mpam/mpam_internal.h:127:1: note: previous declaration of 'mpam_get_raw_resctrl_resource' with type 'struct raw_resctrl_resource *(u32)' {aka 'struct raw_resctrl_resource *(unsigned int)'} 127 | mpam_get_raw_resctrl_resource(u32 level); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/arm64/kernel/mpam/mpam_resctrl.c:784:5: warning: no previous prototype for 'cpus_ctrl_write' [-Wmissing-prototypes] 784 | int cpus_ctrl_write(struct rdtgroup *rdtgrp, cpumask_var_t newmask, | ^~~~~~~~~~~~~~~ arch/arm64/kernel/mpam/mpam_resctrl.c:872:5: warning: no previous prototype for 'cpus_mon_write' [-Wmissing-prototypes] 872 | int cpus_mon_write(struct rdtgroup *rdtgrp, cpumask_var_t newmask, | ^~~~~~~~~~~~~~ arch/arm64/kernel/mpam/mpam_resctrl.c: In function 'rdt_last_cmd_printf': arch/arm64/kernel/mpam/mpam_resctrl.c:1016:9: warning: function 'rdt_last_cmd_printf' might be a candidate for 'gnu_printf' format attribute [-Wsuggest-attribute=format] 1016 | seq_buf_vprintf(&last_cmd_status, fmt, ap); | ^~~~~~~~~~~~~~~ arch/arm64/kernel/mpam/mpam_resctrl.c: At top level: arch/arm64/kernel/mpam/mpam_resctrl.c:1089:5: warning: no previous prototype for 'resctrl_ctrlmon_enable' [-Wmissing-prototypes] 1089 | int resctrl_ctrlmon_enable(struct kernfs_node *parent_kn, | ^~~~~~~~~~~~~~~~~~~~~~ arch/arm64/kernel/mpam/mpam_resctrl.c:1117:6: warning: no previous prototype for 'resctrl_ctrlmon_disable' [-Wmissing-prototypes] 1117 | void resctrl_ctrlmon_disable(struct kernfs_node *kn_mondata, | ^~~~~~~~~~~~~~~~~~~~~~~ vim +358 arch/arm64/kernel/mpam/mpam_resctrl.c 356 357 struct raw_resctrl_resource * > 358 mpam_get_raw_resctrl_resource(enum resctrl_resource_level level) 359 { 360 if (level >= RDT_NUM_RESOURCES) 361 return NULL; 362 363 return &raw_resctrl_resources_all[level]; 364 } 365 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[openeuler:OLK-5.10 18659/30000] drivers/ub/urma/uburma/uburma_cmd.c:180:6: warning: no previous prototype for 'uburma_jetty_event_cb'
by kernel test robot 01 Nov '24

01 Nov '24
Hi Yizhen, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: c78205e40443cde6028b0539f30a00fda4167edd commit: c3af5be3e72710b357d9f23a5bdcafe8f96d6dfd [18659/30000] ub: uburma add cmd create jetty implementation. config: arm64-randconfig-003-20241029 (https://download.01.org/0day-ci/archive/20241101/202411010152.inffSTWn-lkp@…) compiler: aarch64-linux-gcc (GCC) 14.1.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241101/202411010152.inffSTWn-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/202411010152.inffSTWn-lkp@intel.com/ All warnings (new ones prefixed by >>): drivers/ub/urma/uburma/uburma_cmd.c:144:6: warning: no previous prototype for 'uburma_jfc_event_cb' [-Wmissing-prototypes] 144 | void uburma_jfc_event_cb(struct ubcore_event *event, struct ubcore_ucontext *ctx) | ^~~~~~~~~~~~~~~~~~~ drivers/ub/urma/uburma/uburma_cmd.c:156:6: warning: no previous prototype for 'uburma_jfs_event_cb' [-Wmissing-prototypes] 156 | void uburma_jfs_event_cb(struct ubcore_event *event, struct ubcore_ucontext *ctx) | ^~~~~~~~~~~~~~~~~~~ drivers/ub/urma/uburma/uburma_cmd.c:168:6: warning: no previous prototype for 'uburma_jfr_event_cb' [-Wmissing-prototypes] 168 | void uburma_jfr_event_cb(struct ubcore_event *event, struct ubcore_ucontext *ctx) | ^~~~~~~~~~~~~~~~~~~ >> drivers/ub/urma/uburma/uburma_cmd.c:180:6: warning: no previous prototype for 'uburma_jetty_event_cb' [-Wmissing-prototypes] 180 | void uburma_jetty_event_cb(struct ubcore_event *event, struct ubcore_ucontext *ctx) | ^~~~~~~~~~~~~~~~~~~~~ vim +/uburma_jetty_event_cb +180 drivers/ub/urma/uburma/uburma_cmd.c 179 > 180 void uburma_jetty_event_cb(struct ubcore_event *event, struct ubcore_ucontext *ctx) 181 { 182 struct uburma_jetty_uobj *jetty_uobj; 183 184 if (event->element.jetty == NULL) 185 return; 186 187 jetty_uobj = (struct uburma_jetty_uobj *)event->element.jetty->jetty_cfg.jetty_context; 188 uburma_write_async_event(ctx, event->element.jetty->urma_jetty, event->event_type, 189 &jetty_uobj->async_event_list, &jetty_uobj->async_events_reported); 190 } 191 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[openeuler:OLK-5.10 19333/30000] fs/ext4/fast_commit.o: warning: objtool: __ext4_fc_track_unlink()+0x275: unreachable instruction
by kernel test robot 31 Oct '24

31 Oct '24
tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: c67d418d86fea7b8c2a11c7273229ffb0a7a57ed commit: f2c902d8c653f8021f9761092a27f7b9db42b662 [19333/30000] tracing: Make tracepoint lockdep check actually test something config: x86_64-buildonly-randconfig-001-20241030 (https://download.01.org/0day-ci/archive/20241031/202410312220.K72H6v5s-lkp@…) compiler: clang version 19.1.2 (https://github.com/llvm/llvm-project 7ba7d8e2f7b6445b60679da826210cdde29eaf8b) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241031/202410312220.K72H6v5s-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/202410312220.K72H6v5s-lkp@intel.com/ All warnings (new ones prefixed by >>): >> fs/ext4/fast_commit.o: warning: objtool: __ext4_fc_track_unlink()+0x275: unreachable instruction -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[PATCH openEuler-1.0-LTS] NFSv4: release seqid when open failed for nfs4.0
by Li Lingfeng 31 Oct '24

31 Oct '24
From: Yang Erkun <yangerkun(a)huaweicloud.com> hulk inclusion category: bugfix bugzilla: http://openeuler.huawei.com/bugzilla/show_bug.cgi?id=190327 CVE: NA -------------------------------- Two threads that work with the same cred try to open different files concurrently, they will utilize the same nfs4_state_owner. And in order to sequential open request send to server, the second task will fall into RPC_TASK_QUEUED in nfs_wait_on_sequence since there is already one work doing the open operation. Furthermore, the second task will wait until the first task completes its work, call rpc_wake_up_queued_task in nfs_release_seqid to wake up the second task, allowing it to complete the remaining open operation. The preceding logic does not cause any problems under normal circumstances. However, when once we force an unmount using `umount -f`, the function nfs_umount_begin attempts to kill all tasks by calling rpc_signal_task. This help wake up the second task, but it sets the status to -ERESTARTSYS. This status prevents `nfs4_open_release` from calling `nfs4_opendata_to_nfs4_state`. Consequently, while the second task will be freed, the original tasks will still exist in sequence->list(see nfs_release_seqid). Latter, when the first thread calls nfs_release_seqid and attempts to wake up the second task, it will trigger the uaf. To resolve this issue, ensure rpc_task will remove it from sequence->list in nfs4_open_release when open failed, besides, we can only wakeup the next rpc_task, or use-after-free will happen too since privious rpc_task may be released too. ================================================================== BUG: KASAN: slab-use-after-free in rpc_wake_up_queued_task+0xbb/0xc0 Read of size 8 at addr ff11000007639930 by task bash/792 CPU: 0 UID: 0 PID: 792 Comm: bash Tainted: G B W 6.11.0-09960-gd10b58fe53dc-dirty #10 Tainted: [B]=BAD_PAGE, [W]=WARN Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0xa3/0x120 print_address_description.constprop.0+0x63/0x510 print_report+0xf5/0x360 kasan_report+0xd9/0x140 __asan_report_load8_noabort+0x24/0x40 rpc_wake_up_queued_task+0xbb/0xc0 nfs_release_seqid+0x1e1/0x2f0 nfs_free_seqid+0x1a/0x40 nfs4_opendata_free+0xc6/0x3e0 _nfs4_do_open.isra.0+0xbe3/0x1380 nfs4_do_open+0x28b/0x620 nfs4_atomic_open+0x2c6/0x3a0 nfs_atomic_open+0x4f8/0x1180 atomic_open+0x186/0x4e0 lookup_open.isra.0+0x3e7/0x15b0 open_last_lookups+0x85d/0x1260 path_openat+0x151/0x7b0 do_filp_open+0x1e0/0x310 do_sys_openat2+0x178/0x1f0 do_sys_open+0xa2/0x100 __x64_sys_openat+0xa8/0x120 x64_sys_call+0x2507/0x4540 do_syscall_64+0xa7/0x240 entry_SYSCALL_64_after_hwframe+0x76/0x7e ... Allocated by task 767: kasan_save_stack+0x3b/0x70 kasan_save_track+0x1c/0x40 kasan_save_alloc_info+0x44/0x70 __kasan_slab_alloc+0xaf/0xc0 kmem_cache_alloc_noprof+0x1e0/0x4f0 rpc_new_task+0xe7/0x220 rpc_run_task+0x27/0x7d0 nfs4_run_open_task+0x477/0x810 _nfs4_proc_open+0xc0/0x6d0 _nfs4_open_and_get_state+0x178/0xc50 _nfs4_do_open.isra.0+0x47f/0x1380 nfs4_do_open+0x28b/0x620 nfs4_atomic_open+0x2c6/0x3a0 nfs_atomic_open+0x4f8/0x1180 atomic_open+0x186/0x4e0 lookup_open.isra.0+0x3e7/0x15b0 open_last_lookups+0x85d/0x1260 path_openat+0x151/0x7b0 do_filp_open+0x1e0/0x310 do_sys_openat2+0x178/0x1f0 do_sys_open+0xa2/0x100 __x64_sys_openat+0xa8/0x120 x64_sys_call+0x2507/0x4540 do_syscall_64+0xa7/0x240 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 767: kasan_save_stack+0x3b/0x70 kasan_save_track+0x1c/0x40 kasan_save_free_info+0x43/0x80 __kasan_slab_free+0x4f/0x90 kmem_cache_free+0x199/0x4f0 mempool_free_slab+0x1f/0x30 mempool_free+0xdf/0x3d0 rpc_free_task+0x12d/0x180 rpc_final_put_task+0x10e/0x150 rpc_do_put_task+0x63/0x80 rpc_put_task+0x18/0x30 nfs4_run_open_task+0x4f4/0x810 _nfs4_proc_open+0xc0/0x6d0 _nfs4_open_and_get_state+0x178/0xc50 _nfs4_do_open.isra.0+0x47f/0x1380 nfs4_do_open+0x28b/0x620 nfs4_atomic_open+0x2c6/0x3a0 nfs_atomic_open+0x4f8/0x1180 atomic_open+0x186/0x4e0 lookup_open.isra.0+0x3e7/0x15b0 open_last_lookups+0x85d/0x1260 path_openat+0x151/0x7b0 do_filp_open+0x1e0/0x310 do_sys_openat2+0x178/0x1f0 do_sys_open+0xa2/0x100 __x64_sys_openat+0xa8/0x120 x64_sys_call+0x2507/0x4540 do_syscall_64+0xa7/0x240 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: 24ac23ab88df ("NFSv4: Convert open() into an asynchronous RPC call") Signed-off-by: Yang Erkun <yangerkun(a)huaweicloud.com> Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- fs/nfs/nfs4_fs.h | 1 + fs/nfs/nfs4proc.c | 2 ++ fs/nfs/nfs4state.c | 18 ++++++++++++++++++ 3 files changed, 21 insertions(+) diff --git a/fs/nfs/nfs4_fs.h b/fs/nfs/nfs4_fs.h index d22176d87448..586428cca20b 100644 --- a/fs/nfs/nfs4_fs.h +++ b/fs/nfs/nfs4_fs.h @@ -505,6 +505,7 @@ extern struct nfs_seqid *nfs_alloc_seqid(struct nfs_seqid_counter *counter, gfp_ extern int nfs_wait_on_sequence(struct nfs_seqid *seqid, struct rpc_task *task); extern void nfs_increment_open_seqid(int status, struct nfs_seqid *seqid); extern void nfs_increment_lock_seqid(int status, struct nfs_seqid *seqid); +extern void nfs_release_seqid_inorder(struct nfs_seqid *seqid); extern void nfs_release_seqid(struct nfs_seqid *seqid); extern void nfs_free_seqid(struct nfs_seqid *seqid); extern int nfs4_setup_sequence(struct nfs_client *client, diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c index ef9e80928f2a..b19a738dd2e1 100644 --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -2411,6 +2411,8 @@ static void nfs4_open_release(void *calldata) struct nfs4_opendata *data = calldata; struct nfs4_state *state = NULL; + if (data->rpc_status != 0 || !data->rpc_done) + nfs_release_seqid_inorder(data->o_arg.seqid); /* If this request hasn't been cancelled, do nothing */ if (!data->cancelled) goto out_free; diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c index c843917f8e2c..6a5479453256 100644 --- a/fs/nfs/nfs4state.c +++ b/fs/nfs/nfs4state.c @@ -1103,6 +1103,24 @@ struct nfs_seqid *nfs_alloc_seqid(struct nfs_seqid_counter *counter, gfp_t gfp_m return new; } +void nfs_release_seqid_inorder(struct nfs_seqid *seqid) +{ + struct nfs_seqid_counter *sequence; + + if (seqid == NULL || list_empty(&seqid->list)) + return; + sequence = seqid->sequence; + spin_lock(&sequence->lock); + if (!list_is_last(&seqid->list, &sequence->list)) { + struct nfs_seqid *next; + + next = list_next_entry(seqid, list); + rpc_wake_up_queued_task(&sequence->wait, next->task); + } + list_del_init(&seqid->list); + spin_unlock(&sequence->lock); +} + void nfs_release_seqid(struct nfs_seqid *seqid) { struct nfs_seqid_counter *sequence; -- 2.31.1
2 1
0 0
  • ← Newer
  • 1
  • ...
  • 709
  • 710
  • 711
  • 712
  • 713
  • 714
  • 715
  • ...
  • 2121
  • Older →

HyperKitty Powered by HyperKitty