drivers/scsi/lpfc/lpfc_init.c | 25 +++++++++++++------------ drivers/scsi/lpfc/lpfc_nportdisc.c | 4 +++- 2 files changed, 16 insertions(+), 13 deletions(-)
This series fixes three independent memory leaks in the lpfc driver. All of them occur in error handling paths where allocated memory was not properly freed before returning. These issues were identified during static analysis. Signed-off-by: Zilin Guan <zilin@seu.edu.cn> Changes in v3: - Patch 1: Remove unnecessary braces for single-line if statement. - Patch 2: No changes. - Patch 3: No changes. Changes in v2: - Patch 1: Refactor error handling to use a goto label for cleanup. - Patch 2: No changes. - Patch 3: No changes. Zilin Guan (3): scsi: lpfc: Fix memory leak in lpfc_config_port_post() scsi: lpfc: Fix memory leak in lpfc_sli4_driver_resource_setup() scsi: lpfc: Fix memory leak in lpfc_cmpl_plogi_plogi_issue() drivers/scsi/lpfc/lpfc_init.c | 25 +++++++++++++------------ drivers/scsi/lpfc/lpfc_nportdisc.c | 4 +++- 2 files changed, 16 insertions(+), 13 deletions(-) -- 2.34.1
… > These issues were identified during static analysis. How do you think about to share further information according to your source code analysis approach? Regards, Markus
On Wed, Dec 31, 2025 at 05:33:32PM +0100, Markus Elfring wrote: > … > > These issues were identified during static analysis. > > How do you think about to share further information according to > your source code analysis approach? > > Regards, > Markus Hi Markus, Thank you for your inquiry. I believe the commit messages in each individual patch within this series already provide a clear and specific description of the identified issues and the analysis of the failure paths. Best regards, Zilin Guan
>> … >>> These issues were identified during static analysis. >> >> How do you think about to share further information according to >> your source code analysis approach? … > Thank you for your inquiry. > > I believe the commit messages in each individual patch within this series > already provide a clear and specific description of the identified issues > and the analysis of the failure paths. You presented interesting development ideas. Will any related concerns become relevant here? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/researcher-guidelines.rst?h=v6.19-rc3#n5 Did your analysis approach get a corresponding name? Regards, Markus
On Sat, Jan 03, 2026 at 02:30:36PM +0100, Markus Elfring wrote: > You presented interesting development ideas. > Will any related concerns become relevant here? > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/researcher-guidelines.rst?h=v6.19-rc3#n5 > > Did your analysis approach get a corresponding name? > > Regards, > Markus We are aware of these ethics requirements and strictly respect them. For example, we responsibly disclose our findings (i.e., bugs, in the form of patches), and we will make our paper and code public after publication. However, we cannot disclose our tool at this moment because our research is still ongoing. Regards, Zilin Guan
>> You presented interesting development ideas. >> Will any related concerns become relevant here? >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/researcher-guidelines.rst?h=v6.19-rc3#n5 >> >> Did your analysis approach get a corresponding name? … > We are aware of these ethics requirements and strictly respect them. > For example, we responsibly disclose our findings (i.e., bugs, in the > form of patches), Thanks for your contributions. > and we will make our paper and code public after > publication. However, we cannot disclose our tool at this moment because > our research is still ongoing. Do the researcher guidelines indicate a need to point research activities out in more explicit ways? Does your email address indicate a relationship with the Southeast University? Is the School of Information Science and Engineering involved here? Regards, Markus
On Sat, Jan 03, 2026 at 04:54:39PM +0100, Markus Elfring wrote: > Do the researcher guidelines indicate a need to point research activities out > in more explicit ways? No, as our research does not constitute "active research on developer behavior", but rather consists of "good faith contributions". It is governed by and conducted in full compliance with both the Linux Kernel's Researcher Guidelines and the relevant security conference guidelines for vulnerability disclosure (e.g., IEEE S&P: https://sp2026.ieee-security.org/cfpapers.html). I appreciate your engagement, but we must stay on point. Your frequent questions unrelated to the technical content of many my patches are causing distractions and creating noise in the discussion. Therefore, I will no longer respond to off-topic inquiries in this public channel. Regards, Zilin Guan
© 2016 - 2026 Red Hat, Inc.