The patch titled
Subject: proc/vmcore: fix signedness bug in read_from_oldmem()
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
proc-vmcore-fix-signedness-bug-in-read_from_oldmem.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche…
This patch will later appear in the mm-hotfixes-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Dan Carpenter <dan.carpenter(a)linaro.org>
Subject: proc/vmcore: fix signedness bug in read_from_oldmem()
Date: Tue, 25 Jul 2023 20:03:16 +0300
The bug is the error handling:
if (tmp < nr_bytes) {
"tmp" can hold negative error codes but because "nr_bytes" is type size_t
the negative error codes are treated as very high positive values
(success). Fix this by changing "nr_bytes" to type ssize_t. The
"nr_bytes" variable is used to store values between 1 and PAGE_SIZE and
they can fit in ssize_t without any issue.
Link: https://lkml.kernel.org/r/b55f7eed-1c65-4adc-95d1-6c7c65a54a6e@moroto.mount…
Fixes: 5d8de293c224 ("vmcore: convert copy_oldmem_page() to take an iov_iter")
Signed-off-by: Dan Carpenter <dan.carpenter(a)linaro.org>
Reviewed-by: Matthew Wilcox (Oracle) <willy(a)infradead.org>
Acked-by: Baoquan He <bhe(a)redhat.com>
Cc: Dave Young <dyoung(a)redhat.com>
Cc: Vivek Goyal <vgoyal(a)redhat.com>
Cc: Alexey Dobriyan <adobriyan(a)gmail.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/proc/vmcore.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/proc/vmcore.c~proc-vmcore-fix-signedness-bug-in-read_from_oldmem
+++ a/fs/proc/vmcore.c
@@ -132,7 +132,7 @@ ssize_t read_from_oldmem(struct iov_iter
u64 *ppos, bool encrypted)
{
unsigned long pfn, offset;
- size_t nr_bytes;
+ ssize_t nr_bytes;
ssize_t read = 0, tmp;
int idx;
_
Patches currently in -mm which might be from dan.carpenter(a)linaro.org are
proc-vmcore-fix-signedness-bug-in-read_from_oldmem.patch
On 7/26/23 06:17, Conor Dooley wrote:
> On Tue, Jul 25, 2023 at 07:57:54PM +0100, Conor Dooley wrote:
>> On Tue, Jul 25, 2023 at 10:23:44AM -0700, Nathan Chancellor wrote:
>>> On Wed, Jul 26, 2023 at 01:04:05AM +0800, Mingzheng Xing wrote:
>>>> When compiling the kernel with the toolchain composed of GCC >= 12.1.0 and
>>>> binutils < 2.38, default ISA spec used when building binutils and GCC, the
>>>> following build failure will appear because the
>>>> CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI is not turned on.
>>>> (i.e, gcc-12.1.0 and binutils-2.36, or gcc-12.3.0 and binutils-2.37, use
>>>> default ISA spec.)
>>>>
>>>> CC arch/riscv/kernel/vdso/vgettimeofday.o
>>>> <<BUILDDIR>>/arch/riscv/include/asm/vdso/gettimeofday.h: Assembler messages:
>>>> <<BUILDDIR>>/arch/riscv/include/asm/vdso/gettimeofday.h:79: Error: unrecognized opcode `csrr a5,0xc01'
>>> The gift that keeps on giving :/
>>>
>>>> Binutils has updated the default ISA spec version, and the community has
>>>> responded well to this[1][2][3], but it appears that this is not over yet.
> Also, I just noticed this comment. I disagree with the wording "well",
> and more like "with weeping and gnashing of teeth" ;) This stuff is a
> huge pain in the ass, and mixing toolchains between LLVM & GNU stuff (or
> using an older binutils with a newer GCC) really makes it a lot worse.
At least in the usual way , except in my unusual case...
> Thanks for submitting a fix for this so that Nathan or I didn't have to!
Hopefully this patch will make things better.
>>>> We also need to consider the situation of binutils < 2.38 but
>>>> GCC >= 12.1.0, since the combination between different versions of GCC and
>>>> binutils is not unique, which is to some extent flexible. GCC release
>>>> 12.1.0 updated the default ISA spec version in GCC commit[4].
>>> I suspect this combination is not too common because binutils 2.38 came
>>> out before GCC 12.1.0 but as you note, it is obviously possible. What
>>> toolchain has this combination in the wild, which would be helpful for
>>> documentation purposes?
>> Yeah, that'd be great to know, at least the other niche stuff that we
>> are working around had a clear use-case (testing LLVM in debian containers)
>> whereas there's no clear user for this.
>> That's doubly interesting, as this patch seems to break things for binutils
>> < 2.35, and if we have to make a trade-off between those too, then it'd
>> be good to be able to weigh up the options.
>> Do we perhaps need the misa-spec workaround instead for this case?
>> Haven't tested that though, trying to dig myself out of email backlog.
> I don't think the misa-spec stuff is what we need actually. Instead, the
> workaround/fix that this patch implements just needs to be constrained to
> versions of GAS greater than 2.35.
I'm sorry, I didn't quite understand this, could you provide some more
information, thank you very much!
I'll change the handling in v2. After testing it myself, it seems to
work fine.
Thanks,
Mingzheng.
> Thanks,
> Conor.
>
>>>> For more information, please refer to:
>>>>
>>>> commit 6df2a016c0c8 ("riscv: fix build with binutils 2.38")
>>>> commit e89c2e815e76 ("riscv: Handle zicsr/zifencei issues between clang and binutils")
>>>>
>>>> [1]:https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/aE1ZeHHCYf4
>>>> [2]:https://lore.kernel.org/all/20230308220842.1231003-1-conor@kernel.org
>>>> [3]:https://lore.kernel.org/all/20230223220546.52879-1-conor@kernel.org
>>>> [4]:https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=98416dbb0a62579d4a7a4a76ba…
>> btw, please make these regular Link: tags (with a [N] at EOL) and drop
>> the space between them and the sign off. Also, this probably needs to be
>> CC:stable@vger.kernel.org too.
>>>> Signed-off-by: Mingzheng Xing<xingmingzheng(a)iscas.ac.cn>
>>>> ---
>>>> arch/riscv/Kconfig | 6 +++++-
>>>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
>>>> index 4c07b9189c86..b49cea30f6cc 100644
>>>> --- a/arch/riscv/Kconfig
>>>> +++ b/arch/riscv/Kconfig
>>>> @@ -570,11 +570,15 @@ config TOOLCHAIN_HAS_ZIHINTPAUSE
>>>> config TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI
>>>> def_bool y
>>>> #https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=aed44286efa8ae8717a77d94b51ac3614e2ca6dc
>>>> - depends on AS_IS_GNU && AS_VERSION >= 23800
>>>> + #https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=98416dbb0a62579d4a7a4a76bab51b5b52fec2cd
>>>> + depends on CC_IS_GCC && GCC_VERSION >= 120100 || \
>>>> + AS_IS_GNU && AS_VERSION >= 23800
>>> GCC_VERSION will be 0 for clang, so you don't need the CC_IS_GCC check.
>>> With that change, this should be able to stay on one line:
>>>
>>> depends on GCC_VERSION >= 120100 || (AS_IS_GNU && AS_VERSION >= 23800)
>>>
>>>> help
>>>> Newer binutils versions default to ISA spec version 20191213 which
>>>> moves some instructions from the I extension to the Zicsr and Zifencei
>>>> extensions.
>>>> + Similarly, GCC release 12.1.0 has changed the default ISA spec version to
>>>> + 20191213, so the above situation requires this option to be enabled.
>>>>
>>>> config TOOLCHAIN_NEEDS_OLD_ISA_SPEC
>>>> def_bool y
>>>> --
>>>> 2.34.1
>>>>
On 7/26/23 02:57, Conor Dooley wrote:
> On Tue, Jul 25, 2023 at 10:23:44AM -0700, Nathan Chancellor wrote:
>> Hi Mingzheng,
>>
>> Thanks for the patch!
>>
>> On Wed, Jul 26, 2023 at 01:04:05AM +0800, Mingzheng Xing wrote:
>>> When compiling the kernel with the toolchain composed of GCC >= 12.1.0 and
>>> binutils < 2.38, default ISA spec used when building binutils and GCC, the
>>> following build failure will appear because the
>>> CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI is not turned on.
>>> (i.e, gcc-12.1.0 and binutils-2.36, or gcc-12.3.0 and binutils-2.37, use
>>> default ISA spec.)
>>>
>>> CC arch/riscv/kernel/vdso/vgettimeofday.o
>>> <<BUILDDIR>>/arch/riscv/include/asm/vdso/gettimeofday.h: Assembler messages:
>>> <<BUILDDIR>>/arch/riscv/include/asm/vdso/gettimeofday.h:79: Error: unrecognized opcode `csrr a5,0xc01'
>> The gift that keeps on giving :/
>>
>>> Binutils has updated the default ISA spec version, and the community has
>>> responded well to this[1][2][3], but it appears that this is not over yet.
>>>
>>> We also need to consider the situation of binutils < 2.38 but
>>> GCC >= 12.1.0, since the combination between different versions of GCC and
>>> binutils is not unique, which is to some extent flexible. GCC release
>>> 12.1.0 updated the default ISA spec version in GCC commit[4].
>> I suspect this combination is not too common because binutils 2.38 came
>> out before GCC 12.1.0 but as you note, it is obviously possible. What
>> toolchain has this combination in the wild, which would be helpful for
>> documentation purposes?
> Yeah, that'd be great to know, at least the other niche stuff that we
> are working around had a clear use-case (testing LLVM in debian containers)
> whereas there's no clear user for this.
> That's doubly interesting, as this patch seems to break things for binutils
> < 2.35, and if we have to make a trade-off between those too, then it'd
> be good to be able to weigh up the options.
> Do we perhaps need the misa-spec workaround instead for this case?
> Haven't tested that though, trying to dig myself out of email backlog.
Well, what I encountered use-case was a temporary thing caused by the
inconsistent pace of distro package upgrades, but it really happened and
took quite a bit of time to explore why. There are sites like [1] that count
the "Successful Builds" between different GCC and binutils releases,
(Though they don't seem to be updated much...), but it seems to indicate
that all kinds of available pairings are possible.
Before replying to the e-mail, I tested some "extreme" cases and things
seemed to be a little clearer.
1. binutils-2.38 and GCC-12.1.0 each changed default ISA spec version,
updating from 2.2 to 20191213.
2. binutils>=2.38 or GCC>=12.1.0
when meet any of these it is recommended to turn on
TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI, the good outweighs
the bad. (My personal understanding.)
3. (Extreme case) binutils>=2.38 AND GCC<11.1.0
GCC-11.1.0 starts to support zicsr and zifencei extension for
-march[2].
In this case just turn on TOOLCHAIN_NEEDS_OLD_ISA_SPEC.
(Otherwise compiling the kernel will report an error whether
TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI is turned on or not.)
4. (Extreme case) GCC>=12.1.0, binutils<2.36
I tested GCC-12.1.0 + binutils-2.36 and it compiles the kernel
fine(after
hitting this patch). Also tested GCC-12.1.0 + binutils2.35 and
GCC-12.1.0 + binutils-2.34.0, but both pairings gave errors and failed
to produce a usable toolchain (Default ISA versions used). It seems
safe
to assume that GCC-12.1.0 + binutils<2.35 is almost non-existent.
I'm no expert on toolchains, so thanks for correcting me if I'm wrong
somewhere...
[1] https://wiki.osdev.org/Cross-Compiler_Successful_Builds
[2]
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b03be74bad08c382da47e048007a7…
>>> For more information, please refer to:
>>>
>>> commit 6df2a016c0c8 ("riscv: fix build with binutils 2.38")
>>> commit e89c2e815e76 ("riscv: Handle zicsr/zifencei issues between clang and binutils")
>>>
>>> [1]:https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/aE1ZeHHCYf4
>>> [2]:https://lore.kernel.org/all/20230308220842.1231003-1-conor@kernel.org
>>> [3]:https://lore.kernel.org/all/20230223220546.52879-1-conor@kernel.org
>>> [4]:https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=98416dbb0a62579d4a7a4a76ba…
> btw, please make these regular Link: tags (with a [N] at EOL) and drop
> the space between them and the sign off. Also, this probably needs to be
> CC:stable@vger.kernel.org too.
OK, I'll fix it.
Thanks,
Mingzheng.
> Cheers,
> Conor.
>
>>> Signed-off-by: Mingzheng Xing<xingmingzheng(a)iscas.ac.cn>
>>> ---
>>> arch/riscv/Kconfig | 6 +++++-
>>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
>>> index 4c07b9189c86..b49cea30f6cc 100644
>>> --- a/arch/riscv/Kconfig
>>> +++ b/arch/riscv/Kconfig
>>> @@ -570,11 +570,15 @@ config TOOLCHAIN_HAS_ZIHINTPAUSE
>>> config TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI
>>> def_bool y
>>> #https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=aed44286efa8ae8717a77d94b51ac3614e2ca6dc
>>> - depends on AS_IS_GNU && AS_VERSION >= 23800
>>> + #https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=98416dbb0a62579d4a7a4a76bab51b5b52fec2cd
>>> + depends on CC_IS_GCC && GCC_VERSION >= 120100 || \
>>> + AS_IS_GNU && AS_VERSION >= 23800
>> GCC_VERSION will be 0 for clang, so you don't need the CC_IS_GCC check.
>> With that change, this should be able to stay on one line:
>>
>> depends on GCC_VERSION >= 120100 || (AS_IS_GNU && AS_VERSION >= 23800)
>>
>>> help
>>> Newer binutils versions default to ISA spec version 20191213 which
>>> moves some instructions from the I extension to the Zicsr and Zifencei
>>> extensions.
>>> + Similarly, GCC release 12.1.0 has changed the default ISA spec version to
>>> + 20191213, so the above situation requires this option to be enabled.
>>>
>>> config TOOLCHAIN_NEEDS_OLD_ISA_SPEC
>>> def_bool y
>>> --
>>> 2.34.1
>>>
On 7/26/23 01:23, Nathan Chancellor wrote:
> Hi Mingzheng,
>
> Thanks for the patch!
>
> On Wed, Jul 26, 2023 at 01:04:05AM +0800, Mingzheng Xing wrote:
>> When compiling the kernel with the toolchain composed of GCC >= 12.1.0 and
>> binutils < 2.38, default ISA spec used when building binutils and GCC, the
>> following build failure will appear because the
>> CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI is not turned on.
>> (i.e, gcc-12.1.0 and binutils-2.36, or gcc-12.3.0 and binutils-2.37, use
>> default ISA spec.)
>>
>> CC arch/riscv/kernel/vdso/vgettimeofday.o
>> <<BUILDDIR>>/arch/riscv/include/asm/vdso/gettimeofday.h: Assembler messages:
>> <<BUILDDIR>>/arch/riscv/include/asm/vdso/gettimeofday.h:79: Error: unrecognized opcode `csrr a5,0xc01'
> The gift that keeps on giving :/
Yeah, but things will get better :)
>> Binutils has updated the default ISA spec version, and the community has
>> responded well to this[1][2][3], but it appears that this is not over yet.
>>
>> We also need to consider the situation of binutils < 2.38 but
>> GCC >= 12.1.0, since the combination between different versions of GCC and
>> binutils is not unique, which is to some extent flexible. GCC release
>> 12.1.0 updated the default ISA spec version in GCC commit[4].
> I suspect this combination is not too common because binutils 2.38 came
> out before GCC 12.1.0 but as you note, it is obviously possible. What
> toolchain has this combination in the wild, which would be helpful for
> documentation purposes?
Actually, this issue was discovered during the upgrade of the distribution
openEuler for RISC-V. It is a temporary phenomenon caused by
inconsistent upgrade speeds of packages such as GCC and binutils.
From my limited understanding, GCC and binutils are not strictly
version-bound in some other distributions, so I can't rule out this issue
happening in other scenarios. But once it happens it can cause problems
with compiling the kernel.
>> For more information, please refer to:
>>
>> commit 6df2a016c0c8 ("riscv: fix build with binutils 2.38")
>> commit e89c2e815e76 ("riscv: Handle zicsr/zifencei issues between clang and binutils")
>>
>> [1]:https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/aE1ZeHHCYf4
>> [2]:https://lore.kernel.org/all/20230308220842.1231003-1-conor@kernel.org
>> [3]:https://lore.kernel.org/all/20230223220546.52879-1-conor@kernel.org
>> [4]:https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=98416dbb0a62579d4a7a4a76ba…
>>
>> Signed-off-by: Mingzheng Xing<xingmingzheng(a)iscas.ac.cn>
>> ---
>> arch/riscv/Kconfig | 6 +++++-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
>> index 4c07b9189c86..b49cea30f6cc 100644
>> --- a/arch/riscv/Kconfig
>> +++ b/arch/riscv/Kconfig
>> @@ -570,11 +570,15 @@ config TOOLCHAIN_HAS_ZIHINTPAUSE
>> config TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI
>> def_bool y
>> #https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=aed44286efa8ae8717a77d94b51ac3614e2ca6dc
>> - depends on AS_IS_GNU && AS_VERSION >= 23800
>> + #https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=98416dbb0a62579d4a7a4a76bab51b5b52fec2cd
>> + depends on CC_IS_GCC && GCC_VERSION >= 120100 || \
>> + AS_IS_GNU && AS_VERSION >= 23800
> GCC_VERSION will be 0 for clang, so you don't need the CC_IS_GCC check.
> With that change, this should be able to stay on one line:
>
> depends on GCC_VERSION >= 120100 || (AS_IS_GNU && AS_VERSION >= 23800)
OK, I'll change it in v2.
Thanks,
Mingzheng.
>> help
>> Newer binutils versions default to ISA spec version 20191213 which
>> moves some instructions from the I extension to the Zicsr and Zifencei
>> extensions.
>> + Similarly, GCC release 12.1.0 has changed the default ISA spec version to
>> + 20191213, so the above situation requires this option to be enabled.
>>
>> config TOOLCHAIN_NEEDS_OLD_ISA_SPEC
>> def_bool y
>> --
>> 2.34.1
>>
> Cheers,
> Nathan
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv(a)lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
Adding a reserved memory region for the framebuffer memory
(the splash memory region set up by the bootloader).
It fixes a kernel panic (arm-smmu: Unhandled context fault
at this particular memory region) reported on DB845c running
v5.10.y.
Cc: stable(a)vger.kernel.org # v5.10+
Reviewed-by: Caleb Connolly <caleb.connolly(a)linaro.org>
Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org>
---
v6: Collected review tag, updated commit message for the
context and marked for stable kernel versions.
v5: Re-sending with updated dt-bindings patch in mdss-common
schema.
v4: Re-sending this along with a new dt-bindings patch to
document memory-region property in qcom,sdm845-mdss
schema and keep dtbs_check happy.
v3: Point this reserved region to MDSS.
v2: Updated commit message.
There was some dicussion on v1 but it didn't go anywhere,
https://lore.kernel.org/linux-kernel/20230124182857.1524912-1-amit.pundir@l….
The general consensus is that this memory should be freed and be
made resuable but that (releasing this piece of memory) has been
tried before and it is not trivial to return the reserved memory
node to the system RAM pool in this case.
arch/arm64/boot/dts/qcom/sdm845-db845c.dts | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-db845c.dts b/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
index d6b464cb61d6..f546f6f57c1e 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
@@ -101,6 +101,14 @@ hdmi_con: endpoint {
};
};
+ reserved-memory {
+ /* Cont splash region set up by the bootloader */
+ cont_splash_mem: framebuffer@9d400000 {
+ reg = <0x0 0x9d400000 0x0 0x2400000>;
+ no-map;
+ };
+ };
+
lt9611_1v8: lt9611-vdd18-regulator {
compatible = "regulator-fixed";
regulator-name = "LT9611_1V8";
@@ -506,6 +514,7 @@ &i2c14 {
};
&mdss {
+ memory-region = <&cont_splash_mem>;
status = "okay";
};
--
2.25.1
Supported codec bitmask is populated from the payload from venus firmware.
There is a possible case when all the bits in the codec bitmask is set. In
such case, core cap for decoder is filled and MAX_CODEC_NUM is utilized.
Now while filling the caps for encoder, it can lead to access the caps
array beyong 32 index. Hence leading to OOB write.
The fix counts the supported encoder and decoder. If the count is more than
max, then it skips accessing the caps.
Cc: stable(a)vger.kernel.org
Fixes: 1a73374a04e5 ("media: venus: hfi_parser: add common capability parser")
Signed-off-by: Vikash Garodia <quic_vgarodia(a)quicinc.com>
---
drivers/media/platform/qcom/venus/hfi_parser.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/media/platform/qcom/venus/hfi_parser.c b/drivers/media/platform/qcom/venus/hfi_parser.c
index ec73cac..651e215 100644
--- a/drivers/media/platform/qcom/venus/hfi_parser.c
+++ b/drivers/media/platform/qcom/venus/hfi_parser.c
@@ -14,11 +14,26 @@
typedef void (*func)(struct hfi_plat_caps *cap, const void *data,
unsigned int size);
+static int count_setbits(u32 input)
+{
+ u32 count = 0;
+
+ while (input > 0) {
+ if ((input & 1) == 1)
+ count++;
+ input >>= 1;
+ }
+ return count;
+}
+
static void init_codecs(struct venus_core *core)
{
struct hfi_plat_caps *caps = core->caps, *cap;
unsigned long bit;
+ if ((count_setbits(core->dec_codecs) + count_setbits(core->enc_codecs)) > MAX_CODEC_NUM)
+ return;
+
for_each_set_bit(bit, &core->dec_codecs, MAX_CODEC_NUM) {
cap = &caps[core->codecs_count++];
cap->codec = BIT(bit);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
The hfi parser, parses the capabilities received from venus firmware and
copies them to core capabilities. Consider below api, for example,
fill_caps - In this api, caps in core structure gets updated with the
number of capabilities received in firmware data payload. If the same api
is called multiple times, there is a possibility of copying beyond the max
allocated size in core caps.
Similar possibilities in fill_raw_fmts and fill_profile_level functions.
Cc: stable(a)vger.kernel.org
Fixes: 1a73374a04e5 ("media: venus: hfi_parser: add common capability parser")
Signed-off-by: Vikash Garodia <quic_vgarodia(a)quicinc.com>
---
drivers/media/platform/qcom/venus/hfi_parser.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/media/platform/qcom/venus/hfi_parser.c b/drivers/media/platform/qcom/venus/hfi_parser.c
index 6cf74b2..ec73cac 100644
--- a/drivers/media/platform/qcom/venus/hfi_parser.c
+++ b/drivers/media/platform/qcom/venus/hfi_parser.c
@@ -86,6 +86,9 @@ static void fill_profile_level(struct hfi_plat_caps *cap, const void *data,
{
const struct hfi_profile_level *pl = data;
+ if (cap->num_pl > HFI_MAX_PROFILE_COUNT)
+ return;
+
memcpy(&cap->pl[cap->num_pl], pl, num * sizeof(*pl));
cap->num_pl += num;
}
@@ -111,6 +114,9 @@ fill_caps(struct hfi_plat_caps *cap, const void *data, unsigned int num)
{
const struct hfi_capability *caps = data;
+ if (cap->num_caps > MAX_CAP_ENTRIES)
+ return;
+
memcpy(&cap->caps[cap->num_caps], caps, num * sizeof(*caps));
cap->num_caps += num;
}
@@ -137,6 +143,9 @@ static void fill_raw_fmts(struct hfi_plat_caps *cap, const void *fmts,
{
const struct raw_formats *formats = fmts;
+ if (cap->num_fmts > MAX_FMT_ENTRIES)
+ return;
+
memcpy(&cap->fmts[cap->num_fmts], formats, num_fmts * sizeof(*formats));
cap->num_fmts += num_fmts;
}
@@ -159,6 +168,9 @@ parse_raw_formats(struct venus_core *core, u32 codecs, u32 domain, void *data)
rawfmts[i].buftype = fmt->buffer_type;
i++;
+ if (i >= MAX_FMT_ENTRIES)
+ return;
+
if (pinfo->num_planes > MAX_PLANES)
break;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Buffer requirement, for different buffer type, comes from video firmware.
While copying these requirements, there is an OOB possibility when the
payload from firmware is more than expected size. Fix the check to avoid
the OOB possibility.
Cc: stable(a)vger.kernel.org
Fixes: 09c2845e8fe4 ("[media] media: venus: hfi: add Host Firmware Interface (HFI)")
Signed-off-by: Vikash Garodia <quic_vgarodia(a)quicinc.com>
---
drivers/media/platform/qcom/venus/hfi_msgs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/qcom/venus/hfi_msgs.c b/drivers/media/platform/qcom/venus/hfi_msgs.c
index 3d5dadf..3e85bd8 100644
--- a/drivers/media/platform/qcom/venus/hfi_msgs.c
+++ b/drivers/media/platform/qcom/venus/hfi_msgs.c
@@ -398,7 +398,7 @@ session_get_prop_buf_req(struct hfi_msg_session_property_info_pkt *pkt,
memcpy(&bufreq[idx], buf_req, sizeof(*bufreq));
idx++;
- if (idx > HFI_BUFFER_TYPE_MAX)
+ if (idx >= HFI_BUFFER_TYPE_MAX)
return HFI_ERR_SESSION_INVALID_PARAMETER;
req_bytes -= sizeof(struct hfi_buffer_requirements);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Read and write pointers are used to track the packet index in the memory
shared between video driver and firmware. There is a possibility of OOB
access if the read or write pointer goes beyond the queue memory size.
Add checks for the read and write pointer to avoid OOB access.
Cc: stable(a)vger.kernel.org
Fixes: d96d3f30c0f2 ("[media] media: venus: hfi: add Venus HFI files")
Signed-off-by: Vikash Garodia <quic_vgarodia(a)quicinc.com>
---
drivers/media/platform/qcom/venus/hfi_venus.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c b/drivers/media/platform/qcom/venus/hfi_venus.c
index f0b4638..dc228c4 100644
--- a/drivers/media/platform/qcom/venus/hfi_venus.c
+++ b/drivers/media/platform/qcom/venus/hfi_venus.c
@@ -206,6 +206,10 @@ static int venus_write_queue(struct venus_hfi_device *hdev,
new_wr_idx = wr_idx + dwords;
wr_ptr = (u32 *)(queue->qmem.kva + (wr_idx << 2));
+
+ if (wr_ptr < (u32 *)queue->qmem.kva || wr_ptr > (u32 *)(queue->qmem.kva + queue->qmem.size))
+ return -EINVAL;
+
if (new_wr_idx < qsize) {
memcpy(wr_ptr, packet, dwords << 2);
} else {
@@ -273,6 +277,10 @@ static int venus_read_queue(struct venus_hfi_device *hdev,
}
rd_ptr = (u32 *)(queue->qmem.kva + (rd_idx << 2));
+
+ if (rd_ptr < (u32 *)queue->qmem.kva || rd_ptr > (u32 *)(queue->qmem.kva + queue->qmem.size))
+ return -EINVAL;
+
dwords = *rd_ptr >> 2;
if (!dwords)
return -EINVAL;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project