Re: [OE-core] [meta][dunfell][PATCH] rpm: Handle proper return value to avoid major issues and removing unnecessary code

2021-09-15 Thread Steve Sakoman
On Wed, Sep 15, 2021 at 5:43 AM Ranjitsinh Rathod <
ranjitsinh.rat...@kpit.com> wrote:

> Hi Steve,
>
> If you wanted to take changes only for the 
> 0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
> then you can cherry-pick it from master as I have submitted it for master
> and it is available on master branch now. Below is the link.
> poky - Poky Build Tool and Metadata (yoctoproject.org)
> <https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=9886ef691aa117d67e4342c6a5e3f79f6a05f8d5>
>
> Do you still want me to send v2 patch here?
>

No need, I'll cherry-pick the patch from master.

Thanks!

Steve


>
> Thanks,
>
> Best Regards,
>
> *Ranjitsinh Rathod*
> Technical Leader |  | KPIT Technologies Ltd.
> Cellphone: +91-84606 92403
>
> *__ *KPIT <http://www.kpit.com/> |
>  Follow us on LinkedIn <http://www.kpit.com/linkedin>
>
> <https://www.kpit.com/TheNewBrand>
> --
> *From:* openembedded-core@lists.openembedded.org <
> openembedded-core@lists.openembedded.org> on behalf of Alexander Kanavin
> via lists.openembedded.org 
> *Sent:* Wednesday, September 15, 2021 8:36 PM
> *To:* Steve Sakoman 
> *Cc:* Ranjitsinh Rathod ; Patches and
> discussions about the oe-core layer <
> openembedded-core@lists.openembedded.org>; Ranjitsinh Rathod <
> ranjitsinh.rat...@kpit.com>
> *Subject:* Re: [OE-core] [meta][dunfell][PATCH] rpm: Handle proper return
> value to avoid major issues and removing unnecessary code
>
> Caution: This email originated from outside of the KPIT. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
> At this point I have to note that I am removing the patch altogether with
> the upcoming upgrade of rpm to 4.17, as I'm also switching the compression
> format to zstd, and the patch is generally difficult to maintain and
> rebase. If you care about xz compression, please do work with upstream to
> get it merged there.
>
> Alex
>
> On Wed, 15 Sept 2021 at 16:59, Steve Sakoman  wrote:
>
> On Wed, Sep 8, 2021 at 4:02 AM Ranjitsinh Rathod
>  wrote:
> >
> > From: Ranjitsinh Rathod 
> >
> > Change in 2 patch as below to avoid critical issues
> > 1) 0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
> > Handled return values of getrlimit() and lzma_cputhreads() functions
> > to avoid unexpected behaviours like devide by zero and potential read
> > of uninitialized variable 'virtual_memory'
> > Upstream-Status: Pending [merge of multithreading patches to upstream]
>
> This does look like a good fix.  Are these changes to the patch from
> upstream?
>
> Once upstream has accepted the change we should change the status from
> "pending", but for now this is ok.
>
> > 2) CVE-2021-3421.patch
> > Removed RPMSIGTAG_FILESIGNATURES and RPMSIGTAG_FILESIGNATURELENGTH as
> > it is not needed during backporting of original patch.
> > Upstream-Status: Backport [
> https://github.com/rpm-software-management/rpm/commit/d6a86b5e69e46cc283b1e06c92343319beb42e21
> <https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frpm-software-management%2Frpm%2Fcommit%2Fd6a86b5e69e46cc283b1e06c92343319beb42e21=04%7C01%7Cranjitsinh.rathod%40kpit.com%7Cdfd54731b1a240ea64ed08d9785a7618%7C3539451eb46e4a26a242ff61502855c7%7C0%7C0%7C637673152237746428%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=BFoFI3j9RjhqXQi1tSqfoVoS2strOChMcswosTH59Fs%3D=0>
> ]
>
> Removing these unused definitions doesn't really seem like a critical
> issue. I'd prefer to leave the CVE patch in its original form.
>
> Could you submit a V2 with this change?
>
> Thanks!
>
> Steve
>
> > Signed-off-by: Ranjitsinh Rathod 
> > ---
> >  ...rict-virtual-memory-usage-if-limit-s.patch | 25 ---
> >  .../rpm/files/CVE-2021-3421.patch | 32 +++
> >  2 files changed, 19 insertions(+), 38 deletions(-)
> >
> > diff --git
> a/meta/recipes-devtools/rpm/files/0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
> b/meta/recipes-devtools/rpm/files/0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
> > index 6454785254..dc3f74fecd 100644
> > ---
> a/meta/recipes-devtools/rpm/files/0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
> > +++
> b/meta/recipes-devtools/rpm/files/0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
> > @@ -11,36 +11,39 @@ CPU thread.
> >  Upstream-Status: Pending [merge of multithreading patches to upstream]
>

Re: [OE-core] [meta][dunfell][PATCH] rpm: Handle proper return value to avoid major issues and removing unnecessary code

2021-09-15 Thread Ranjitsinh Rathod
Hi Steve,

If you wanted to take changes only for the 
0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch then you can 
cherry-pick it from master as I have submitted it for master and it is 
available on master branch now. Below is the link.
poky - Poky Build Tool and Metadata 
(yoctoproject.org)<https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=9886ef691aa117d67e4342c6a5e3f79f6a05f8d5>

Do you still want me to send v2 patch here?


Thanks,

Best Regards,

Ranjitsinh Rathod
Technical Leader |  | KPIT Technologies Ltd.
Cellphone: +91-84606 92403
__
KPIT<http://www.kpit.com/> | Follow us on LinkedIn<http://www.kpit.com/linkedin>

[cid:05fb0115-01bd-4421-ae2f-587c78415386]<https://www.kpit.com/TheNewBrand>


From: openembedded-core@lists.openembedded.org 
 on behalf of Alexander Kanavin via 
lists.openembedded.org 
Sent: Wednesday, September 15, 2021 8:36 PM
To: Steve Sakoman 
Cc: Ranjitsinh Rathod ; Patches and discussions 
about the oe-core layer ; Ranjitsinh 
Rathod 
Subject: Re: [OE-core] [meta][dunfell][PATCH] rpm: Handle proper return value 
to avoid major issues and removing unnecessary code

Caution: This email originated from outside of the KPIT. Do not click links or 
open attachments unless you recognize the sender and know the content is safe.
At this point I have to note that I am removing the patch altogether with the 
upcoming upgrade of rpm to 4.17, as I'm also switching the compression format 
to zstd, and the patch is generally difficult to maintain and rebase. If you 
care about xz compression, please do work with upstream to get it merged there.

Alex

On Wed, 15 Sept 2021 at 16:59, Steve Sakoman 
mailto:st...@sakoman.com>> wrote:
On Wed, Sep 8, 2021 at 4:02 AM Ranjitsinh Rathod
mailto:ranjitsinhrathod1...@gmail.com>> wrote:
>
> From: Ranjitsinh Rathod 
> mailto:ranjitsinh.rat...@kpit.com>>
>
> Change in 2 patch as below to avoid critical issues
> 1) 0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
> Handled return values of getrlimit() and lzma_cputhreads() functions
> to avoid unexpected behaviours like devide by zero and potential read
> of uninitialized variable 'virtual_memory'
> Upstream-Status: Pending [merge of multithreading patches to upstream]

This does look like a good fix.  Are these changes to the patch from upstream?

Once upstream has accepted the change we should change the status from
"pending", but for now this is ok.

> 2) CVE-2021-3421.patch
> Removed RPMSIGTAG_FILESIGNATURES and RPMSIGTAG_FILESIGNATURELENGTH as
> it is not needed during backporting of original patch.
> Upstream-Status: Backport 
> [https://github.com/rpm-software-management/rpm/commit/d6a86b5e69e46cc283b1e06c92343319beb42e21<https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frpm-software-management%2Frpm%2Fcommit%2Fd6a86b5e69e46cc283b1e06c92343319beb42e21=04%7C01%7Cranjitsinh.rathod%40kpit.com%7Cdfd54731b1a240ea64ed08d9785a7618%7C3539451eb46e4a26a242ff61502855c7%7C0%7C0%7C637673152237746428%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=BFoFI3j9RjhqXQi1tSqfoVoS2strOChMcswosTH59Fs%3D=0>]

Removing these unused definitions doesn't really seem like a critical
issue. I'd prefer to leave the CVE patch in its original form.

Could you submit a V2 with this change?

Thanks!

Steve

> Signed-off-by: Ranjitsinh Rathod 
> mailto:ranjitsinh.rat...@kpit.com>>
> ---
>  ...rict-virtual-memory-usage-if-limit-s.patch | 25 ---
>  .../rpm/files/CVE-2021-3421.patch | 32 +++
>  2 files changed, 19 insertions(+), 38 deletions(-)
>
> diff --git 
> a/meta/recipes-devtools/rpm/files/0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
>  
> b/meta/recipes-devtools/rpm/files/0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
> index 6454785254..dc3f74fecd 100644
> --- 
> a/meta/recipes-devtools/rpm/files/0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
> +++ 
> b/meta/recipes-devtools/rpm/files/0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
> @@ -11,36 +11,39 @@ CPU thread.
>  Upstream-Status: Pending [merge of multithreading patches to upstream]
>
>  Signed-off-by: Peter Bergin 
> mailto:pe...@berginkonsult.se>>
> +Signed-off-by: Ranjitsinh Rathod 
> mailto:ranjitsinh.rat...@kpit.com>>
>  ---
> - rpmio/rpmio.c | 34 ++
> - 1 file changed, 34 insertions(+)
> + rpmio/rpmio.c | 36 
> + 1 file changed, 36 insertions(+)
>
>  diff --git a/rpmio/rpmio.c b/rpmio/rpmio.c
>  index e051c98..b3c56b6 100644
>  --- a/rpmio/rpmio.c
>  +++ b/rpmio/rpmio.c
> -@@ -845,6 +845,

Re: [OE-core] [meta][dunfell][PATCH] rpm: Handle proper return value to avoid major issues and removing unnecessary code

2021-09-15 Thread Alexander Kanavin
At this point I have to note that I am removing the patch altogether with
the upcoming upgrade of rpm to 4.17, as I'm also switching the compression
format to zstd, and the patch is generally difficult to maintain and
rebase. If you care about xz compression, please do work with upstream to
get it merged there.

Alex

On Wed, 15 Sept 2021 at 16:59, Steve Sakoman  wrote:

> On Wed, Sep 8, 2021 at 4:02 AM Ranjitsinh Rathod
>  wrote:
> >
> > From: Ranjitsinh Rathod 
> >
> > Change in 2 patch as below to avoid critical issues
> > 1) 0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
> > Handled return values of getrlimit() and lzma_cputhreads() functions
> > to avoid unexpected behaviours like devide by zero and potential read
> > of uninitialized variable 'virtual_memory'
> > Upstream-Status: Pending [merge of multithreading patches to upstream]
>
> This does look like a good fix.  Are these changes to the patch from
> upstream?
>
> Once upstream has accepted the change we should change the status from
> "pending", but for now this is ok.
>
> > 2) CVE-2021-3421.patch
> > Removed RPMSIGTAG_FILESIGNATURES and RPMSIGTAG_FILESIGNATURELENGTH as
> > it is not needed during backporting of original patch.
> > Upstream-Status: Backport [
> https://github.com/rpm-software-management/rpm/commit/d6a86b5e69e46cc283b1e06c92343319beb42e21
> ]
>
> Removing these unused definitions doesn't really seem like a critical
> issue. I'd prefer to leave the CVE patch in its original form.
>
> Could you submit a V2 with this change?
>
> Thanks!
>
> Steve
>
> > Signed-off-by: Ranjitsinh Rathod 
> > ---
> >  ...rict-virtual-memory-usage-if-limit-s.patch | 25 ---
> >  .../rpm/files/CVE-2021-3421.patch | 32 +++
> >  2 files changed, 19 insertions(+), 38 deletions(-)
> >
> > diff --git
> a/meta/recipes-devtools/rpm/files/0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
> b/meta/recipes-devtools/rpm/files/0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
> > index 6454785254..dc3f74fecd 100644
> > ---
> a/meta/recipes-devtools/rpm/files/0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
> > +++
> b/meta/recipes-devtools/rpm/files/0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
> > @@ -11,36 +11,39 @@ CPU thread.
> >  Upstream-Status: Pending [merge of multithreading patches to upstream]
> >
> >  Signed-off-by: Peter Bergin 
> > +Signed-off-by: Ranjitsinh Rathod 
> >  ---
> > - rpmio/rpmio.c | 34 ++
> > - 1 file changed, 34 insertions(+)
> > + rpmio/rpmio.c | 36 
> > + 1 file changed, 36 insertions(+)
> >
> >  diff --git a/rpmio/rpmio.c b/rpmio/rpmio.c
> >  index e051c98..b3c56b6 100644
> >  --- a/rpmio/rpmio.c
> >  +++ b/rpmio/rpmio.c
> > -@@ -845,6 +845,40 @@ static LZFILE *lzopen_internal(const char *mode,
> int fd, int xz)
> > +@@ -845,6 +845,42 @@ static LZFILE *lzopen_internal(const char *mode,
> int fd, int xz)
> > }
> >   #endif
> >
> > -+  struct rlimit virtual_memory;
> > -+  getrlimit(RLIMIT_AS, _memory);
> > -+  if (virtual_memory.rlim_cur != RLIM_INFINITY) {
> > ++  struct rlimit virtual_memory = {RLIM_INFINITY ,
> RLIM_INFINITY};
> > ++  int status = getrlimit(RLIMIT_AS, _memory);
> > ++  if ((status != -1) && (virtual_memory.rlim_cur !=
> RLIM_INFINITY)) {
> >  +  const uint64_t virtual_memlimit =
> virtual_memory.rlim_cur;
> > ++  uint32_t threads_max = lzma_cputhreads();
> >  +  const uint64_t virtual_memlimit_per_cpu_thread =
> > -+  virtual_memlimit / lzma_cputhreads();
> > -+  uint64_t memory_usage_virt;
> > ++  virtual_memlimit / ((threads_max == 0) ?
> 1 : threads_max);
> >  +  rpmlog(RPMLOG_NOTICE, "XZ: virtual memory
> restricted to %lu and "
> >  + "per CPU thread %lu\n", virtual_memlimit,
> virtual_memlimit_per_cpu_thread);
> > ++  uint64_t memory_usage_virt;
> >  +  /* keep reducing the number of compression
> threads until memory
> >  + usage falls below the limit per CPU thread*/
> >  +  while ((memory_usage_virt =
> lzma_stream_encoder_mt_memusage(_options)) >
> >  + virtual_memlimit_per_cpu_thread) {
> > -+  /* If number of threads goes down to
> zero lzma_stream_encoder will
> > -+   * will return UINT64_MAX. We must check
> here to avoid an infinite loop.
> > ++  /* If number of threads goes down to
> zero or in case of any other error
> > ++   * lzma_stream_encoder_mt_memusage will
> return UINT64_MAX. We must check
> > ++

Re: [OE-core] [meta][dunfell][PATCH] rpm: Handle proper return value to avoid major issues and removing unnecessary code

2021-09-15 Thread Steve Sakoman
On Wed, Sep 8, 2021 at 4:02 AM Ranjitsinh Rathod
 wrote:
>
> From: Ranjitsinh Rathod 
>
> Change in 2 patch as below to avoid critical issues
> 1) 0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
> Handled return values of getrlimit() and lzma_cputhreads() functions
> to avoid unexpected behaviours like devide by zero and potential read
> of uninitialized variable 'virtual_memory'
> Upstream-Status: Pending [merge of multithreading patches to upstream]

This does look like a good fix.  Are these changes to the patch from upstream?

Once upstream has accepted the change we should change the status from
"pending", but for now this is ok.

> 2) CVE-2021-3421.patch
> Removed RPMSIGTAG_FILESIGNATURES and RPMSIGTAG_FILESIGNATURELENGTH as
> it is not needed during backporting of original patch.
> Upstream-Status: Backport 
> [https://github.com/rpm-software-management/rpm/commit/d6a86b5e69e46cc283b1e06c92343319beb42e21]

Removing these unused definitions doesn't really seem like a critical
issue. I'd prefer to leave the CVE patch in its original form.

Could you submit a V2 with this change?

Thanks!

Steve

> Signed-off-by: Ranjitsinh Rathod 
> ---
>  ...rict-virtual-memory-usage-if-limit-s.patch | 25 ---
>  .../rpm/files/CVE-2021-3421.patch | 32 +++
>  2 files changed, 19 insertions(+), 38 deletions(-)
>
> diff --git 
> a/meta/recipes-devtools/rpm/files/0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
>  
> b/meta/recipes-devtools/rpm/files/0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
> index 6454785254..dc3f74fecd 100644
> --- 
> a/meta/recipes-devtools/rpm/files/0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
> +++ 
> b/meta/recipes-devtools/rpm/files/0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
> @@ -11,36 +11,39 @@ CPU thread.
>  Upstream-Status: Pending [merge of multithreading patches to upstream]
>
>  Signed-off-by: Peter Bergin 
> +Signed-off-by: Ranjitsinh Rathod 
>  ---
> - rpmio/rpmio.c | 34 ++
> - 1 file changed, 34 insertions(+)
> + rpmio/rpmio.c | 36 
> + 1 file changed, 36 insertions(+)
>
>  diff --git a/rpmio/rpmio.c b/rpmio/rpmio.c
>  index e051c98..b3c56b6 100644
>  --- a/rpmio/rpmio.c
>  +++ b/rpmio/rpmio.c
> -@@ -845,6 +845,40 @@ static LZFILE *lzopen_internal(const char *mode, int 
> fd, int xz)
> +@@ -845,6 +845,42 @@ static LZFILE *lzopen_internal(const char *mode, int 
> fd, int xz)
> }
>   #endif
>
> -+  struct rlimit virtual_memory;
> -+  getrlimit(RLIMIT_AS, _memory);
> -+  if (virtual_memory.rlim_cur != RLIM_INFINITY) {
> ++  struct rlimit virtual_memory = {RLIM_INFINITY , 
> RLIM_INFINITY};
> ++  int status = getrlimit(RLIMIT_AS, _memory);
> ++  if ((status != -1) && (virtual_memory.rlim_cur != 
> RLIM_INFINITY)) {
>  +  const uint64_t virtual_memlimit = 
> virtual_memory.rlim_cur;
> ++  uint32_t threads_max = lzma_cputhreads();
>  +  const uint64_t virtual_memlimit_per_cpu_thread =
> -+  virtual_memlimit / lzma_cputhreads();
> -+  uint64_t memory_usage_virt;
> ++  virtual_memlimit / ((threads_max == 0) ? 1 : 
> threads_max);
>  +  rpmlog(RPMLOG_NOTICE, "XZ: virtual memory restricted 
> to %lu and "
>  + "per CPU thread %lu\n", virtual_memlimit, 
> virtual_memlimit_per_cpu_thread);
> ++  uint64_t memory_usage_virt;
>  +  /* keep reducing the number of compression threads 
> until memory
>  + usage falls below the limit per CPU thread*/
>  +  while ((memory_usage_virt = 
> lzma_stream_encoder_mt_memusage(_options)) >
>  + virtual_memlimit_per_cpu_thread) {
> -+  /* If number of threads goes down to zero 
> lzma_stream_encoder will
> -+   * will return UINT64_MAX. We must check here 
> to avoid an infinite loop.
> ++  /* If number of threads goes down to zero or 
> in case of any other error
> ++   * lzma_stream_encoder_mt_memusage will 
> return UINT64_MAX. We must check
> ++   * for both the cases here to avoid an 
> infinite loop.
>  +   * If we get into situation that one thread 
> requires more virtual memory
>  +   * than available we set one thread, print 
> error message and try anyway. */
> -+  if (--mt_options.threads == 0) {
> ++  if ((--mt_options.threads == 0) || 
> (memory_usage_virt == UINT64_MAX)) {
>  +  

Re: [OE-core] [meta][dunfell][PATCH] rpm: Handle proper return value to avoid major issues and removing unnecessary code

2021-09-13 Thread Minjae Kim
[Edited Message Follows]

On Mon, Sep 13, 2021 at 11:34 AM, Steve Sakoman wrote:

> 
> RPMSIGTAG_FILESIGNATURELENGTH

Hi, Steve and Ranjitsinh,
Sorry for the late response.
I know that the RPMSIGTAG_FILESIGNATURES and RPMSIGTAG_FILESIGNATURELENGTH are 
defined in the original commit, but are not used.
I left it with the author`s intent. If the build goes well without those 
variables, it doesn't seem to matter.

Thanks,
Minjae Kim.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155997): 
https://lists.openembedded.org/g/openembedded-core/message/155997
Mute This Topic: https://lists.openembedded.org/mt/85459532/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [meta][dunfell][PATCH] rpm: Handle proper return value to avoid major issues and removing unnecessary code

2021-09-13 Thread Minjae Kim
On Mon, Sep 13, 2021 at 11:34 AM, Steve Sakoman wrote:

> 
> RPMSIGTAG_FILESIGNATURELENGTH

Sorry for the late reponse.
I know that the RPMSIGTAG_FILESIGNATURES and RPMSIGTAG_FILESIGNATURELENGTH are 
defined in the original commit, but are not used.
I left it with the author`s intent. If the build goes well without those 
variables, it doesn't seem to matter.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155997): 
https://lists.openembedded.org/g/openembedded-core/message/155997
Mute This Topic: https://lists.openembedded.org/mt/85459532/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [meta][dunfell][PATCH] rpm: Handle proper return value to avoid major issues and removing unnecessary code

2021-09-13 Thread Steve Sakoman
On Wed, Sep 8, 2021 at 4:02 AM Ranjitsinh Rathod
 wrote:
>
> From: Ranjitsinh Rathod 
>
> Change in 2 patch as below to avoid critical issues
> 1) 0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
> Handled return values of getrlimit() and lzma_cputhreads() functions
> to avoid unexpected behaviours like devide by zero and potential read
> of uninitialized variable 'virtual_memory'
> Upstream-Status: Pending [merge of multithreading patches to upstream]
>
> 2) CVE-2021-3421.patch
> Removed RPMSIGTAG_FILESIGNATURES and RPMSIGTAG_FILESIGNATURELENGTH as
> it is not needed during backporting of original patch.
> Upstream-Status: Backport 
> [https://github.com/rpm-software-management/rpm/commit/d6a86b5e69e46cc283b1e06c92343319beb42e21]

Minjae, can you review this since he is modifying your CVE patch?

Thanks!

Steve

> Signed-off-by: Ranjitsinh Rathod 
> ---
>  ...rict-virtual-memory-usage-if-limit-s.patch | 25 ---
>  .../rpm/files/CVE-2021-3421.patch | 32 +++
>  2 files changed, 19 insertions(+), 38 deletions(-)
>
> diff --git 
> a/meta/recipes-devtools/rpm/files/0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
>  
> b/meta/recipes-devtools/rpm/files/0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
> index 6454785254..dc3f74fecd 100644
> --- 
> a/meta/recipes-devtools/rpm/files/0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
> +++ 
> b/meta/recipes-devtools/rpm/files/0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
> @@ -11,36 +11,39 @@ CPU thread.
>  Upstream-Status: Pending [merge of multithreading patches to upstream]
>
>  Signed-off-by: Peter Bergin 
> +Signed-off-by: Ranjitsinh Rathod 
>  ---
> - rpmio/rpmio.c | 34 ++
> - 1 file changed, 34 insertions(+)
> + rpmio/rpmio.c | 36 
> + 1 file changed, 36 insertions(+)
>
>  diff --git a/rpmio/rpmio.c b/rpmio/rpmio.c
>  index e051c98..b3c56b6 100644
>  --- a/rpmio/rpmio.c
>  +++ b/rpmio/rpmio.c
> -@@ -845,6 +845,40 @@ static LZFILE *lzopen_internal(const char *mode, int 
> fd, int xz)
> +@@ -845,6 +845,42 @@ static LZFILE *lzopen_internal(const char *mode, int 
> fd, int xz)
> }
>   #endif
>
> -+  struct rlimit virtual_memory;
> -+  getrlimit(RLIMIT_AS, _memory);
> -+  if (virtual_memory.rlim_cur != RLIM_INFINITY) {
> ++  struct rlimit virtual_memory = {RLIM_INFINITY , 
> RLIM_INFINITY};
> ++  int status = getrlimit(RLIMIT_AS, _memory);
> ++  if ((status != -1) && (virtual_memory.rlim_cur != 
> RLIM_INFINITY)) {
>  +  const uint64_t virtual_memlimit = 
> virtual_memory.rlim_cur;
> ++  uint32_t threads_max = lzma_cputhreads();
>  +  const uint64_t virtual_memlimit_per_cpu_thread =
> -+  virtual_memlimit / lzma_cputhreads();
> -+  uint64_t memory_usage_virt;
> ++  virtual_memlimit / ((threads_max == 0) ? 1 : 
> threads_max);
>  +  rpmlog(RPMLOG_NOTICE, "XZ: virtual memory restricted 
> to %lu and "
>  + "per CPU thread %lu\n", virtual_memlimit, 
> virtual_memlimit_per_cpu_thread);
> ++  uint64_t memory_usage_virt;
>  +  /* keep reducing the number of compression threads 
> until memory
>  + usage falls below the limit per CPU thread*/
>  +  while ((memory_usage_virt = 
> lzma_stream_encoder_mt_memusage(_options)) >
>  + virtual_memlimit_per_cpu_thread) {
> -+  /* If number of threads goes down to zero 
> lzma_stream_encoder will
> -+   * will return UINT64_MAX. We must check here 
> to avoid an infinite loop.
> ++  /* If number of threads goes down to zero or 
> in case of any other error
> ++   * lzma_stream_encoder_mt_memusage will 
> return UINT64_MAX. We must check
> ++   * for both the cases here to avoid an 
> infinite loop.
>  +   * If we get into situation that one thread 
> requires more virtual memory
>  +   * than available we set one thread, print 
> error message and try anyway. */
> -+  if (--mt_options.threads == 0) {
> ++  if ((--mt_options.threads == 0) || 
> (memory_usage_virt == UINT64_MAX)) {
>  +  mt_options.threads = 1;
>  +  rpmlog(RPMLOG_WARNING,
>  + "XZ: Could not adjust number 
> of threads to get below "
> diff --git a/meta/recipes-devtools/rpm/files/CVE-2021-3421.patch 
> 

Re: [OE-core] [meta][dunfell][PATCH] rpm: Handle proper return value to avoid major issues and removing unnecessary code

2021-09-13 Thread Ranjitsinh Rathod
Can someone please check this and confirm if this can go on dunfell?

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155984): 
https://lists.openembedded.org/g/openembedded-core/message/155984
Mute This Topic: https://lists.openembedded.org/mt/85459532/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-