April 2024 - Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()
by Baogen Shang 30 Apr '24

30 Apr '24

From: Justin Tee <justin.tee(a)broadcom.com> stable inclusion from stable-v5.10.215 commit c473288f27d15014447de5a891bdf22a0695847a category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9J6AL CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… ------------------------- [ Upstream commit 2ae917d4bcab80ab304b774d492e2fcd6c52c06b ] The call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an unsuccessful status. In such cases, the elsiocb is not issued, the completion is not called, and thus the elsiocb resource is leaked. Check return value after calling lpfc_sli4_resume_rpi() and conditionally release the elsiocb resource. Signed-off-by: Justin Tee <justin.tee(a)broadcom.com> Link: https://lore.kernel.org/r/20240131185112.149731-3-justintee8345@gmail.com Reviewed-by: Himanshu Madhani <himanshu.madhani(a)oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Baogen Shang <baogen.shang(a)windriver.com> --- drivers/scsi/lpfc/lpfc_nportdisc.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_nportdisc.c b/drivers/scsi/lpfc/lpfc_nportdisc.c index 1e22364a31fc..d6287c58d504 100644 --- a/drivers/scsi/lpfc/lpfc_nportdisc.c +++ b/drivers/scsi/lpfc/lpfc_nportdisc.c @@ -784,8 +784,10 @@ lpfc_rcv_padisc(struct lpfc_vport *vport, struct lpfc_nodelist *ndlp, /* Save the ELS cmd */ elsiocb->drvrTimeout = cmd; - lpfc_sli4_resume_rpi(ndlp, - lpfc_mbx_cmpl_resume_rpi, elsiocb); + if (lpfc_sli4_resume_rpi(ndlp, + lpfc_mbx_cmpl_resume_rpi, + elsiocb)) + kfree(elsiocb); goto out; } } -- 2.33.0

1 0

[PATCH OLK-5.10] scsi: lpfc: Fix possible file string name overflow when updating firmware
by Baogen Shang 30 Apr '24

30 Apr '24

From: Justin Tee <justin.tee(a)broadcom.com> stable inclusion from stable-v5.10.215 commit 9bc7617a0d46f5c9e070cb93b08f8036c86aaaa1 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9J6AL CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… ------------------------- [ Upstream commit f5779b529240b715f0e358489ad0ed933bf77c97 ] Because file_name and phba->ModelName are both declared a size 80 bytes, the extra ".grp" file extension could cause an overflow into file_name. Define a ELX_FW_NAME_SIZE macro with value 84. 84 incorporates the 4 extra characters from ".grp". file_name is changed to be declared as a char and initialized to zeros i.e. null chars. Signed-off-by: Justin Tee <justin.tee(a)broadcom.com> Link: https://lore.kernel.org/r/20231031191224.150862-3-justintee8345@gmail.com Reviewed-by: Himanshu Madhani <himanshu.madhani(a)oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Baogen Shang <baogen.shang(a)windriver.com> --- drivers/scsi/lpfc/lpfc.h | 1 + drivers/scsi/lpfc/lpfc_init.c | 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc.h b/drivers/scsi/lpfc/lpfc.h index 03bc472f302a..cf69f831a725 100644 --- a/drivers/scsi/lpfc/lpfc.h +++ b/drivers/scsi/lpfc/lpfc.h @@ -32,6 +32,7 @@ struct lpfc_sli2_slim; #define ELX_MODEL_NAME_SIZE 80 +#define ELX_FW_NAME_SIZE 84 #define LPFC_PCI_DEV_LP 0x1 #define LPFC_PCI_DEV_OC 0x2 diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c index 1bb3c96a04bd..5f2009327a59 100644 --- a/drivers/scsi/lpfc/lpfc_init.c +++ b/drivers/scsi/lpfc/lpfc_init.c @@ -13026,7 +13026,7 @@ lpfc_write_firmware(const struct firmware *fw, void *context) int lpfc_sli4_request_firmware_update(struct lpfc_hba *phba, uint8_t fw_upgrade) { - uint8_t file_name[ELX_MODEL_NAME_SIZE]; + char file_name[ELX_FW_NAME_SIZE] = {0}; int ret; const struct firmware *fw; @@ -13035,7 +13035,7 @@ lpfc_sli4_request_firmware_update(struct lpfc_hba *phba, uint8_t fw_upgrade) LPFC_SLI_INTF_IF_TYPE_2) return -EPERM; - snprintf(file_name, ELX_MODEL_NAME_SIZE, "%s.grp", phba->ModelName); + scnprintf(file_name, sizeof(file_name), "%s.grp", phba->ModelName); if (fw_upgrade == INT_FW_UPGRADE) { ret = request_firmware_nowait(THIS_MODULE, FW_ACTION_HOTPLUG, -- 2.33.0

1 0

[openeuler:OLK-6.6 6858/7643] drivers/char/ipmi/ipmi_bt_sm.c:194:11: error: call to undeclared function 'acpi_evaluate_integer'; ISO C99 and later do not support implicit function declarations
by kernel test robot 30 Apr '24

30 Apr '24

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 3fd472966bcc21f40dc20bb47c7ad18392fbec05 commit: 6449ff7a5a2b148bc0a60efb3f0d723aaeceaae6 [6858/7643] ipmi: Errata workaround to prevent SMS message processing timeout config: arm64-randconfig-r053-20240430 (https://download.01.org/0day-ci/archive/20240430/202404301314.Y3h2lmDN-lkp@…) compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project 37ae4ad0eef338776c7e2cffb3896153d43dcd90) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240430/202404301314.Y3h2lmDN-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/202404301314.Y3h2lmDN-lkp@intel.com/ All errors (new ones prefixed by >>): >> drivers/char/ipmi/ipmi_bt_sm.c:194:11: error: call to undeclared function 'acpi_evaluate_integer'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 194 | status = acpi_evaluate_integer(handle, "SATN", NULL, &tmp); | ^ drivers/char/ipmi/ipmi_bt_sm.c:194:11: note: did you mean 'acpi_evaluate_object'? include/acpi/acpixf.h:550:8: note: 'acpi_evaluate_object' declared here 550 | acpi_evaluate_object(acpi_handle object, | ^ include/acpi/platform/aclinux.h:93:21: note: expanded from macro 'ACPI_EXTERNAL_RETURN_STATUS' 93 | static ACPI_INLINE prototype {return(AE_NOT_CONFIGURED);} | ^ 1 error generated. vim +/acpi_evaluate_integer +194 drivers/char/ipmi/ipmi_bt_sm.c 177 178 #ifdef CONFIG_HISILICON_ERRATUM_162102203 179 /* 180 * To confirm whether the SMS_ATN flag needs to be stored and get 181 * quirk through the method reported by the BIOS. Because in special 182 * cases SMS_ATN flag bits may be lost before being processed. 183 */ 184 static bool get_sms_atn_quirk(struct si_sm_io *io) 185 { 186 acpi_handle handle; 187 acpi_status status; 188 unsigned long long tmp; 189 190 handle = ACPI_HANDLE(io->dev); 191 if (!handle) 192 return false; 193 > 194 status = acpi_evaluate_integer(handle, "SATN", NULL, &tmp); 195 if (ACPI_FAILURE(status)) 196 return false; 197 else if (tmp != 1) 198 return false; 199 200 return true; 201 } 202 #endif 203 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:openEuler-1.0-LTS 21355/22260] drivers/gpio/gpio-phytium-platform.c:111:2-3: Unneeded semicolon
by kernel test robot 30 Apr '24

30 Apr '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 534530510857129d59e723e50cc93349b4a59fb2 commit: 00711bad7e372a30c4975ba43811ffa666aff0e1 [21355/22260] gpio: add phytium gpio driver config: arm64-randconfig-r054-20240430 (https://download.01.org/0day-ci/archive/20240430/202404301203.LIsGwT62-lkp@…) compiler: aarch64-linux-gcc (GCC) 13.2.0 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/202404301203.LIsGwT62-lkp@intel.com/ cocci warnings: (new ones prefixed by >>) >> drivers/gpio/gpio-phytium-platform.c:111:2-3: Unneeded semicolon vim +111 drivers/gpio/gpio-phytium-platform.c 35 36 static int phytium_gpio_probe(struct platform_device *pdev) 37 { 38 struct device *dev = &pdev->dev; 39 struct resource *res; 40 struct phytium_gpio *gpio; 41 struct gpio_irq_chip *girq; 42 struct fwnode_handle *fwnode; 43 int err, irq_count; 44 45 gpio = devm_kzalloc(&pdev->dev, sizeof(*gpio), GFP_KERNEL); 46 if (!gpio) 47 return -ENOMEM; 48 49 res = platform_get_resource(pdev, IORESOURCE_MEM, 0); 50 gpio->regs = devm_ioremap_resource(&pdev->dev, res); 51 if (IS_ERR(gpio->regs)) 52 return PTR_ERR(gpio->regs); 53 54 if (!device_get_child_node_count(dev)) 55 return -ENODEV; 56 57 device_for_each_child_node(dev, fwnode) { 58 int idx; 59 60 if (fwnode_property_read_u32(fwnode, "reg", &idx) || 61 idx >= MAX_NPORTS) { 62 dev_err(dev, "missing/invalid port index\n"); 63 fwnode_handle_put(fwnode); 64 return -EINVAL; 65 } 66 67 if (fwnode_property_read_u32(fwnode, "nr-gpios", 68 &gpio->ngpio[idx])) { 69 dev_info(dev, 70 "failed to get number of gpios for Port%c\n", 71 idx ? 'B' : 'A'); 72 gpio->ngpio[idx] = NGPIO_DEFAULT; 73 } 74 } 75 76 /* irq_chip support */ 77 gpio->irq_chip.name = dev_name(dev); 78 gpio->irq_chip.irq_ack = phytium_gpio_irq_ack; 79 gpio->irq_chip.irq_mask = phytium_gpio_irq_mask; 80 gpio->irq_chip.irq_unmask = phytium_gpio_irq_unmask; 81 gpio->irq_chip.irq_set_type = phytium_gpio_irq_set_type; 82 gpio->irq_chip.irq_enable = phytium_gpio_irq_enable; 83 gpio->irq_chip.irq_disable = phytium_gpio_irq_disable; 84 #ifdef CONFIG_SMP 85 gpio->irq_chip.irq_set_affinity = phytium_gpio_irq_set_affinity; 86 #endif 87 raw_spin_lock_init(&gpio->lock); 88 89 gpio->gc.base = -1; 90 gpio->gc.get_direction = phytium_gpio_get_direction; 91 gpio->gc.direction_input = phytium_gpio_direction_input; 92 gpio->gc.direction_output = phytium_gpio_direction_output; 93 gpio->gc.get = phytium_gpio_get; 94 gpio->gc.set = phytium_gpio_set; 95 gpio->gc.ngpio = gpio->ngpio[0] + gpio->ngpio[1]; 96 gpio->gc.label = dev_name(dev); 97 gpio->gc.parent = dev; 98 gpio->gc.owner = THIS_MODULE; 99 100 girq = &gpio->gc.irq; 101 girq->handler = handle_bad_irq; 102 girq->default_type = IRQ_TYPE_NONE; 103 104 for (irq_count = 0; irq_count < gpio->ngpio[0]; irq_count++) { 105 gpio->irq[irq_count] = -ENXIO; 106 gpio->irq[irq_count] = platform_get_irq(pdev, irq_count); 107 if (gpio->irq[irq_count] < 0) { 108 dev_warn(dev, "no irq is found.\n"); 109 break; 110 } > 111 }; 112 113 girq->num_parents = irq_count; 114 girq->parents = gpio->irq; 115 girq->parent_handler = phytium_gpio_irq_handler; 116 117 girq->chip = &gpio->irq_chip; 118 119 err = devm_gpiochip_add_data(dev, &gpio->gc, gpio); 120 if (err) 121 return err; 122 123 platform_set_drvdata(pdev, gpio); 124 dev_info(dev, "Phytium GPIO controller @%pa registered\n", 125 &res->start); 126 127 return 0; 128 } 129 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-5.10] [Huawei] ima: Fix suspicious RCU usage
by GUO Zihua 30 Apr '24

30 Apr '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9KUX7 -------------------------------- Fixed "WARNING: suspicious RCU usage" warning on ima_update_policy_flag. Fixes: bccda6c35b52 ("ima: fix deadlock when traversing \"ima_default_rules\".") Signed-off-by: GUO Zihua <guozihua(a)huawei.com> --- security/integrity/ima/ima_policy.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c index a9dbfc7143b3..43a5c4754a66 100644 --- a/security/integrity/ima/ima_policy.c +++ b/security/integrity/ima/ima_policy.c @@ -759,11 +759,13 @@ void ima_update_policy_flag(void) struct ima_rule_entry *entry; struct list_head *ima_rules_tmp; + rcu_read_lock(); ima_rules_tmp = rcu_dereference(ima_rules); list_for_each_entry_rcu(entry, ima_rules_tmp, list) { if (entry->action & IMA_DO_MASK) ima_policy_flag |= entry->action; } + rcu_read_unlock(); ima_appraise |= (build_ima_appraise | temp_ima_appraise); if (!ima_appraise) -- 2.34.1

2 1

[PATCH OLK-5.10] [Huawei] ima: Fix suspicious RCU usage
by GUO Zihua 30 Apr '24

30 Apr '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9KUX7 -------------------------------- Fixed "WARNING: suspicious RCU usage" warning on ima_update_policy_flag. Fixes: bccda6c35b52 ("ima: fix deadlock when traversing \"ima_default_rules\".") Signed-off-by: GUO Zihua <guozihua(a)huawei.com> --- security/integrity/ima/ima_policy.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c index a9dbfc7143b3..43a5c4754a66 100644 --- a/security/integrity/ima/ima_policy.c +++ b/security/integrity/ima/ima_policy.c @@ -759,11 +759,13 @@ void ima_update_policy_flag(void) struct ima_rule_entry *entry; struct list_head *ima_rules_tmp; + rcu_read_lock(); ima_rules_tmp = rcu_dereference(ima_rules); list_for_each_entry_rcu(entry, ima_rules_tmp, list) { if (entry->action & IMA_DO_MASK) ima_policy_flag |= entry->action; } + rcu_read_unlock(); ima_appraise |= (build_ima_appraise | temp_ima_appraise); if (!ima_appraise) -- 2.34.1

2 1

[PATCH OLK-6.6] media: dvb-usb: Fix unexpected infinite loop in dvb_usb_read_remote_control()
by Zheng Yejian 30 Apr '24

30 Apr '24

maillist inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9KUFO Reference: https://lore.kernel.org/all/20240412135256.1546051-1-zhengyejian1@huawei.co… -------------------------------- Infinite log printing occurs during fuzz test: rc rc1: DViCO FusionHDTV DVB-T USB (LGZ201) as ... ... dvb-usb: schedule remote query interval to 100 msecs. dvb-usb: DViCO FusionHDTV DVB-T USB (LGZ201) successfully initialized ... dvb-usb: bulk message failed: -22 (1/0) dvb-usb: bulk message failed: -22 (1/0) dvb-usb: bulk message failed: -22 (1/0) ... dvb-usb: bulk message failed: -22 (1/0) Looking into the codes, there is a loop in dvb_usb_read_remote_control(), that is in rc_core_dvb_usb_remote_init() create a work that will call dvb_usb_read_remote_control(), and this work will reschedule itself at 'rc_interval' intervals to recursively call dvb_usb_read_remote_control(), see following code snippet: rc_core_dvb_usb_remote_init() { ... INIT_DELAYED_WORK(&d->rc_query_work, dvb_usb_read_remote_control); schedule_delayed_work(&d->rc_query_work, msecs_to_jiffies(rc_interval)); ... } dvb_usb_read_remote_control() { ... err = d->props.rc.core.rc_query(d); if (err) err(...) // Did not return even if query failed schedule_delayed_work(&d->rc_query_work, msecs_to_jiffies(rc_interval)); } When the infinite log printing occurs, the query callback 'd->props.rc.core.rc_query' is cxusb_rc_query(). And the log is due to the failure of finding a valid 'generic_bulk_ctrl_endpoint' in usb_bulk_msg(), see following code snippet: cxusb_rc_query() { cxusb_ctrl_msg() { dvb_usb_generic_rw() { ret = usb_bulk_msg(d->udev, usb_sndbulkpipe(d->udev, d->props.generic_bulk_ctrl_endpoint),...); if (ret) err("bulk message failed: %d (%d/%d)",ret,wlen,actlen); ... } ... } By analyzing the corresponding USB descriptor, it shows that the bNumEndpoints is 0 in its interface descriptor, but the 'generic_bulk_ctrl_endpoint' is 1, that means user don't configure a valid endpoint for 'generic_bulk_ctrl_endpoint', therefore this 'invalid' USB device should be rejected before it calls into dvb_usb_read_remote_control(). To fix it, iiuc, we can add endpoint check in dvb_usb_adapter_init(). Fixes: 786baecfe78f ("[media] dvb-usb: move it to drivers/media/usb/dvb-usb") Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> --- drivers/media/usb/dvb-usb/dvb-usb-init.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/media/usb/dvb-usb/dvb-usb-init.c b/drivers/media/usb/dvb-usb/dvb-usb-init.c index fbf58012becd..48e7b9fb93dd 100644 --- a/drivers/media/usb/dvb-usb/dvb-usb-init.c +++ b/drivers/media/usb/dvb-usb/dvb-usb-init.c @@ -104,6 +104,14 @@ static int dvb_usb_adapter_init(struct dvb_usb_device *d, short *adapter_nrs) * sometimes a timeout occurs, this helps */ if (d->props.generic_bulk_ctrl_endpoint != 0) { + ret = usb_pipe_type_check(d->udev, usb_sndbulkpipe(d->udev, + d->props.generic_bulk_ctrl_endpoint)); + if (ret) + goto frontend_init_err; + ret = usb_pipe_type_check(d->udev, usb_rcvbulkpipe(d->udev, + d->props.generic_bulk_ctrl_endpoint)); + if (ret) + goto frontend_init_err; usb_clear_halt(d->udev, usb_sndbulkpipe(d->udev, d->props.generic_bulk_ctrl_endpoint)); usb_clear_halt(d->udev, usb_rcvbulkpipe(d->udev, d->props.generic_bulk_ctrl_endpoint)); } -- 2.25.1

2 1

[PATCH OLK-5.10] media: dvb-usb: Fix unexpected infinite loop in dvb_usb_read_remote_control()
by Zheng Yejian 30 Apr '24

30 Apr '24

maillist inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9KUFO Reference: https://lore.kernel.org/all/20240412135256.1546051-1-zhengyejian1@huawei.co… -------------------------------- Infinite log printing occurs during fuzz test: rc rc1: DViCO FusionHDTV DVB-T USB (LGZ201) as ... ... dvb-usb: schedule remote query interval to 100 msecs. dvb-usb: DViCO FusionHDTV DVB-T USB (LGZ201) successfully initialized ... dvb-usb: bulk message failed: -22 (1/0) dvb-usb: bulk message failed: -22 (1/0) dvb-usb: bulk message failed: -22 (1/0) ... dvb-usb: bulk message failed: -22 (1/0) Looking into the codes, there is a loop in dvb_usb_read_remote_control(), that is in rc_core_dvb_usb_remote_init() create a work that will call dvb_usb_read_remote_control(), and this work will reschedule itself at 'rc_interval' intervals to recursively call dvb_usb_read_remote_control(), see following code snippet: rc_core_dvb_usb_remote_init() { ... INIT_DELAYED_WORK(&d->rc_query_work, dvb_usb_read_remote_control); schedule_delayed_work(&d->rc_query_work, msecs_to_jiffies(rc_interval)); ... } dvb_usb_read_remote_control() { ... err = d->props.rc.core.rc_query(d); if (err) err(...) // Did not return even if query failed schedule_delayed_work(&d->rc_query_work, msecs_to_jiffies(rc_interval)); } When the infinite log printing occurs, the query callback 'd->props.rc.core.rc_query' is cxusb_rc_query(). And the log is due to the failure of finding a valid 'generic_bulk_ctrl_endpoint' in usb_bulk_msg(), see following code snippet: cxusb_rc_query() { cxusb_ctrl_msg() { dvb_usb_generic_rw() { ret = usb_bulk_msg(d->udev, usb_sndbulkpipe(d->udev, d->props.generic_bulk_ctrl_endpoint),...); if (ret) err("bulk message failed: %d (%d/%d)",ret,wlen,actlen); ... } ... } By analyzing the corresponding USB descriptor, it shows that the bNumEndpoints is 0 in its interface descriptor, but the 'generic_bulk_ctrl_endpoint' is 1, that means user don't configure a valid endpoint for 'generic_bulk_ctrl_endpoint', therefore this 'invalid' USB device should be rejected before it calls into dvb_usb_read_remote_control(). To fix it, iiuc, we can add endpoint check in dvb_usb_adapter_init(). Fixes: 786baecfe78f ("[media] dvb-usb: move it to drivers/media/usb/dvb-usb") Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> --- drivers/media/usb/dvb-usb/dvb-usb-init.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/media/usb/dvb-usb/dvb-usb-init.c b/drivers/media/usb/dvb-usb/dvb-usb-init.c index 58eea8ab5477..d8098c110450 100644 --- a/drivers/media/usb/dvb-usb/dvb-usb-init.c +++ b/drivers/media/usb/dvb-usb/dvb-usb-init.c @@ -104,6 +104,14 @@ static int dvb_usb_adapter_init(struct dvb_usb_device *d, short *adapter_nrs) * sometimes a timeout occurs, this helps */ if (d->props.generic_bulk_ctrl_endpoint != 0) { + ret = usb_pipe_type_check(d->udev, usb_sndbulkpipe(d->udev, + d->props.generic_bulk_ctrl_endpoint)); + if (ret) + goto frontend_init_err; + ret = usb_pipe_type_check(d->udev, usb_rcvbulkpipe(d->udev, + d->props.generic_bulk_ctrl_endpoint)); + if (ret) + goto frontend_init_err; usb_clear_halt(d->udev, usb_sndbulkpipe(d->udev, d->props.generic_bulk_ctrl_endpoint)); usb_clear_halt(d->udev, usb_rcvbulkpipe(d->udev, d->props.generic_bulk_ctrl_endpoint)); } -- 2.25.1

2 1

[PATCH OLK-6.6] media: dvb-usb: Fix unexpected infinite loop in dvb_usb_read_remote_control()
by Zheng Yejian 30 Apr '24

30 Apr '24

maillist inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9KUFO Reference: https://lore.kernel.org/all/20240412135256.1546051-1-zhengyejian1@huawei.co… -------------------------------- Infinite log printing occurs during fuzz test: rc rc1: DViCO FusionHDTV DVB-T USB (LGZ201) as ... ... dvb-usb: schedule remote query interval to 100 msecs. dvb-usb: DViCO FusionHDTV DVB-T USB (LGZ201) successfully initialized ... dvb-usb: bulk message failed: -22 (1/0) dvb-usb: bulk message failed: -22 (1/0) dvb-usb: bulk message failed: -22 (1/0) ... dvb-usb: bulk message failed: -22 (1/0) Looking into the codes, there is a loop in dvb_usb_read_remote_control(), that is in rc_core_dvb_usb_remote_init() create a work that will call dvb_usb_read_remote_control(), and this work will reschedule itself at 'rc_interval' intervals to recursively call dvb_usb_read_remote_control(), see following code snippet: rc_core_dvb_usb_remote_init() { ... INIT_DELAYED_WORK(&d->rc_query_work, dvb_usb_read_remote_control); schedule_delayed_work(&d->rc_query_work, msecs_to_jiffies(rc_interval)); ... } dvb_usb_read_remote_control() { ... err = d->props.rc.core.rc_query(d); if (err) err(...) // Did not return even if query failed schedule_delayed_work(&d->rc_query_work, msecs_to_jiffies(rc_interval)); } When the infinite log printing occurs, the query callback 'd->props.rc.core.rc_query' is cxusb_rc_query(). And the log is due to the failure of finding a valid 'generic_bulk_ctrl_endpoint' in usb_bulk_msg(), see following code snippet: cxusb_rc_query() { cxusb_ctrl_msg() { dvb_usb_generic_rw() { ret = usb_bulk_msg(d->udev, usb_sndbulkpipe(d->udev, d->props.generic_bulk_ctrl_endpoint),...); if (ret) err("bulk message failed: %d (%d/%d)",ret,wlen,actlen); ... } ... } By analyzing the corresponding USB descriptor, it shows that the bNumEndpoints is 0 in its interface descriptor, but the 'generic_bulk_ctrl_endpoint' is 1, that means user don't configure a valid endpoint for 'generic_bulk_ctrl_endpoint', therefore this 'invalid' USB device should be rejected before it calls into dvb_usb_read_remote_control(). To fix it, iiuc, we can add endpoint check in dvb_usb_adapter_init(). Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> --- drivers/media/usb/dvb-usb/dvb-usb-init.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/media/usb/dvb-usb/dvb-usb-init.c b/drivers/media/usb/dvb-usb/dvb-usb-init.c index fbf58012becd..48e7b9fb93dd 100644 --- a/drivers/media/usb/dvb-usb/dvb-usb-init.c +++ b/drivers/media/usb/dvb-usb/dvb-usb-init.c @@ -104,6 +104,14 @@ static int dvb_usb_adapter_init(struct dvb_usb_device *d, short *adapter_nrs) * sometimes a timeout occurs, this helps */ if (d->props.generic_bulk_ctrl_endpoint != 0) { + ret = usb_pipe_type_check(d->udev, usb_sndbulkpipe(d->udev, + d->props.generic_bulk_ctrl_endpoint)); + if (ret) + goto frontend_init_err; + ret = usb_pipe_type_check(d->udev, usb_rcvbulkpipe(d->udev, + d->props.generic_bulk_ctrl_endpoint)); + if (ret) + goto frontend_init_err; usb_clear_halt(d->udev, usb_sndbulkpipe(d->udev, d->props.generic_bulk_ctrl_endpoint)); usb_clear_halt(d->udev, usb_rcvbulkpipe(d->udev, d->props.generic_bulk_ctrl_endpoint)); } -- 2.25.1

2 1

[PATCH OLK-5.10] media: dvb-usb: Fix unexpected infinite loop in dvb_usb_read_remote_control()
by Zheng Yejian 30 Apr '24

30 Apr '24

maillist inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9KUFO Reference: https://lore.kernel.org/all/20240412135256.1546051-1-zhengyejian1@huawei.co… -------------------------------- Infinite log printing occurs during fuzz test: rc rc1: DViCO FusionHDTV DVB-T USB (LGZ201) as ... ... dvb-usb: schedule remote query interval to 100 msecs. dvb-usb: DViCO FusionHDTV DVB-T USB (LGZ201) successfully initialized ... dvb-usb: bulk message failed: -22 (1/0) dvb-usb: bulk message failed: -22 (1/0) dvb-usb: bulk message failed: -22 (1/0) ... dvb-usb: bulk message failed: -22 (1/0) Looking into the codes, there is a loop in dvb_usb_read_remote_control(), that is in rc_core_dvb_usb_remote_init() create a work that will call dvb_usb_read_remote_control(), and this work will reschedule itself at 'rc_interval' intervals to recursively call dvb_usb_read_remote_control(), see following code snippet: rc_core_dvb_usb_remote_init() { ... INIT_DELAYED_WORK(&d->rc_query_work, dvb_usb_read_remote_control); schedule_delayed_work(&d->rc_query_work, msecs_to_jiffies(rc_interval)); ... } dvb_usb_read_remote_control() { ... err = d->props.rc.core.rc_query(d); if (err) err(...) // Did not return even if query failed schedule_delayed_work(&d->rc_query_work, msecs_to_jiffies(rc_interval)); } When the infinite log printing occurs, the query callback 'd->props.rc.core.rc_query' is cxusb_rc_query(). And the log is due to the failure of finding a valid 'generic_bulk_ctrl_endpoint' in usb_bulk_msg(), see following code snippet: cxusb_rc_query() { cxusb_ctrl_msg() { dvb_usb_generic_rw() { ret = usb_bulk_msg(d->udev, usb_sndbulkpipe(d->udev, d->props.generic_bulk_ctrl_endpoint),...); if (ret) err("bulk message failed: %d (%d/%d)",ret,wlen,actlen); ... } ... } By analyzing the corresponding USB descriptor, it shows that the bNumEndpoints is 0 in its interface descriptor, but the 'generic_bulk_ctrl_endpoint' is 1, that means user don't configure a valid endpoint for 'generic_bulk_ctrl_endpoint', therefore this 'invalid' USB device should be rejected before it calls into dvb_usb_read_remote_control(). To fix it, iiuc, we can add endpoint check in dvb_usb_adapter_init(). Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> --- drivers/media/usb/dvb-usb/dvb-usb-init.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/media/usb/dvb-usb/dvb-usb-init.c b/drivers/media/usb/dvb-usb/dvb-usb-init.c index 58eea8ab5477..d8098c110450 100644 --- a/drivers/media/usb/dvb-usb/dvb-usb-init.c +++ b/drivers/media/usb/dvb-usb/dvb-usb-init.c @@ -104,6 +104,14 @@ static int dvb_usb_adapter_init(struct dvb_usb_device *d, short *adapter_nrs) * sometimes a timeout occurs, this helps */ if (d->props.generic_bulk_ctrl_endpoint != 0) { + ret = usb_pipe_type_check(d->udev, usb_sndbulkpipe(d->udev, + d->props.generic_bulk_ctrl_endpoint)); + if (ret) + goto frontend_init_err; + ret = usb_pipe_type_check(d->udev, usb_rcvbulkpipe(d->udev, + d->props.generic_bulk_ctrl_endpoint)); + if (ret) + goto frontend_init_err; usb_clear_halt(d->udev, usb_sndbulkpipe(d->udev, d->props.generic_bulk_ctrl_endpoint)); usb_clear_halt(d->udev, usb_rcvbulkpipe(d->udev, d->props.generic_bulk_ctrl_endpoint)); } -- 2.25.1

2 1

2024

2023

2022

2021

2020

2019

Kernel April 2024