linux-kernel - Re: [PATCH -next 1/2] irqdomain: fix possible uninitialized variable in irq_find

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 18 Jul 2022 15:12:53 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Xu Qiang <xuqiang36@...wei.com>
Cc:     <tglx@...utronix.de>, <linux-kernel@...r.kernel.org>,
        <rui.xiang@...wei.com>
Subject: Re: [PATCH -next 1/2] irqdomain: fix possible uninitialized variable in irq_find_mapping()

On Mon, 18 Jul 2022 14:07:58 +0100,
Xu Qiang <xuqiang36@...wei.com> wrote:
> 
> In irq_find_mapping,ret value may be uninitialized.However,even if
> the local variable irq is initialized, it only solves the uninitialized
> problem and ret value is still an incorrect virq, so my modification
> method is to set virq in __irq_resolve_mapping function.

I think I understand what you are fixing, but I sadly don't understand
the commit message. Here's what I suggest as a commit message:

<commit>
When using a NOMAP domain, __irq_resolve_mapping() doesn't store the
Linux IRQ number at the address optionally provided by the caller.

While this isn't a huge deal (the returned value is guaranteed to the
hwirq that was passed as a parameter), let's honour the letter of the
API by writing the expected value.
</commit>

Does this match what you expected?

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.