Fwd: New Defects reported by Coverity Scan for RTEMS
Hi
Sebastian I know this is third party code that you just imported but this
looks like a potentially serious issue.
Does anyone see how this could occur? Have a suggestion?
Minimum is to report it upstream. I did that years ago with another issue
in zlib.
--joel
-- Forwarded message -
From:
Date: Wed, May 10, 2023 at 12:22 AM
Subject: New Defects reported by Coverity Scan for RTEMS
To:
Hi,
Please find the latest report on new defect(s) introduced to RTEMS found
with Coverity Scan.
7 new defect(s) introduced to RTEMS found with Coverity Scan.
2 defect(s), reported by Coverity Scan earlier, were marked fixed in the
recent build analyzed by Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 7 of 7 defect(s)
** CID 1529957: Memory - corruptions (OVERRUN)
/cpukit/zlib/gzread.c: 323 in gz_read()
*** CID 1529957: Memory - corruptions (OVERRUN)
/cpukit/zlib/gzread.c: 323 in gz_read()
317 n = (unsigned)len;
318
319 /* first just try copying data from the output buffer */
320 if (state->x.have) {
321 if (state->x.have < n)
322 n = state->x.have;
>>> CID 1529957: Memory - corruptions (OVERRUN)
>>> Calling "memcpy" with "state->x.next" and "n" is suspicious because
of the very large index, 4294967295. The index may be due to a negative
parameter being interpreted as unsigned.
323 memcpy(buf, state->x.next, n);
324 state->x.next += n;
325 state->x.have -= n;
326 }
327
328 /* output buffer empty -- return if we're at the end of the
input */
** CID 1529956: Integer handling issues (CONSTANT_EXPRESSION_RESULT)
/cpukit/zlib/compress.c: 51 in z_compress2()
*** CID 1529956: Integer handling issues (CONSTANT_EXPRESSION_RESULT)
/cpukit/zlib/compress.c: 51 in z_compress2()
45 stream.avail_out = 0;
46 stream.next_in = (z_const Bytef *)source;
47 stream.avail_in = 0;
48
49 do {
50 if (stream.avail_out == 0) {
>>> CID 1529956: Integer handling issues (CONSTANT_EXPRESSION_RESULT)
>>> "left > 4294967295UL /* (z_uLong)max */" is always false regardless
of the values of its operands. This occurs as the logical first operand of
"?:".
51 stream.avail_out = left > (uLong)max ? max : (uInt)left;
52 left -= stream.avail_out;
53 }
54 if (stream.avail_in == 0) {
55 stream.avail_in = sourceLen > (uLong)max ? max :
(uInt)sourceLen;
56 sourceLen -= stream.avail_in;
** CID 1529955: Memory - corruptions (OVERRUN)
/cpukit/zlib/gzread.c: 323 in gz_read()
*** CID 1529955: Memory - corruptions (OVERRUN)
/cpukit/zlib/gzread.c: 323 in gz_read()
317 n = (unsigned)len;
318
319 /* first just try copying data from the output buffer */
320 if (state->x.have) {
321 if (state->x.have < n)
322 n = state->x.have;
>>> CID 1529955: Memory - corruptions (OVERRUN)
>>> Calling "memcpy" with "buf" and "n" is suspicious because of the
very large index, 4294967295. The index may be due to a negative parameter
being interpreted as unsigned.
323 memcpy(buf, state->x.next, n);
324 state->x.next += n;
325 state->x.have -= n;
326 }
327
328 /* output buffer empty -- return if we're at the end of the
input */
** CID 1529954: Integer handling issues (CONSTANT_EXPRESSION_RESULT)
/cpukit/zlib/uncompr.c: 63 in z_uncompress2()
*** CID 1529954: Integer handling issues (CONSTANT_EXPRESSION_RESULT)
/cpukit/zlib/uncompr.c: 63 in z_uncompress2()
57
58 stream.next_out = dest;
59 stream.avail_out = 0;
60
61 do {
62 if (stream.avail_out == 0) {
>>> CID 1529954: Integer handling issues (CONSTANT_EXPRESSION_RESULT)
>>> "left > 4294967295UL /* (z_uLong)max */" is always false regardless
of the values of its operands. This occurs as the logical first operand of
"?:".
63 stream.avail_out = left > (uLong)max ? max : (uInt)left;
64 left -= stream.avail_out;
65 }
66 if (stream.avail_in == 0) {
67 stream.avail_in = len > (uLong)max ? max : (uInt)len;
68 len -= stream.avail_in;
** CID 1529953: Integer handling issues (CONSTANT_EXPRESSION_RESULT)
/cpukit/zlib/compress.c: 55 in z_compress2()
__
Re: GSoC Contributor Introduction: Integrating Renode to RTEMS
First, congratulations on being accepted. This project was my idea initially so I hope it is as fruitful to the community as I hope. Second, use the devel@ mailing list since that is where most of the developers are. Other comments inline. On Wed, May 10, 2023 at 4:06 AM Muhammad Sulthan Mazaya < msulthanmaz...@gmail.com> wrote: > Hi everyone, > > My name is Mazaya, I am one of the Google Summer of Code contributors for > this summer. I will be working on integrating the renode.io simulator > into RTEMS. Renode (http://renode.io/) is an open source software > development framework with commercial support from Antmicro that lets you > develop, debug and test multi-node device systems for System on Chips (SoC) > and Internet of Things (IoT) devices. To learn more about my project, you > can go to the RTEMS wiki where you can access my proposal ( > https://devel.rtems.org/wiki/GSoC/2023) or you can see it from the GSoC > website ( > https://summerofcode.withgoogle.com/programs/2023/projects/bQeiZzHB). > > I hope to accomplish the following things this summer: > 1. document running RTEMS/leon3 on renode (including networking and > debugging) > This is known to work. I think Alan Cudmore has reproduced this and there is some information on the web about this: https://antmicro.com/blog/2021/09/leon3-support-in-renode/ I don't think you will be adding code to renode. I hope you will submit documentattion to them on running RTEMS on renode. I also expect additions to the RTEMS documentation on running each BSP you succeed with on renode. > 2. provide at least a basic resc script for other RTEMS bsps that can run > on renode > I would hope that you are able to run multiple BSPs on renode. That's one of the goals of this project in my mind. How many BSPs can you run on renode? STM32 is one which looks like it is well supported and we don't have another simulator option. https://interrupt.memfault.com/blog/intro-to-renode > 3. provide a build and install recipe for Renode in the RTEMS source > builder > Yep. Although this can evolve over the project. Focus on using it first. > 4. potentially figure out how to run the RTEMS test suite on the > renode-test framework > You want to use the rtems-test framework to run renode from the command line. This should be an early goal. It should not be particularly hard. If you can run it from the command line without a GUI, then it should be easy. We can model this support after qemu or sis. Now what they have for a framework is another matter. It would be nice to exercise more of the BSPs supported but testing more BSPs using renode.io is the first order. Make that easy for everyone. > > I will document the contribution in the RTEMS wiki ( > https://devel.rtems.org/wiki/GSoC/2023/add-support-for-renode-simulator) > and my personal website blog (https://www.mazaya.id/blogs?tag=GSoC). I am > truly looking forward to contributing to the RTEMS community. Hopefully, > the things that I eventually achieve this summer will be useful for the > community. > :) I'm looking forward to this. --joel > ___ > users mailing list > us...@rtems.org > http://lists.rtems.org/mailman/listinfo/users ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Fwd: Coverity Scan: Analysis completed for RTEMS
Another report from Coverity which shows more were introduced recently.
Unfortunately, their web UI doesn't help here. Per that, the most recently
"first detected" is from March and is in the jffs2 gc.c file:
135
const: At condition ({...; 0;}), the value of ({...; 0;}) must be equal to
0.
null: At condition ({...; 0;}), the value of ({...; 0;}) must be NULL.
dead_error_condition: The condition ({...; 0;}) cannot be true.
136if (mutex_lock_interruptible(&c->alloc_sem))
CID 1523448 (#1 of 1): Logically dead code (DEADCODE)dead_error_line: Execution
cannot reach this statement: return -4;.
137return -EINTR;
I have no idea what the other new issues are. :(
Anyone else figure it out?
--joel
-- Forwarded message -
From:
Date: Wed, May 10, 2023 at 12:21 AM
Subject: Coverity Scan: Analysis completed for RTEMS
To:
Your request for analysis of RTEMS has been completed successfully.
The results are available at
https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50ypUUzi-2FdSNmuyRB7BEFT8xQ81HXwCHW32Mihy8bA1BUtQ-3D-3DXv8Q_CTvEjVoKhyc6dLmJJo1u9AYIk8P8bcAbCPbBDYvYSXoRifeznD-2F20WffDcjOQq9n9YY3b15WgQq2UkJA9ViPExfgcVwXhZXGPGFnc9PYG7sRlBvtviauPdHuZJFG9b7rIf-2BcTbfFQ4JEBqB1T6zPz-2FByDFBGY0O6oRlmhA-2FceIOeYLAC-2BNXNkd4ZpyVBJ7TnQsoXXsJLCXVaSnKyQJeU0ioEiJFKWLRoEno1Cr-2BeEa8-3D
Build ID: 531257
Analysis Summary:
New defects found: 7
Defects eliminated: 2
If you have difficulty understanding any defects, email us at
scan-ad...@coverity.com,
or post your question to StackOverflow
at
https://u15810271.ct.sendgrid.net/ls/click?upn=CTPegkVN6peWFCMEieYYmPWIi1E4yUS9EoqKFcNAiqhRq8qmgeBE-2Bdt3uvFRAFXd-2FlwX83-2FVVdybfzIMOby0qA-3D-3DL7H2_CTvEjVoKhyc6dLmJJo1u9AYIk8P8bcAbCPbBDYvYSXoRifeznD-2F20WffDcjOQq9n9YY3b15WgQq2UkJA9ViPEwm9NBJLNJpsLlYV23pZJZjFv6g-2FvK8QA-2BPJxaoHD5cz0Kuq95gJ7rRS2xSXTSYrKAq5pHKcRcWUiDMT5YfrWrt4Ovg36hvRxUGQU-2FFaIJocQZt8H0vuqPxeJqF6FLYuLT5twSijVMDx3KS10MNZmIo-3D
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Fwd: New Defects reported by Coverity Scan for RTEMS
Hello Joel, On 10.05.23 15:33, Joel Sherrill wrote: Sebastian I know this is third party code that you just imported but this looks like a potentially serious issue. Does anyone see how this could occur? Have a suggestion? Minimum is to report it upstream. I did that years ago with another issue in zlib. yes, we should report this upstream. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-source-builder] devel/qemu-xilinx: Fix source URL
On Mon, May 8, 2023 at 1:28 PM Gedare Bloom wrote: > > I think the https works though? Or does it break? > > I recall there are sometimes issues that users face based on their IT > site policy that prevents git protocol from working properly while > https almost always works (tunnels) right. Hi Gedare, The build was broken before this patch. HTTPS does work, yes, and this patch does not change the protocol. This just changes how the source is handled by the RSB scripts. To get the git handling to work, the URL needs to start with 'git://'. It still uses HTTPS since it specifies '?protocol=https' in the URL. Thanks, Alex ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
