Openembedded Core Discussions
 help / color / mirror / Atom feed
* [OE-core][walnascar 00/14] Patch review
@ 2025-05-28 15:33 Steve Sakoman
  2025-05-28 15:33 ` [OE-core][walnascar 01/14] sqlite3: patch CVE-2025-3277 Steve Sakoman
                   ` (13 more replies)
  0 siblings, 14 replies; 15+ messages in thread
From: Steve Sakoman @ 2025-05-28 15:33 UTC (permalink / raw)
  To: openembedded-core

Please review this set of changes for walnascar and have comments back by
end of day Friday, May 30

Passed a-full on autobuilder:

https://autobuilder.yoctoproject.org/valkyrie/#/builders/29/builds/1673

The following changes since commit 17affdaa600896282e07fb4d64cb23195673baa1:

  build-appliance-image: Update to walnascar head revision (2025-05-23 08:43:13 -0700)

are available in the Git repository at:

  https://git.openembedded.org/openembedded-core-contrib stable/walnascar-nut
  https://git.openembedded.org/openembedded-core-contrib/log/?h=stable/walnascar-nut

Deepesh Varatharajan (1):
  binutils: Fix CVE-2025-1178

Gyorgy Sarvari (1):
  libmatchbox: upgrade 1.13 -> 1.14

Harish Sadineni (1):
  binutils: Fix CVE-2025-1180

Peter Marko (8):
  sqlite3: patch CVE-2025-3277
  sqlite3: patch CVE-2025-29088
  sqlite3: mark CVE-2025-29087 as patched
  ofono: patch CVE-2024-7537
  xz: patch CVE-2025-31115
  binutils: drop obsolete CVE_STATUS
  binutils: mark CVE-2025-1153 as fixed
  libarchive: upgrade 3.7.8 -> 3.7.9

Wang Mingyu (1):
  epiphany: upgrade 48.0 -> 48.3

Yash Shinde (1):
  gcc: fix incorrect preprocessor line numbers in large files

Yi Zhao (1):
  python3-pygobject: RDEPENDS on gobject-introspection

 .../ofono/ofono/CVE-2024-7537.patch           |  59 +++
 meta/recipes-connectivity/ofono/ofono_2.15.bb |   1 +
 .../binutils/binutils-2.44.inc                |   4 +-
 .../binutils/0015-CVE-2025-1178.patch         |  33 ++
 .../binutils/binutils/CVE-2025-1180.patch     | 165 ++++++
 meta/recipes-devtools/gcc/gcc-14.2.inc        |   1 +
 ...-incorrect-preprocessor-line-numbers.patch | 475 ++++++++++++++++++
 .../python/python3-pygobject_3.52.2.bb        |   1 +
 ...ibarchive_3.7.8.bb => libarchive_3.7.9.bb} |   4 +-
 .../xz/xz/CVE-2025-31115-01.patch             |  29 ++
 .../xz/xz/CVE-2025-31115-02.patch             | 152 ++++++
 .../xz/xz/CVE-2025-31115-03.patch             |  98 ++++
 .../xz/xz/CVE-2025-31115-04.patch             |  56 +++
 meta/recipes-extended/xz/xz_5.6.4.bb          |   4 +
 .../{epiphany_48.0.bb => epiphany_48.3.bb}    |   2 +-
 ...ibmatchbox_1.13.bb => libmatchbox_1.14.bb} |   2 +-
 .../sqlite/sqlite3/CVE-2025-29088.patch       | 179 +++++++
 .../sqlite/sqlite3/CVE-2025-3277.patch        |  29 ++
 meta/recipes-support/sqlite/sqlite3_3.48.0.bb |   5 +-
 19 files changed, 1292 insertions(+), 7 deletions(-)
 create mode 100644 meta/recipes-connectivity/ofono/ofono/CVE-2024-7537.patch
 create mode 100644 meta/recipes-devtools/binutils/binutils/0015-CVE-2025-1178.patch
 create mode 100644 meta/recipes-devtools/binutils/binutils/CVE-2025-1180.patch
 create mode 100644 meta/recipes-devtools/gcc/gcc/0028-fix-incorrect-preprocessor-line-numbers.patch
 rename meta/recipes-extended/libarchive/{libarchive_3.7.8.bb => libarchive_3.7.9.bb} (91%)
 create mode 100644 meta/recipes-extended/xz/xz/CVE-2025-31115-01.patch
 create mode 100644 meta/recipes-extended/xz/xz/CVE-2025-31115-02.patch
 create mode 100644 meta/recipes-extended/xz/xz/CVE-2025-31115-03.patch
 create mode 100644 meta/recipes-extended/xz/xz/CVE-2025-31115-04.patch
 rename meta/recipes-gnome/epiphany/{epiphany_48.0.bb => epiphany_48.3.bb} (94%)
 rename meta/recipes-graphics/libmatchbox/{libmatchbox_1.13.bb => libmatchbox_1.14.bb} (95%)
 create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2025-29088.patch
 create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2025-3277.patch

-- 
2.43.0



^ permalink raw reply	[flat|nested] 15+ messages in thread

* [OE-core][walnascar 01/14] sqlite3: patch CVE-2025-3277
  2025-05-28 15:33 [OE-core][walnascar 00/14] Patch review Steve Sakoman
@ 2025-05-28 15:33 ` Steve Sakoman
  2025-05-28 15:33 ` [OE-core][walnascar 02/14] sqlite3: patch CVE-2025-29088 Steve Sakoman
                   ` (12 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: Steve Sakoman @ 2025-05-28 15:33 UTC (permalink / raw)
  To: openembedded-core

From: Peter Marko <peter.marko@siemens.com>

Pick commit [1] mentioned in [2].

[1] https://sqlite.org/src/info/498e3f1cf57f164f
[2] https://nvd.nist.gov/vuln/detail/CVE-2025-3277

Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
 .../sqlite/sqlite3/CVE-2025-3277.patch        | 28 +++++++++++++++++++
 meta/recipes-support/sqlite/sqlite3_3.48.0.bb |  4 ++-
 2 files changed, 31 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2025-3277.patch

diff --git a/meta/recipes-support/sqlite/sqlite3/CVE-2025-3277.patch b/meta/recipes-support/sqlite/sqlite3/CVE-2025-3277.patch
new file mode 100644
index 0000000000..8264d4443a
--- /dev/null
+++ b/meta/recipes-support/sqlite/sqlite3/CVE-2025-3277.patch
@@ -0,0 +1,28 @@
+From d7f45414935e4ef6e3361f02a22876f1ee7a04aa Mon Sep 17 00:00:00 2001
+From: drh <>
+Date: Sun, 16 Feb 2025 10:57:25 +0000
+Subject: [PATCH] Add a typecast to avoid 32-bit integer overflow in the
+ concat_ws() function with an enormous separator values and many arguments.
+
+FossilOrigin-Name: 498e3f1cf57f164fbd8380e92bf91b9f26d6aa05d092fcd135d754abf1e5b1b5
+
+CVE: CVE-2025-3277
+Upstream-Status: Backport [https://sqlite.org/src/info/498e3f1cf57f164f]
+Signed-off-by: Peter Marko <peter.marko@siemens.com>
+---
+ sqlite3.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/sqlite3.c b/sqlite3.c
+index 08c593e55c..24d0d954d9 100644
+--- a/sqlite3.c
++++ b/sqlite3.c
+@@ -130954,7 +130954,7 @@ static void concatFuncCore(
+   for(i=0; i<argc; i++){
+     n += sqlite3_value_bytes(argv[i]);
+   }
+-  n += (argc-1)*nSep;
++  n += (argc-1)*(i64)nSep;
+   z = sqlite3_malloc64(n+1);
+   if( z==0 ){
+     sqlite3_result_error_nomem(context);
diff --git a/meta/recipes-support/sqlite/sqlite3_3.48.0.bb b/meta/recipes-support/sqlite/sqlite3_3.48.0.bb
index bd2ac6614d..86983f21bd 100644
--- a/meta/recipes-support/sqlite/sqlite3_3.48.0.bb
+++ b/meta/recipes-support/sqlite/sqlite3_3.48.0.bb
@@ -3,6 +3,8 @@ require sqlite3.inc
 LICENSE = "PD"
 LIC_FILES_CHKSUM = "file://sqlite3.h;endline=11;md5=786d3dc581eff03f4fd9e4a77ed00c66"
 
-SRC_URI = "http://www.sqlite.org/2025/sqlite-autoconf-${SQLITE_PV}.tar.gz"
+SRC_URI = "http://www.sqlite.org/2025/sqlite-autoconf-${SQLITE_PV}.tar.gz \
+    file://CVE-2025-3277.patch \
+"
 SRC_URI[sha256sum] = "ac992f7fca3989de7ed1fe99c16363f848794c8c32a158dafd4eb927a2e02fd5"
 
-- 
2.43.0



^ permalink raw reply related	[flat|nested] 15+ messages in thread

* [OE-core][walnascar 02/14] sqlite3: patch CVE-2025-29088
  2025-05-28 15:33 [OE-core][walnascar 00/14] Patch review Steve Sakoman
  2025-05-28 15:33 ` [OE-core][walnascar 01/14] sqlite3: patch CVE-2025-3277 Steve Sakoman
@ 2025-05-28 15:33 ` Steve Sakoman
  2025-05-28 15:33 ` [OE-core][walnascar 03/14] sqlite3: mark CVE-2025-29087 as patched Steve Sakoman
                   ` (11 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: Steve Sakoman @ 2025-05-28 15:33 UTC (permalink / raw)
  To: openembedded-core

From: Peter Marko <peter.marko@siemens.com>

Pick commit [1] mentioned in [2].

[1] https://github.com/sqlite/sqlite/commit/56d2fd008b108109f489339f5fd55212bb50afd4
[2] https://nvd.nist.gov/vuln/detail/CVE-2025-29088

Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
 .../sqlite/sqlite3/CVE-2025-29088.patch       | 179 ++++++++++++++++++
 meta/recipes-support/sqlite/sqlite3_3.48.0.bb |   1 +
 2 files changed, 180 insertions(+)
 create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2025-29088.patch

diff --git a/meta/recipes-support/sqlite/sqlite3/CVE-2025-29088.patch b/meta/recipes-support/sqlite/sqlite3/CVE-2025-29088.patch
new file mode 100644
index 0000000000..12a025fdd8
--- /dev/null
+++ b/meta/recipes-support/sqlite/sqlite3/CVE-2025-29088.patch
@@ -0,0 +1,179 @@
+From 57d1e61dda969659f59a0b7841c7d0287d724bc6 Mon Sep 17 00:00:00 2001
+From: drh <>
+Date: Mon, 17 Feb 2025 14:16:49 +0000
+Subject: [PATCH] Harden the SQLITE_DBCONFIG_LOOKASIDE interface against
+ misuse, such as described in [forum:/forumpost/48f365daec|forum post
+ 48f365daec].  Enhancements to the SQLITE_DBCONFIG_LOOKASIDE documentation. 
+ Test cases in TH3.
+
+FossilOrigin-Name: 1ec4c308c76c69fba031184254fc3340f07607cfbf8342b13713ab445563d377
+
+CVE: CVE-2025-29088
+Upstream-Status: Backport [https://github.com/sqlite/sqlite/commit/56d2fd008b108109f489339f5fd55212bb50afd4]
+Signed-off-by: Peter Marko <peter.marko@siemens.com>
+---
+ sqlite3.c | 42 +++++++++++++++++++++++---------------
+ sqlite3.h | 60 +++++++++++++++++++++++++++++++++++++------------------
+ 2 files changed, 67 insertions(+), 35 deletions(-)
+
+diff --git a/sqlite3.c b/sqlite3.c
+index 24d0d954d9..2574a43f3e 100644
+--- a/sqlite3.c
++++ b/sqlite3.c
+@@ -182001,17 +182001,22 @@ SQLITE_API int sqlite3_config(int op, ...){
+ ** If lookaside is already active, return SQLITE_BUSY.
+ **
+ ** The sz parameter is the number of bytes in each lookaside slot.
+-** The cnt parameter is the number of slots.  If pStart is NULL the
+-** space for the lookaside memory is obtained from sqlite3_malloc().
+-** If pStart is not NULL then it is sz*cnt bytes of memory to use for
+-** the lookaside memory.
++** The cnt parameter is the number of slots.  If pBuf is NULL the
++** space for the lookaside memory is obtained from sqlite3_malloc()
++** or similar.  If pBuf is not NULL then it is sz*cnt bytes of memory
++** to use for the lookaside memory.
+ */
+-static int setupLookaside(sqlite3 *db, void *pBuf, int sz, int cnt){
++static int setupLookaside(
++  sqlite3 *db,    /* Database connection being configured */
++  void *pBuf,     /* Memory to use for lookaside.  May be NULL */
++  int sz,         /* Desired size of each lookaside memory slot */
++  int cnt         /* Number of slots to allocate */
++){
+ #ifndef SQLITE_OMIT_LOOKASIDE
+-  void *pStart;
+-  sqlite3_int64 szAlloc = sz*(sqlite3_int64)cnt;
+-  int nBig;   /* Number of full-size slots */
+-  int nSm;    /* Number smaller LOOKASIDE_SMALL-byte slots */
++  void *pStart;          /* Start of the lookaside buffer */
++  sqlite3_int64 szAlloc; /* Total space set aside for lookaside memory */
++  int nBig;              /* Number of full-size slots */
++  int nSm;               /* Number smaller LOOKASIDE_SMALL-byte slots */
+ 
+   if( sqlite3LookasideUsed(db,0)>0 ){
+     return SQLITE_BUSY;
+@@ -182024,17 +182029,22 @@ static int setupLookaside(sqlite3 *db, void *pBuf, int sz, int cnt){
+     sqlite3_free(db->lookaside.pStart);
+   }
+   /* The size of a lookaside slot after ROUNDDOWN8 needs to be larger
+-  ** than a pointer to be useful.
++  ** than a pointer and small enough to fit in a u16.
+   */
+-  sz = ROUNDDOWN8(sz);  /* IMP: R-33038-09382 */
++  sz = ROUNDDOWN8(sz);
+   if( sz<=(int)sizeof(LookasideSlot*) ) sz = 0;
+-  if( cnt<0 ) cnt = 0;
+-  if( sz==0 || cnt==0 ){
++  if( sz>65528 ) sz = 65528;
++  /* Count must be at least 1 to be useful, but not so large as to use
++  ** more than 0x7fff0000 total bytes for lookaside. */
++  if( cnt<1 ) cnt = 0;
++  if( sz>0 && cnt>(0x7fff0000/sz) ) cnt = 0x7fff0000/sz;
++  szAlloc = (i64)sz*(i64)cnt;
++  if( szAlloc==0 ){
+     sz = 0;
+     pStart = 0;
+   }else if( pBuf==0 ){
+     sqlite3BeginBenignMalloc();
+-    pStart = sqlite3Malloc( szAlloc );  /* IMP: R-61949-35727 */
++    pStart = sqlite3Malloc( szAlloc );
+     sqlite3EndBenignMalloc();
+     if( pStart ) szAlloc = sqlite3MallocSize(pStart);
+   }else{
+@@ -182043,10 +182053,10 @@ static int setupLookaside(sqlite3 *db, void *pBuf, int sz, int cnt){
+ #ifndef SQLITE_OMIT_TWOSIZE_LOOKASIDE
+   if( sz>=LOOKASIDE_SMALL*3 ){
+     nBig = szAlloc/(3*LOOKASIDE_SMALL+sz);
+-    nSm = (szAlloc - sz*nBig)/LOOKASIDE_SMALL;
++    nSm = (szAlloc - (i64)sz*(i64)nBig)/LOOKASIDE_SMALL;
+   }else if( sz>=LOOKASIDE_SMALL*2 ){
+     nBig = szAlloc/(LOOKASIDE_SMALL+sz);
+-    nSm = (szAlloc - sz*nBig)/LOOKASIDE_SMALL;
++    nSm = (szAlloc - (i64)sz*(i64)nBig)/LOOKASIDE_SMALL;
+   }else
+ #endif /* SQLITE_OMIT_TWOSIZE_LOOKASIDE */
+   if( sz>0 ){
+diff --git a/sqlite3.h b/sqlite3.h
+index 2618b37a7b..056511f577 100644
+--- a/sqlite3.h
++++ b/sqlite3.h
+@@ -1989,13 +1989,16 @@ struct sqlite3_mem_methods {
+ **
+ ** [[SQLITE_CONFIG_LOOKASIDE]] <dt>SQLITE_CONFIG_LOOKASIDE</dt>
+ ** <dd> ^(The SQLITE_CONFIG_LOOKASIDE option takes two arguments that determine
+-** the default size of lookaside memory on each [database connection].
++** the default size of [lookaside memory] on each [database connection].
+ ** The first argument is the
+-** size of each lookaside buffer slot and the second is the number of
+-** slots allocated to each database connection.)^  ^(SQLITE_CONFIG_LOOKASIDE
+-** sets the <i>default</i> lookaside size. The [SQLITE_DBCONFIG_LOOKASIDE]
+-** option to [sqlite3_db_config()] can be used to change the lookaside
+-** configuration on individual connections.)^ </dd>
++** size of each lookaside buffer slot ("sz") and the second is the number of
++** slots allocated to each database connection ("cnt").)^
++** ^(SQLITE_CONFIG_LOOKASIDE sets the <i>default</i> lookaside size.
++** The [SQLITE_DBCONFIG_LOOKASIDE] option to [sqlite3_db_config()] can
++** be used to change the lookaside configuration on individual connections.)^
++** The [-DSQLITE_DEFAULT_LOOKASIDE] option can be used to change the
++** default lookaside configuration at compile-time.
++** </dd>
+ **
+ ** [[SQLITE_CONFIG_PCACHE2]] <dt>SQLITE_CONFIG_PCACHE2</dt>
+ ** <dd> ^(The SQLITE_CONFIG_PCACHE2 option takes a single argument which is
+@@ -2225,24 +2228,43 @@ struct sqlite3_mem_methods {
+ ** <dt>SQLITE_DBCONFIG_LOOKASIDE</dt>
+ ** <dd> ^This option takes three additional arguments that determine the
+ ** [lookaside memory allocator] configuration for the [database connection].
+-** ^The first argument (the third parameter to [sqlite3_db_config()] is a
++** <ol>
++** <li><p>The first argument ("buf") is a
+ ** pointer to a memory buffer to use for lookaside memory.
+-** ^The first argument after the SQLITE_DBCONFIG_LOOKASIDE verb
+-** may be NULL in which case SQLite will allocate the
+-** lookaside buffer itself using [sqlite3_malloc()]. ^The second argument is the
+-** size of each lookaside buffer slot.  ^The third argument is the number of
+-** slots.  The size of the buffer in the first argument must be greater than
+-** or equal to the product of the second and third arguments.  The buffer
+-** must be aligned to an 8-byte boundary.  ^If the second argument to
+-** SQLITE_DBCONFIG_LOOKASIDE is not a multiple of 8, it is internally
+-** rounded down to the next smaller multiple of 8.  ^(The lookaside memory
++** The first argument may be NULL in which case SQLite will allocate the
++** lookaside buffer itself using [sqlite3_malloc()].
++** <li><P>The second argument ("sz") is the
++** size of each lookaside buffer slot.  Lookaside is disabled if "sz"
++** is less than 8.  The "sz" argument should be a multiple of 8 less than
++** 65536.  If "sz" does not meet this constraint, it is reduced in size until
++** it does.
++** <li><p>The third argument ("cnt") is the number of slots. Lookaside is disabled
++** if "cnt"is less than 1.  The "cnt" value will be reduced, if necessary, so
++** that the product of "sz" and "cnt" does not exceed 2,147,418,112.  The "cnt"
++** parameter is usually chosen so that the product of "sz" and "cnt" is less
++** than 1,000,000.
++** </ol>
++** <p>If the "buf" argument is not NULL, then it must
++** point to a memory buffer with a size that is greater than
++** or equal to the product of "sz" and "cnt".
++** The buffer must be aligned to an 8-byte boundary.
++** The lookaside memory
+ ** configuration for a database connection can only be changed when that
+ ** connection is not currently using lookaside memory, or in other words
+-** when the "current value" returned by
+-** [sqlite3_db_status](D,[SQLITE_DBSTATUS_LOOKASIDE_USED],...) is zero.
++** when the value returned by [SQLITE_DBSTATUS_LOOKASIDE_USED] is zero.
+ ** Any attempt to change the lookaside memory configuration when lookaside
+ ** memory is in use leaves the configuration unchanged and returns
+-** [SQLITE_BUSY].)^</dd>
++** [SQLITE_BUSY].
++** If the "buf" argument is NULL and an attempt
++** to allocate memory based on "sz" and "cnt" fails, then
++** lookaside is silently disabled.
++** <p>
++** The [SQLITE_CONFIG_LOOKASIDE] configuration option can be used to set the
++** default lookaside configuration at initialization.  The
++** [-DSQLITE_DEFAULT_LOOKASIDE] option can be used to set the default lookaside
++** configuration at compile-time.  Typical values for lookaside are 1200 for
++** "sz" and 40 to 100 for "cnt".
++** </dd>
+ **
+ ** [[SQLITE_DBCONFIG_ENABLE_FKEY]]
+ ** <dt>SQLITE_DBCONFIG_ENABLE_FKEY</dt>
diff --git a/meta/recipes-support/sqlite/sqlite3_3.48.0.bb b/meta/recipes-support/sqlite/sqlite3_3.48.0.bb
index 86983f21bd..11f103dddc 100644
--- a/meta/recipes-support/sqlite/sqlite3_3.48.0.bb
+++ b/meta/recipes-support/sqlite/sqlite3_3.48.0.bb
@@ -5,6 +5,7 @@ LIC_FILES_CHKSUM = "file://sqlite3.h;endline=11;md5=786d3dc581eff03f4fd9e4a77ed0
 
 SRC_URI = "http://www.sqlite.org/2025/sqlite-autoconf-${SQLITE_PV}.tar.gz \
     file://CVE-2025-3277.patch \
+    file://CVE-2025-29088.patch \
 "
 SRC_URI[sha256sum] = "ac992f7fca3989de7ed1fe99c16363f848794c8c32a158dafd4eb927a2e02fd5"
 
-- 
2.43.0



^ permalink raw reply related	[flat|nested] 15+ messages in thread

* [OE-core][walnascar 03/14] sqlite3: mark CVE-2025-29087 as patched
  2025-05-28 15:33 [OE-core][walnascar 00/14] Patch review Steve Sakoman
  2025-05-28 15:33 ` [OE-core][walnascar 01/14] sqlite3: patch CVE-2025-3277 Steve Sakoman
  2025-05-28 15:33 ` [OE-core][walnascar 02/14] sqlite3: patch CVE-2025-29088 Steve Sakoman
@ 2025-05-28 15:33 ` Steve Sakoman
  2025-05-28 15:33 ` [OE-core][walnascar 04/14] ofono: patch CVE-2024-7537 Steve Sakoman
                   ` (10 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: Steve Sakoman @ 2025-05-28 15:33 UTC (permalink / raw)
  To: openembedded-core

From: Peter Marko <peter.marko@siemens.com>

Description of CVE-2025-29087 and CVE-2025-3277 are very similar.
There is no lonk from NVD, but [1] and [2] from Debian mark these two
CVEs as duplicates with the same link for patch.

[1] https://security-tracker.debian.org/tracker/CVE-2025-29087
[2] https://security-tracker.debian.org/tracker/CVE-2025-3277

Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
 meta/recipes-support/sqlite/sqlite3/CVE-2025-3277.patch | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-support/sqlite/sqlite3/CVE-2025-3277.patch b/meta/recipes-support/sqlite/sqlite3/CVE-2025-3277.patch
index 8264d4443a..60da0b773d 100644
--- a/meta/recipes-support/sqlite/sqlite3/CVE-2025-3277.patch
+++ b/meta/recipes-support/sqlite/sqlite3/CVE-2025-3277.patch
@@ -7,6 +7,7 @@ Subject: [PATCH] Add a typecast to avoid 32-bit integer overflow in the
 FossilOrigin-Name: 498e3f1cf57f164fbd8380e92bf91b9f26d6aa05d092fcd135d754abf1e5b1b5
 
 CVE: CVE-2025-3277
+CVE: CVE-2025-29087
 Upstream-Status: Backport [https://sqlite.org/src/info/498e3f1cf57f164f]
 Signed-off-by: Peter Marko <peter.marko@siemens.com>
 ---
-- 
2.43.0



^ permalink raw reply related	[flat|nested] 15+ messages in thread

* [OE-core][walnascar 04/14] ofono: patch CVE-2024-7537
  2025-05-28 15:33 [OE-core][walnascar 00/14] Patch review Steve Sakoman
                   ` (2 preceding siblings ...)
  2025-05-28 15:33 ` [OE-core][walnascar 03/14] sqlite3: mark CVE-2025-29087 as patched Steve Sakoman
@ 2025-05-28 15:33 ` Steve Sakoman
  2025-05-28 15:33 ` [OE-core][walnascar 05/14] xz: patch CVE-2025-31115 Steve Sakoman
                   ` (9 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: Steve Sakoman @ 2025-05-28 15:33 UTC (permalink / raw)
  To: openembedded-core

From: Peter Marko <peter.marko@siemens.com>

Pick commit
https://web.git.kernel.org/pub/scm/network/ofono/ofono.git/commit/?id=e6d8d526d5077c0b6ab459efeb6b882c28e0fdeb

Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
 .../ofono/ofono/CVE-2024-7537.patch           | 59 +++++++++++++++++++
 meta/recipes-connectivity/ofono/ofono_2.15.bb |  1 +
 2 files changed, 60 insertions(+)
 create mode 100644 meta/recipes-connectivity/ofono/ofono/CVE-2024-7537.patch

diff --git a/meta/recipes-connectivity/ofono/ofono/CVE-2024-7537.patch b/meta/recipes-connectivity/ofono/ofono/CVE-2024-7537.patch
new file mode 100644
index 0000000000..4a7cd12297
--- /dev/null
+++ b/meta/recipes-connectivity/ofono/ofono/CVE-2024-7537.patch
@@ -0,0 +1,59 @@
+From e6d8d526d5077c0b6ab459efeb6b882c28e0fdeb Mon Sep 17 00:00:00 2001
+From: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
+Date: Sun, 16 Mar 2025 12:26:42 +0200
+Subject: [PATCH] qmi: sms: Fix possible out-of-bounds read
+
+Fixes: CVE-2024-7537
+
+CVE: CVE-2024-7537
+Upstream-Status: Backport [https://web.git.kernel.org/pub/scm/network/ofono/ofono.git/commit/?id=e6d8d526d5077c0b6ab459efeb6b882c28e0fdeb]
+Signed-off-by: Peter Marko <peter.marko@siemens.com>
+---
+ drivers/qmimodem/sms.c | 13 ++++++++++---
+ 1 file changed, 10 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/qmimodem/sms.c b/drivers/qmimodem/sms.c
+index 3e2bef6e..75863480 100644
+--- a/drivers/qmimodem/sms.c
++++ b/drivers/qmimodem/sms.c
+@@ -442,6 +442,8 @@ static void get_msg_list_cb(struct qmi_result *result, void *user_data)
+ 	const struct qmi_wms_result_msg_list *list;
+ 	uint32_t cnt = 0;
+ 	uint16_t tmp;
++	uint16_t length;
++	size_t msg_size;
+ 
+ 	DBG("");
+ 
+@@ -451,7 +453,7 @@ static void get_msg_list_cb(struct qmi_result *result, void *user_data)
+ 		goto done;
+ 	}
+ 
+-	list = qmi_result_get(result, QMI_WMS_RESULT_MSG_LIST, NULL);
++	list = qmi_result_get(result, QMI_WMS_RESULT_MSG_LIST, &length);
+ 	if (list == NULL) {
+ 		DBG("Err: get msg list empty");
+ 		goto done;
+@@ -460,6 +462,13 @@ static void get_msg_list_cb(struct qmi_result *result, void *user_data)
+ 	cnt = L_LE32_TO_CPU(list->cnt);
+ 	DBG("msgs found %d", cnt);
+ 
++	msg_size = cnt * sizeof(list->msg[0]);
++
++	if (length != sizeof(list->cnt) + msg_size) {
++		DBG("Err: invalid msg list count");
++		goto done;
++	}
++
+ 	for (tmp = 0; tmp < cnt; tmp++) {
+ 		DBG("unread type %d ndx %d", list->msg[tmp].type,
+ 			L_LE32_TO_CPU(list->msg[tmp].ndx));
+@@ -473,8 +482,6 @@ static void get_msg_list_cb(struct qmi_result *result, void *user_data)
+ 
+ 	/* save list and get 1st msg */
+ 	if (cnt) {
+-		int msg_size = cnt * sizeof(list->msg[0]);
+-
+ 		data->msg_list = l_malloc(sizeof(list->cnt) + msg_size);
+ 		data->msg_list->cnt = cnt;
+ 		memcpy(data->msg_list->msg, list->msg, msg_size);
diff --git a/meta/recipes-connectivity/ofono/ofono_2.15.bb b/meta/recipes-connectivity/ofono/ofono_2.15.bb
index 40eeb3a086..07d7ac6095 100644
--- a/meta/recipes-connectivity/ofono/ofono_2.15.bb
+++ b/meta/recipes-connectivity/ofono/ofono_2.15.bb
@@ -9,6 +9,7 @@ DEPENDS = "dbus glib-2.0 udev mobile-broadband-provider-info ell"
 
 SRC_URI = "${KERNELORG_MIRROR}/linux/network/${BPN}/${BP}.tar.xz \
            file://ofono \
+           file://CVE-2024-7537.patch \
            "
 SRC_URI[sha256sum] = "1af93ab72a70502452fe3d0297a6eaea13750cacae1fff3b643dd2245a6408ca"
 
-- 
2.43.0



^ permalink raw reply related	[flat|nested] 15+ messages in thread

* [OE-core][walnascar 05/14] xz: patch CVE-2025-31115
  2025-05-28 15:33 [OE-core][walnascar 00/14] Patch review Steve Sakoman
                   ` (3 preceding siblings ...)
  2025-05-28 15:33 ` [OE-core][walnascar 04/14] ofono: patch CVE-2024-7537 Steve Sakoman
@ 2025-05-28 15:33 ` Steve Sakoman
  2025-05-28 15:33 ` [OE-core][walnascar 06/14] binutils: drop obsolete CVE_STATUS Steve Sakoman
                   ` (8 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: Steve Sakoman @ 2025-05-28 15:33 UTC (permalink / raw)
  To: openembedded-core

From: Peter Marko <peter.marko@siemens.com>

Cherry-pick commits from [1] linked from [2] from branch v5.6

[1] https://tukaani.org/xz/xz-cve-2025-31115.patch
[2] https://tukaani.org/xz/threaded-decoder-early-free.html

Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
 .../xz/xz/CVE-2025-31115-01.patch             |  29 ++++
 .../xz/xz/CVE-2025-31115-02.patch             | 152 ++++++++++++++++++
 .../xz/xz/CVE-2025-31115-03.patch             |  98 +++++++++++
 .../xz/xz/CVE-2025-31115-04.patch             |  56 +++++++
 meta/recipes-extended/xz/xz_5.6.4.bb          |   4 +
 5 files changed, 339 insertions(+)
 create mode 100644 meta/recipes-extended/xz/xz/CVE-2025-31115-01.patch
 create mode 100644 meta/recipes-extended/xz/xz/CVE-2025-31115-02.patch
 create mode 100644 meta/recipes-extended/xz/xz/CVE-2025-31115-03.patch
 create mode 100644 meta/recipes-extended/xz/xz/CVE-2025-31115-04.patch

diff --git a/meta/recipes-extended/xz/xz/CVE-2025-31115-01.patch b/meta/recipes-extended/xz/xz/CVE-2025-31115-01.patch
new file mode 100644
index 0000000000..d6e75f8201
--- /dev/null
+++ b/meta/recipes-extended/xz/xz/CVE-2025-31115-01.patch
@@ -0,0 +1,29 @@
+From c1a91b8baeb947c5b232a6c3d6319267131830bc Mon Sep 17 00:00:00 2001
+From: Lasse Collin <lasse.collin@tukaani.org>
+Date: Thu, 3 Apr 2025 14:34:42 +0300
+Subject: [PATCH 1/4] liblzma: mt dec: Fix a comment
+
+Reviewed-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
+Thanks-to: Sam James <sam@gentoo.org>
+(cherry picked from commit 831b55b971cf579ee16a854f177c36b20d3c6999)
+
+CVE: CVE-2025-31115
+Upstream-Status: Backport [https://github.com/tukaani-project/xz/commit/c1a91b8baeb947c5b232a6c3d6319267131830bc]
+Signed-off-by: Peter Marko <peter.marko@siemens.com>
+---
+ src/liblzma/common/stream_decoder_mt.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/liblzma/common/stream_decoder_mt.c b/src/liblzma/common/stream_decoder_mt.c
+index 244624a4..6f06f1d1 100644
+--- a/src/liblzma/common/stream_decoder_mt.c
++++ b/src/liblzma/common/stream_decoder_mt.c
+@@ -347,7 +347,7 @@ worker_enable_partial_update(void *thr_ptr)
+ 
+ 
+ /// Things do to at THR_STOP or when finishing a Block.
+-/// This is called with thr->mutex locked.
++/// This is called with thr->coder->mutex locked.
+ static void
+ worker_stop(struct worker_thread *thr)
+ {
diff --git a/meta/recipes-extended/xz/xz/CVE-2025-31115-02.patch b/meta/recipes-extended/xz/xz/CVE-2025-31115-02.patch
new file mode 100644
index 0000000000..7b36ae551a
--- /dev/null
+++ b/meta/recipes-extended/xz/xz/CVE-2025-31115-02.patch
@@ -0,0 +1,152 @@
+From f74cf18ad084a9185d8ae148d89265860aa8004c Mon Sep 17 00:00:00 2001
+From: Lasse Collin <lasse.collin@tukaani.org>
+Date: Thu, 3 Apr 2025 14:34:42 +0300
+Subject: [PATCH 2/4] liblzma: mt dec: Simplify by removing the THR_STOP state
+
+The main thread can directly set THR_IDLE in threads_stop() which is
+called when errors are detected. threads_stop() won't return the stopped
+threads to the pool or free the memory pointed by thr->in anymore, but
+it doesn't matter because the existing workers won't be reused after
+an error. The resources will be cleaned up when threads_end() is
+called (reinitializing the decoder always calls threads_end()).
+
+Reviewed-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
+Thanks-to: Sam James <sam@gentoo.org>
+(cherry picked from commit c0c835964dfaeb2513a3c0bdb642105152fe9f34)
+
+CVE: CVE-2025-31115
+Upstream-Status: Backport [https://github.com/tukaani-project/xz/commit/f74cf18ad084a9185d8ae148d89265860aa8004c]
+Signed-off-by: Peter Marko <peter.marko@siemens.com>
+---
+ src/liblzma/common/stream_decoder_mt.c | 75 ++++++++++----------------
+ 1 file changed, 29 insertions(+), 46 deletions(-)
+
+diff --git a/src/liblzma/common/stream_decoder_mt.c b/src/liblzma/common/stream_decoder_mt.c
+index 6f06f1d1..e1d07007 100644
+--- a/src/liblzma/common/stream_decoder_mt.c
++++ b/src/liblzma/common/stream_decoder_mt.c
+@@ -23,15 +23,10 @@ typedef enum {
+ 	THR_IDLE,
+ 
+ 	/// Decoding is in progress.
+-	/// Main thread may change this to THR_STOP or THR_EXIT.
++	/// Main thread may change this to THR_IDLE or THR_EXIT.
+ 	/// The worker thread may change this to THR_IDLE.
+ 	THR_RUN,
+ 
+-	/// The main thread wants the thread to stop whatever it was doing
+-	/// but not exit. Main thread may change this to THR_EXIT.
+-	/// The worker thread may change this to THR_IDLE.
+-	THR_STOP,
+-
+ 	/// The main thread wants the thread to exit.
+ 	THR_EXIT,
+ 
+@@ -346,27 +341,6 @@ worker_enable_partial_update(void *thr_ptr)
+ }
+ 
+ 
+-/// Things do to at THR_STOP or when finishing a Block.
+-/// This is called with thr->coder->mutex locked.
+-static void
+-worker_stop(struct worker_thread *thr)
+-{
+-	// Update memory usage counters.
+-	thr->coder->mem_in_use -= thr->in_size;
+-	thr->in_size = 0; // thr->in was freed above.
+-
+-	thr->coder->mem_in_use -= thr->mem_filters;
+-	thr->coder->mem_cached += thr->mem_filters;
+-
+-	// Put this thread to the stack of free threads.
+-	thr->next = thr->coder->threads_free;
+-	thr->coder->threads_free = thr;
+-
+-	mythread_cond_signal(&thr->coder->cond);
+-	return;
+-}
+-
+-
+ static MYTHREAD_RET_TYPE
+ worker_decoder(void *thr_ptr)
+ {
+@@ -397,17 +371,6 @@ next_loop_unlocked:
+ 		return MYTHREAD_RET_VALUE;
+ 	}
+ 
+-	if (thr->state == THR_STOP) {
+-		thr->state = THR_IDLE;
+-		mythread_mutex_unlock(&thr->mutex);
+-
+-		mythread_sync(thr->coder->mutex) {
+-			worker_stop(thr);
+-		}
+-
+-		goto next_loop_lock;
+-	}
+-
+ 	assert(thr->state == THR_RUN);
+ 
+ 	// Update progress info for get_progress().
+@@ -510,7 +473,22 @@ next_loop_unlocked:
+ 				&& thr->coder->thread_error == LZMA_OK)
+ 			thr->coder->thread_error = ret;
+ 
+-		worker_stop(thr);
++		// Return the worker thread to the stack of available
++		// threads.
++		{
++			// Update memory usage counters.
++			thr->coder->mem_in_use -= thr->in_size;
++			thr->in_size = 0; // thr->in was freed above.
++
++			thr->coder->mem_in_use -= thr->mem_filters;
++			thr->coder->mem_cached += thr->mem_filters;
++
++			// Put this thread to the stack of free threads.
++			thr->next = thr->coder->threads_free;
++			thr->coder->threads_free = thr;
++		}
++
++		mythread_cond_signal(&thr->coder->cond);
+ 	}
+ 
+ 	goto next_loop_lock;
+@@ -544,17 +522,22 @@ threads_end(struct lzma_stream_coder *coder, const lzma_allocator *allocator)
+ }
+ 
+ 
++/// Tell worker threads to stop without doing any cleaning up.
++/// The clean up will be done when threads_exit() is called;
++/// it's not possible to reuse the threads after threads_stop().
++///
++/// This is called before returning an unrecoverable error code
++/// to the application. It would be waste of processor time
++/// to keep the threads running in such a situation.
+ static void
+ threads_stop(struct lzma_stream_coder *coder)
+ {
+ 	for (uint32_t i = 0; i < coder->threads_initialized; ++i) {
++		// The threads that are in the THR_RUN state will stop
++		// when they check the state the next time. There's no
++		// need to signal coder->threads[i].cond.
+ 		mythread_sync(coder->threads[i].mutex) {
+-			// The state must be changed conditionally because
+-			// THR_IDLE -> THR_STOP is not a valid state change.
+-			if (coder->threads[i].state != THR_IDLE) {
+-				coder->threads[i].state = THR_STOP;
+-				mythread_cond_signal(&coder->threads[i].cond);
+-			}
++			coder->threads[i].state = THR_IDLE;
+ 		}
+ 	}
+ 
+@@ -1948,7 +1931,7 @@ stream_decoder_mt_init(lzma_next_coder *next, const lzma_allocator *allocator,
+ 	// accounting from scratch, too. Changes in filter and block sizes may
+ 	// affect number of threads.
+ 	//
+-	// FIXME? Reusing should be easy but unlike the single-threaded
++	// Reusing threads doesn't seem worth it. Unlike the single-threaded
+ 	// decoder, with some types of input file combinations reusing
+ 	// could leave quite a lot of memory allocated but unused (first
+ 	// file could allocate a lot, the next files could use fewer
diff --git a/meta/recipes-extended/xz/xz/CVE-2025-31115-03.patch b/meta/recipes-extended/xz/xz/CVE-2025-31115-03.patch
new file mode 100644
index 0000000000..892249d0b4
--- /dev/null
+++ b/meta/recipes-extended/xz/xz/CVE-2025-31115-03.patch
@@ -0,0 +1,98 @@
+From 1b874b4f04909b7bb5259cb612ecef39a434dde8 Mon Sep 17 00:00:00 2001
+From: Lasse Collin <lasse.collin@tukaani.org>
+Date: Thu, 3 Apr 2025 14:34:42 +0300
+Subject: [PATCH 3/4] liblzma: mt dec: Don't free the input buffer too early
+ (CVE-2025-31115)
+
+The input buffer must be valid as long as the main thread is writing
+to the worker-specific input buffer. Fix it by making the worker
+thread not free the buffer on errors and not return the worker thread to
+the pool. The input buffer will be freed when threads_end() is called.
+
+With invalid input, the bug could at least result in a crash. The
+effects include heap use after free and writing to an address based
+on the null pointer plus an offset.
+
+The bug has been there since the first committed version of the threaded
+decoder and thus affects versions from 5.3.3alpha to 5.8.0.
+
+As the commit message in 4cce3e27f529 says, I had made significant
+changes on top of Sebastian's patch. This bug was indeed introduced
+by my changes; it wasn't in Sebastian's version.
+
+Thanks to Harri K. Koskinen for discovering and reporting this issue.
+
+Fixes: 4cce3e27f529 ("liblzma: Add threaded .xz decompressor.")
+Reported-by: Harri K. Koskinen <x64nop@nannu.org>
+Reviewed-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
+Thanks-to: Sam James <sam@gentoo.org>
+(cherry picked from commit d5a2ffe41bb77b918a8c96084885d4dbe4bf6480)
+
+CVE: CVE-2025-31115
+Upstream-Status: Backport [https://github.com/tukaani-project/xz/commit/1b874b4f04909b7bb5259cb612ecef39a434dde8]
+Signed-off-by: Peter Marko <peter.marko@siemens.com>
+---
+ src/liblzma/common/stream_decoder_mt.c | 31 ++++++++++++++++++--------
+ 1 file changed, 22 insertions(+), 9 deletions(-)
+
+diff --git a/src/liblzma/common/stream_decoder_mt.c b/src/liblzma/common/stream_decoder_mt.c
+index e1d07007..ce5e54ac 100644
+--- a/src/liblzma/common/stream_decoder_mt.c
++++ b/src/liblzma/common/stream_decoder_mt.c
+@@ -435,8 +435,7 @@ next_loop_unlocked:
+ 	}
+ 
+ 	// Either we finished successfully (LZMA_STREAM_END) or an error
+-	// occurred. Both cases are handled almost identically. The error
+-	// case requires updating thr->coder->thread_error.
++	// occurred.
+ 	//
+ 	// The sizes are in the Block Header and the Block decoder
+ 	// checks that they match, thus we know these:
+@@ -444,16 +443,30 @@ next_loop_unlocked:
+ 	assert(ret != LZMA_STREAM_END
+ 		|| thr->out_pos == thr->block_options.uncompressed_size);
+ 
+-	// Free the input buffer. Don't update in_size as we need
+-	// it later to update thr->coder->mem_in_use.
+-	lzma_free(thr->in, thr->allocator);
+-	thr->in = NULL;
+-
+ 	mythread_sync(thr->mutex) {
++		// Block decoder ensures this, but do a sanity check anyway
++		// because thr->in_filled < thr->in_size means that the main
++		// thread is still writing to thr->in.
++		if (ret == LZMA_STREAM_END && thr->in_filled != thr->in_size) {
++			assert(0);
++			ret = LZMA_PROG_ERROR;
++		}
++
+ 		if (thr->state != THR_EXIT)
+ 			thr->state = THR_IDLE;
+ 	}
+ 
++	// Free the input buffer. Don't update in_size as we need
++	// it later to update thr->coder->mem_in_use.
++	//
++	// This step is skipped if an error occurred because the main thread
++	// might still be writing to thr->in. The memory will be freed after
++	// threads_end() sets thr->state = THR_EXIT.
++	if (ret == LZMA_STREAM_END) {
++		lzma_free(thr->in, thr->allocator);
++		thr->in = NULL;
++	}
++
+ 	mythread_sync(thr->coder->mutex) {
+ 		// Move our progress info to the main thread.
+ 		thr->coder->progress_in += thr->in_pos;
+@@ -474,8 +487,8 @@ next_loop_unlocked:
+ 			thr->coder->thread_error = ret;
+ 
+ 		// Return the worker thread to the stack of available
+-		// threads.
+-		{
++		// threads only if no errors occurred.
++		if (ret == LZMA_STREAM_END) {
+ 			// Update memory usage counters.
+ 			thr->coder->mem_in_use -= thr->in_size;
+ 			thr->in_size = 0; // thr->in was freed above.
diff --git a/meta/recipes-extended/xz/xz/CVE-2025-31115-04.patch b/meta/recipes-extended/xz/xz/CVE-2025-31115-04.patch
new file mode 100644
index 0000000000..f80daceb4a
--- /dev/null
+++ b/meta/recipes-extended/xz/xz/CVE-2025-31115-04.patch
@@ -0,0 +1,56 @@
+From 6ff5b8c55960f9ebc917b668bd3567ef217175fa Mon Sep 17 00:00:00 2001
+From: Lasse Collin <lasse.collin@tukaani.org>
+Date: Thu, 3 Apr 2025 14:34:42 +0300
+Subject: [PATCH 4/4] liblzma: mt dec: Don't modify thr->in_size in the worker
+ thread
+
+Don't set thr->in_size = 0 when returning the thread to the stack of
+available threads. Not only is it useless, but the main thread may
+read the value in SEQ_BLOCK_THR_RUN. With valid inputs, it made
+no difference if the main thread saw the original value or 0. With
+invalid inputs (when worker thread stops early), thr->in_size was
+no longer modified after the previous commit with the security fix
+("Don't free the input buffer too early").
+
+So while the bug appears harmless now, it's important to fix it because
+the variable was being modified without proper locking. It's trivial
+to fix because there is no need to change the value. Only main thread
+needs to set the value in (in SEQ_BLOCK_THR_INIT) when starting a new
+Block before the worker thread is activated.
+
+Fixes: 4cce3e27f529 ("liblzma: Add threaded .xz decompressor.")
+Reviewed-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
+Thanks-to: Sam James <sam@gentoo.org>
+(cherry picked from commit 8188048854e8d11071b8a50d093c74f4c030acc9)
+
+CVE: CVE-2025-31115
+Upstream-Status: Backport [https://github.com/tukaani-project/xz/commit/6ff5b8c55960f9ebc917b668bd3567ef217175fa]
+Signed-off-by: Peter Marko <peter.marko@siemens.com>
+---
+ src/liblzma/common/stream_decoder_mt.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/src/liblzma/common/stream_decoder_mt.c b/src/liblzma/common/stream_decoder_mt.c
+index ce5e54ac..0cdb47d3 100644
+--- a/src/liblzma/common/stream_decoder_mt.c
++++ b/src/liblzma/common/stream_decoder_mt.c
+@@ -491,8 +491,6 @@ next_loop_unlocked:
+ 		if (ret == LZMA_STREAM_END) {
+ 			// Update memory usage counters.
+ 			thr->coder->mem_in_use -= thr->in_size;
+-			thr->in_size = 0; // thr->in was freed above.
+-
+ 			thr->coder->mem_in_use -= thr->mem_filters;
+ 			thr->coder->mem_cached += thr->mem_filters;
+ 
+@@ -1557,6 +1555,10 @@ stream_decode_mt(void *coder_ptr, const lzma_allocator *allocator,
+ 		}
+ 
+ 		// Return if the input didn't contain the whole Block.
++		//
++		// NOTE: When we updated coder->thr->in_filled a few lines
++		// above, the worker thread might by now have finished its
++		// work and returned itself back to the stack of free threads.
+ 		if (coder->thr->in_filled < coder->thr->in_size) {
+ 			assert(*in_pos == in_size);
+ 			return LZMA_OK;
diff --git a/meta/recipes-extended/xz/xz_5.6.4.bb b/meta/recipes-extended/xz/xz_5.6.4.bb
index e48f4dbd7f..52bfd844b2 100644
--- a/meta/recipes-extended/xz/xz_5.6.4.bb
+++ b/meta/recipes-extended/xz/xz_5.6.4.bb
@@ -27,6 +27,10 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=c02de712b028a5cc7e22472e8f2b3db1 \
 
 SRC_URI = "https://github.com/tukaani-project/xz/releases/download/v${PV}/xz-${PV}.tar.gz \
            file://run-ptest \
+           file://CVE-2025-31115-01.patch \
+           file://CVE-2025-31115-02.patch \
+           file://CVE-2025-31115-03.patch \
+           file://CVE-2025-31115-04.patch \
           "
 SRC_URI[sha256sum] = "269e3f2e512cbd3314849982014dc199a7b2148cf5c91cedc6db629acdf5e09b"
 UPSTREAM_CHECK_REGEX = "releases/tag/v(?P<pver>\d+(\.\d+)+)"
-- 
2.43.0



^ permalink raw reply related	[flat|nested] 15+ messages in thread

* [OE-core][walnascar 06/14] binutils: drop obsolete CVE_STATUS
  2025-05-28 15:33 [OE-core][walnascar 00/14] Patch review Steve Sakoman
                   ` (4 preceding siblings ...)
  2025-05-28 15:33 ` [OE-core][walnascar 05/14] xz: patch CVE-2025-31115 Steve Sakoman
@ 2025-05-28 15:33 ` Steve Sakoman
  2025-05-28 15:33 ` [OE-core][walnascar 07/14] binutils: mark CVE-2025-1153 as fixed Steve Sakoman
                   ` (7 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: Steve Sakoman @ 2025-05-28 15:33 UTC (permalink / raw)
  To: openembedded-core

From: Peter Marko <peter.marko@siemens.com>

NVD has CVE-2023-25584 listed as < 2.40, so we don't need to ignore it
for version 2.44 anymore.

(From OE-Core rev: eaf80096f96e5bebed53076c1dfe7e35e539f383)

Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
 meta/recipes-devtools/binutils/binutils-2.44.inc | 2 --
 1 file changed, 2 deletions(-)

diff --git a/meta/recipes-devtools/binutils/binutils-2.44.inc b/meta/recipes-devtools/binutils/binutils-2.44.inc
index 7a19aa31d5..41071fada1 100644
--- a/meta/recipes-devtools/binutils/binutils-2.44.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.44.inc
@@ -18,8 +18,6 @@ SRCBRANCH ?= "binutils-2_44-branch"
 
 UPSTREAM_CHECK_GITTAGREGEX = "binutils-(?P<pver>\d+_(\d_?)*)"
 
-CVE_STATUS[CVE-2023-25584] = "cpe-incorrect: Applies only for version 2.40 and earlier"
-
 SRCREV ?= "819d713b6340ed3657e00ad0bc8d5f2b73094a0f"
 BINUTILS_GIT_URI ?= "git://sourceware.org/git/binutils-gdb.git;branch=${SRCBRANCH};protocol=https"
 SRC_URI = "\
-- 
2.43.0



^ permalink raw reply related	[flat|nested] 15+ messages in thread

* [OE-core][walnascar 07/14] binutils: mark CVE-2025-1153 as fixed
  2025-05-28 15:33 [OE-core][walnascar 00/14] Patch review Steve Sakoman
                   ` (5 preceding siblings ...)
  2025-05-28 15:33 ` [OE-core][walnascar 06/14] binutils: drop obsolete CVE_STATUS Steve Sakoman
@ 2025-05-28 15:33 ` Steve Sakoman
  2025-05-28 15:33 ` [OE-core][walnascar 08/14] binutils: Fix CVE-2025-1178 Steve Sakoman
                   ` (6 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: Steve Sakoman @ 2025-05-28 15:33 UTC (permalink / raw)
  To: openembedded-core

From: Peter Marko <peter.marko@siemens.com>

We had this CVE patched but the patch was removed with last 2.44 branch
updates as it is now included.
Since there is no new version which could be set in NVD DB, this needs
to be explicitly handled.

(From OE-Core rev: 32f18145dee54f61203506daef339cd132908287)

Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
 meta/recipes-devtools/binutils/binutils-2.44.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/binutils/binutils-2.44.inc b/meta/recipes-devtools/binutils/binutils-2.44.inc
index 41071fada1..28100abbe9 100644
--- a/meta/recipes-devtools/binutils/binutils-2.44.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.44.inc
@@ -18,6 +18,8 @@ SRCBRANCH ?= "binutils-2_44-branch"
 
 UPSTREAM_CHECK_GITTAGREGEX = "binutils-(?P<pver>\d+_(\d_?)*)"
 
+CVE_STATUS[CVE-2025-1153] = "cpe-stable-backport: fix available in used git hash"
+
 SRCREV ?= "819d713b6340ed3657e00ad0bc8d5f2b73094a0f"
 BINUTILS_GIT_URI ?= "git://sourceware.org/git/binutils-gdb.git;branch=${SRCBRANCH};protocol=https"
 SRC_URI = "\
-- 
2.43.0



^ permalink raw reply related	[flat|nested] 15+ messages in thread

* [OE-core][walnascar 08/14] binutils: Fix CVE-2025-1178
  2025-05-28 15:33 [OE-core][walnascar 00/14] Patch review Steve Sakoman
                   ` (6 preceding siblings ...)
  2025-05-28 15:33 ` [OE-core][walnascar 07/14] binutils: mark CVE-2025-1153 as fixed Steve Sakoman
@ 2025-05-28 15:33 ` Steve Sakoman
  2025-05-28 15:33 ` [OE-core][walnascar 09/14] binutils: Fix CVE-2025-1180 Steve Sakoman
                   ` (5 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: Steve Sakoman @ 2025-05-28 15:33 UTC (permalink / raw)
  To: openembedded-core

From: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>

Prevent an abort in the bfd linker when attempting to
generate dynamic relocs for a corrupt input file.

PR 32638

Backport a patch from upstream to fix CVE-2025-1178
Upstream-Status: Backport from [https://sourceware.org/git/?p=binutils-gdb.git;a=patch;h=75086e9de1707281172cc77f178e7949a4414ed0]

Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
 .../binutils/binutils-2.44.inc                |  1 +
 .../binutils/0015-CVE-2025-1178.patch         | 33 +++++++++++++++++++
 2 files changed, 34 insertions(+)
 create mode 100644 meta/recipes-devtools/binutils/binutils/0015-CVE-2025-1178.patch

diff --git a/meta/recipes-devtools/binutils/binutils-2.44.inc b/meta/recipes-devtools/binutils/binutils-2.44.inc
index 28100abbe9..681b42fc3c 100644
--- a/meta/recipes-devtools/binutils/binutils-2.44.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.44.inc
@@ -35,5 +35,6 @@ SRC_URI = "\
      file://0012-Only-generate-an-RPATH-entry-if-LD_RUN_PATH-is-not-e.patch \
      file://0013-Define-alignof-using-_Alignof-when-using-C11-or-newe.patch \
      file://0014-Remove-duplicate-pe-dll.o-entry-deom-targ_extra_ofil.patch \
+     file://0015-CVE-2025-1178.patch \
 "
 S  = "${WORKDIR}/git"
diff --git a/meta/recipes-devtools/binutils/binutils/0015-CVE-2025-1178.patch b/meta/recipes-devtools/binutils/binutils/0015-CVE-2025-1178.patch
new file mode 100644
index 0000000000..c39f43fba4
--- /dev/null
+++ b/meta/recipes-devtools/binutils/binutils/0015-CVE-2025-1178.patch
@@ -0,0 +1,33 @@
+From 75086e9de1707281172cc77f178e7949a4414ed0 Mon Sep 17 00:00:00 2001
+From: Nick Clifton <nickc@redhat.com>
+Date: Wed, 5 Feb 2025 13:26:51 +0000
+Subject: [PATCH] Prevent an abort in the bfd linker when attempting to
+ generate dynamic relocs for a corrupt input file.
+
+PR 32638
+
+Upstream-Status: Backport [https://sourceware.org/git/?p=binutils-gdb.git;a=patch;h=75086e9de1707281172cc77f178e7949a4414ed0]
+CVE: CVE-2025-1178
+
+Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
+
+diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c
+index cb32732e..a08e9c97 100644
+--- a/bfd/elf64-x86-64.c
++++ b/bfd/elf64-x86-64.c
+@@ -5031,6 +5031,15 @@ elf_x86_64_finish_dynamic_symbol (bfd *output_bfd,
+ 
+       if (generate_dynamic_reloc)
+ 	{
++	  /* If the relgot section has not been created, then
++	     generate an error instead of a reloc.  cf PR 32638.  */
++	  if (relgot == NULL || relgot->size == 0)
++	    {
++	      info->callbacks->einfo (_("%F%pB: Unable to generate dynamic relocs because a suitable section does not exist\n"),
++					output_bfd);
++	      return false;
++	    }
++	  
+ 	  if (relative_reloc_name != NULL
+ 	      && htab->params->report_relative_reloc)
+ 	    _bfd_x86_elf_link_report_relative_reloc
-- 
2.43.0



^ permalink raw reply related	[flat|nested] 15+ messages in thread

* [OE-core][walnascar 09/14] binutils: Fix CVE-2025-1180
  2025-05-28 15:33 [OE-core][walnascar 00/14] Patch review Steve Sakoman
                   ` (7 preceding siblings ...)
  2025-05-28 15:33 ` [OE-core][walnascar 08/14] binutils: Fix CVE-2025-1178 Steve Sakoman
@ 2025-05-28 15:33 ` Steve Sakoman
  2025-05-28 15:33 ` [OE-core][walnascar 10/14] libarchive: upgrade 3.7.8 -> 3.7.9 Steve Sakoman
                   ` (4 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: Steve Sakoman @ 2025-05-28 15:33 UTC (permalink / raw)
  To: openembedded-core

From: Harish Sadineni <Harish.Sadineni@windriver.com>

Upstream-Status: Submitted [https://sourceware.org/pipermail/binutils/2025-May/141351.html]
CVE: CVE-2025-1180

cherry picked from upstream commit:
https://sourceware.org/git/?p=binutils-gdb.git;a=patch;h=f9978defb6fab0bd8583942d97c112b0932ac814

Signed-off-by: Harish Sadineni <Harish.Sadineni@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
 .../binutils/binutils-2.44.inc                |   1 +
 .../binutils/binutils/CVE-2025-1180.patch     | 165 ++++++++++++++++++
 2 files changed, 166 insertions(+)
 create mode 100644 meta/recipes-devtools/binutils/binutils/CVE-2025-1180.patch

diff --git a/meta/recipes-devtools/binutils/binutils-2.44.inc b/meta/recipes-devtools/binutils/binutils-2.44.inc
index 681b42fc3c..6906ab3efb 100644
--- a/meta/recipes-devtools/binutils/binutils-2.44.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.44.inc
@@ -36,5 +36,6 @@ SRC_URI = "\
      file://0013-Define-alignof-using-_Alignof-when-using-C11-or-newe.patch \
      file://0014-Remove-duplicate-pe-dll.o-entry-deom-targ_extra_ofil.patch \
      file://0015-CVE-2025-1178.patch \
+     file://CVE-2025-1180.patch \
 "
 S  = "${WORKDIR}/git"
diff --git a/meta/recipes-devtools/binutils/binutils/CVE-2025-1180.patch b/meta/recipes-devtools/binutils/binutils/CVE-2025-1180.patch
new file mode 100644
index 0000000000..073361cf19
--- /dev/null
+++ b/meta/recipes-devtools/binutils/binutils/CVE-2025-1180.patch
@@ -0,0 +1,165 @@
+From 509c5afcd71afd36cd6496f8c84733b11bd5e9e5 Mon Sep 17 00:00:00 2001
+From: Nick Clifton <nickc@redhat.com>
+Date: Thu, 22 May 2025 01:56:17 -0700
+Subject: [PATCH] Backport fix for PR 32642(CVE-2025-1180)
+
+Backporting the fix from PR 32636 to fix PR 32642 (ld SEGV (illegal read access)
+in _bfd_elf_write_section_eh_frame (bfd/elf-eh-frame.c:2234:29) with
+ --gc-sections --gc-keep-exported option)
+
+https://nvd.nist.gov/vuln/detail/CVE-2025-1180 is associated with
+PR32642 which will get fixed with commit from PR 32636.
+
+(cherry picked from commit: f9978defb6fab0bd8583942d97c112b0932ac814)
+Upstream-Status: Submitted [https://sourceware.org/pipermail/binutils/2025-May/141351.html]
+CVE: CVE-2025-1180
+
+Signed-off-by: Harish Sadineni <Harish.Sadineni@windriver.com>
+---
+ bfd/elflink.c | 88 +++++++++++++++++++++++++--------------------------
+ 1 file changed, 44 insertions(+), 44 deletions(-)
+
+diff --git a/bfd/elflink.c b/bfd/elflink.c
+index 6346d7e2b4b..d765b688801 100644
+--- a/bfd/elflink.c
++++ b/bfd/elflink.c
+@@ -96,22 +96,37 @@ _bfd_elf_link_keep_memory (struct bfd_link_info *info)
+   return true;
+ }
+ 
+-asection *
+-_bfd_elf_section_for_symbol (struct elf_reloc_cookie *cookie,
+-			     unsigned long r_symndx,
+-			     bool discard)
++static struct elf_link_hash_entry *
++get_ext_sym_hash (struct elf_reloc_cookie *cookie, unsigned long r_symndx)
+ {
+-  if (r_symndx >= cookie->locsymcount
+-      || ELF_ST_BIND (cookie->locsyms[r_symndx].st_info) != STB_LOCAL)
+-    {
+-      struct elf_link_hash_entry *h;
++  struct elf_link_hash_entry *h = NULL;
+ 
++  if ((r_symndx >= cookie->locsymcount
++       || ELF_ST_BIND (cookie->locsyms[r_symndx].st_info) != STB_LOCAL)
++      /* Guard against corrupt input.  See PR 32636 for an example.  */
++      && r_symndx >= cookie->extsymoff)
++    {
+       h = cookie->sym_hashes[r_symndx - cookie->extsymoff];
+ 
+       while (h->root.type == bfd_link_hash_indirect
+ 	     || h->root.type == bfd_link_hash_warning)
+ 	h = (struct elf_link_hash_entry *) h->root.u.i.link;
++    }
++
++  return h;
++}
+ 
++asection *
++_bfd_elf_section_for_symbol (struct elf_reloc_cookie *cookie,
++			     unsigned long r_symndx,
++			     bool discard)
++{
++  struct elf_link_hash_entry *h;
++
++  h = get_ext_sym_hash (cookie, r_symndx);
++  
++  if (h != NULL)
++    {
+       if ((h->root.type == bfd_link_hash_defined
+ 	   || h->root.type == bfd_link_hash_defweak)
+ 	   && discarded_section (h->root.u.def.section))
+@@ -119,21 +134,20 @@ _bfd_elf_section_for_symbol (struct elf_reloc_cookie *cookie,
+       else
+ 	return NULL;
+     }
+-  else
+-    {
+-      /* It's not a relocation against a global symbol,
+-	 but it could be a relocation against a local
+-	 symbol for a discarded section.  */
+-      asection *isec;
+-      Elf_Internal_Sym *isym;
+ 
+-      /* Need to: get the symbol; get the section.  */
+-      isym = &cookie->locsyms[r_symndx];
+-      isec = bfd_section_from_elf_index (cookie->abfd, isym->st_shndx);
+-      if (isec != NULL
+-	  && discard ? discarded_section (isec) : 1)
+-	return isec;
+-     }
++  /* It's not a relocation against a global symbol,
++     but it could be a relocation against a local
++     symbol for a discarded section.  */
++  asection *isec;
++  Elf_Internal_Sym *isym;
++
++  /* Need to: get the symbol; get the section.  */
++  isym = &cookie->locsyms[r_symndx];
++  isec = bfd_section_from_elf_index (cookie->abfd, isym->st_shndx);
++  if (isec != NULL
++      && discard ? discarded_section (isec) : 1)
++    return isec;
++
+   return NULL;
+ }
+ 
+@@ -13994,22 +14008,12 @@ _bfd_elf_gc_mark_rsec (struct bfd_link_info *info, asection *sec,
+   if (r_symndx == STN_UNDEF)
+     return NULL;
+ 
+-  if (r_symndx >= cookie->locsymcount
+-      || ELF_ST_BIND (cookie->locsyms[r_symndx].st_info) != STB_LOCAL)
++  h = get_ext_sym_hash (cookie, r_symndx);
++
++  if (h != NULL)
+     {
+       bool was_marked;
+ 
+-      h = cookie->sym_hashes[r_symndx - cookie->extsymoff];
+-      if (h == NULL)
+-	{
+-	  info->callbacks->fatal (_("%F%P: corrupt input: %pB\n"),
+-				  sec->owner);
+-	  return NULL;
+-	}
+-      while (h->root.type == bfd_link_hash_indirect
+-	     || h->root.type == bfd_link_hash_warning)
+-	h = (struct elf_link_hash_entry *) h->root.u.i.link;
+-
+       was_marked = h->mark;
+       h->mark = 1;
+       /* Keep all aliases of the symbol too.  If an object symbol
+@@ -15064,17 +15068,12 @@ bfd_elf_reloc_symbol_deleted_p (bfd_vma offset, void *cookie)
+       if (r_symndx == STN_UNDEF)
+ 	return true;
+ 
+-      if (r_symndx >= rcookie->locsymcount
+-	  || ELF_ST_BIND (rcookie->locsyms[r_symndx].st_info) != STB_LOCAL)
+-	{
+-	  struct elf_link_hash_entry *h;
+-
+-	  h = rcookie->sym_hashes[r_symndx - rcookie->extsymoff];
++      struct elf_link_hash_entry *h;
+ 
+-	  while (h->root.type == bfd_link_hash_indirect
+-		 || h->root.type == bfd_link_hash_warning)
+-	    h = (struct elf_link_hash_entry *) h->root.u.i.link;
++      h = get_ext_sym_hash (rcookie, r_symndx);
+ 
++      if (h != NULL)
++	{
+ 	  if ((h->root.type == bfd_link_hash_defined
+ 	       || h->root.type == bfd_link_hash_defweak)
+ 	      && (h->root.u.def.section->owner != rcookie->abfd
+@@ -15098,6 +15097,7 @@ bfd_elf_reloc_symbol_deleted_p (bfd_vma offset, void *cookie)
+ 		  || discarded_section (isec)))
+ 	    return true;
+ 	}
++      
+       return false;
+     }
+   return false;
+-- 
+2.49.0
+
-- 
2.43.0



^ permalink raw reply related	[flat|nested] 15+ messages in thread

* [OE-core][walnascar 10/14] libarchive: upgrade 3.7.8 -> 3.7.9
  2025-05-28 15:33 [OE-core][walnascar 00/14] Patch review Steve Sakoman
                   ` (8 preceding siblings ...)
  2025-05-28 15:33 ` [OE-core][walnascar 09/14] binutils: Fix CVE-2025-1180 Steve Sakoman
@ 2025-05-28 15:33 ` Steve Sakoman
  2025-05-28 15:33 ` [OE-core][walnascar 11/14] epiphany: upgrade 48.0 -> 48.3 Steve Sakoman
                   ` (3 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: Steve Sakoman @ 2025-05-28 15:33 UTC (permalink / raw)
  To: openembedded-core

From: Peter Marko <peter.marko@siemens.com>

https://github.com/libarchive/libarchive/releases/tag/v3.7.9

Libarchive 3.7.9 is a bugfix release
Important bugfixes:
* a regression in libarchive 3.7.8 regarding GNU sparse entries was fixed (#2558)

Also remove CVE_STATUS which was obsolete already before this upgrade.

(From OE-Core rev: 670f3fa028f3e873acf4c5265d3f5e4a3aa0ec89)

Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
 .../libarchive/{libarchive_3.7.8.bb => libarchive_3.7.9.bb}   | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)
 rename meta/recipes-extended/libarchive/{libarchive_3.7.8.bb => libarchive_3.7.9.bb} (91%)

diff --git a/meta/recipes-extended/libarchive/libarchive_3.7.8.bb b/meta/recipes-extended/libarchive/libarchive_3.7.9.bb
similarity index 91%
rename from meta/recipes-extended/libarchive/libarchive_3.7.8.bb
rename to meta/recipes-extended/libarchive/libarchive_3.7.9.bb
index d78b38d3e9..9d134f7d38 100644
--- a/meta/recipes-extended/libarchive/libarchive_3.7.8.bb
+++ b/meta/recipes-extended/libarchive/libarchive_3.7.9.bb
@@ -33,9 +33,7 @@ SRC_URI = "https://libarchive.org/downloads/libarchive-${PV}.tar.gz"
 
 UPSTREAM_CHECK_URI = "http://libarchive.org/"
 
-SRC_URI[sha256sum] = "a123d87b1bd8adb19e8c187da17ae2d957c7f9596e741b929e6b9ceefea5ad0f"
-
-CVE_STATUS[CVE-2023-30571] = "upstream-wontfix: upstream has documented that reported function is not thread-safe"
+SRC_URI[sha256sum] = "aa90732c5a6bdda52fda2ad468ac98d75be981c15dde263d7b5cf6af66fd009f"
 
 inherit autotools update-alternatives pkgconfig
 
-- 
2.43.0



^ permalink raw reply related	[flat|nested] 15+ messages in thread

* [OE-core][walnascar 11/14] epiphany: upgrade 48.0 -> 48.3
  2025-05-28 15:33 [OE-core][walnascar 00/14] Patch review Steve Sakoman
                   ` (9 preceding siblings ...)
  2025-05-28 15:33 ` [OE-core][walnascar 10/14] libarchive: upgrade 3.7.8 -> 3.7.9 Steve Sakoman
@ 2025-05-28 15:33 ` Steve Sakoman
  2025-05-28 15:33 ` [OE-core][walnascar 12/14] libmatchbox: upgrade 1.13 -> 1.14 Steve Sakoman
                   ` (2 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: Steve Sakoman @ 2025-05-28 15:33 UTC (permalink / raw)
  To: openembedded-core

From: Wang Mingyu <wangmy@fujitsu.com>

Changelog:
===========
- Fix crash when opening downloaded file
- Fix crash when opening incognito window
- Fix Crash when trying to select download location
- Fix Crash in escape_csv_field() when exporting passwords
- Fix Adding WhatsApp as a web app crashes
- Fix Pressing Escape key in addressbar resets the cursor to beginning of
  the widget
- Fix Epiphay shouldn't show the privacy dialog in incognito mode
- Fix (CVE-2025-3839) Require user interaction before opening URL in
  external application
- Fix Code cleanup
- Fix window: fix crash when force closing window without session
- Fix Several fixes for password export
- Fix Remove Granite support from Tech Preview and Canary
- Fix find-toolbar: fix crash on load-changed

Signed-off-by: Wang Mingyu <wangmy@fujitsu.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

(master rev: 2c60159fffd76b5dbe75bf7d6758e5f78b166714)

Signed-off-by: Zhang Peng <peng.zhang1.cn@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
 .../epiphany/{epiphany_48.0.bb => epiphany_48.3.bb}             | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-gnome/epiphany/{epiphany_48.0.bb => epiphany_48.3.bb} (94%)

diff --git a/meta/recipes-gnome/epiphany/epiphany_48.0.bb b/meta/recipes-gnome/epiphany/epiphany_48.3.bb
similarity index 94%
rename from meta/recipes-gnome/epiphany/epiphany_48.0.bb
rename to meta/recipes-gnome/epiphany/epiphany_48.3.bb
index 9eff56df3a..74a17be5a5 100644
--- a/meta/recipes-gnome/epiphany/epiphany_48.0.bb
+++ b/meta/recipes-gnome/epiphany/epiphany_48.3.bb
@@ -31,7 +31,7 @@ SRC_URI = "${GNOME_MIRROR}/${GNOMEBN}/${@oe.utils.trim_version("${PV}", 1)}/${GN
            file://migrator.patch \
            file://distributor.patch \
            "
-SRC_URI[archive.sha256sum] = "c9d1f6dffbad03b0916436901c770da302879ca60a636d2b72b25b142ec05f80"
+SRC_URI[archive.sha256sum] = "da2953e7e2b73bf7473c0a33979104d79362795295eaa0a2a38ea188537daf13"
 
 # Developer mode enables debugging
 PACKAGECONFIG[developer-mode] = "-Ddeveloper_mode=true,-Ddeveloper_mode=false"
-- 
2.43.0



^ permalink raw reply related	[flat|nested] 15+ messages in thread

* [OE-core][walnascar 12/14] libmatchbox: upgrade 1.13 -> 1.14
  2025-05-28 15:33 [OE-core][walnascar 00/14] Patch review Steve Sakoman
                   ` (10 preceding siblings ...)
  2025-05-28 15:33 ` [OE-core][walnascar 11/14] epiphany: upgrade 48.0 -> 48.3 Steve Sakoman
@ 2025-05-28 15:33 ` Steve Sakoman
  2025-05-28 15:33 ` [OE-core][walnascar 13/14] gcc: fix incorrect preprocessor line numbers in large files Steve Sakoman
  2025-05-28 15:33 ` [OE-core][walnascar 14/14] python3-pygobject: RDEPENDS on gobject-introspection Steve Sakoman
  13 siblings, 0 replies; 15+ messages in thread
From: Steve Sakoman @ 2025-05-28 15:33 UTC (permalink / raw)
  To: openembedded-core

From: Gyorgy Sarvari <skandigraun@gmail.com>

Includes a fix for the library version to match the tagged version in git.

(From OE-Core rev: 3ba4b22ef7e50e017d25ba974666f2fdf190a8fd)

Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
 .../libmatchbox/{libmatchbox_1.13.bb => libmatchbox_1.14.bb}    | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-graphics/libmatchbox/{libmatchbox_1.13.bb => libmatchbox_1.14.bb} (95%)

diff --git a/meta/recipes-graphics/libmatchbox/libmatchbox_1.13.bb b/meta/recipes-graphics/libmatchbox/libmatchbox_1.14.bb
similarity index 95%
rename from meta/recipes-graphics/libmatchbox/libmatchbox_1.13.bb
rename to meta/recipes-graphics/libmatchbox/libmatchbox_1.14.bb
index f212eb5e96..87ec4c812f 100644
--- a/meta/recipes-graphics/libmatchbox/libmatchbox_1.13.bb
+++ b/meta/recipes-graphics/libmatchbox/libmatchbox_1.14.bb
@@ -13,7 +13,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=87712c91ca9a2c2d475a0604c00f8f54 \
 
 DEPENDS = "virtual/libx11 libxext"
 
-SRCREV = "35cd78efa3120efc46497f55c04382be960d1864"
+SRCREV = "04b214a0d5cf8285e196d90bf2332626b12c74ef"
 SRC_URI = "git://git.yoctoproject.org/${BPN};branch=master;protocol=https;tag=${PV}"
 
 S = "${WORKDIR}/git"
-- 
2.43.0



^ permalink raw reply related	[flat|nested] 15+ messages in thread

* [OE-core][walnascar 13/14] gcc: fix incorrect preprocessor line numbers in large files
  2025-05-28 15:33 [OE-core][walnascar 00/14] Patch review Steve Sakoman
                   ` (11 preceding siblings ...)
  2025-05-28 15:33 ` [OE-core][walnascar 12/14] libmatchbox: upgrade 1.13 -> 1.14 Steve Sakoman
@ 2025-05-28 15:33 ` Steve Sakoman
  2025-05-28 15:33 ` [OE-core][walnascar 14/14] python3-pygobject: RDEPENDS on gobject-introspection Steve Sakoman
  13 siblings, 0 replies; 15+ messages in thread
From: Steve Sakoman @ 2025-05-28 15:33 UTC (permalink / raw)
  To: openembedded-core

From: Yash Shinde <Yash.Shinde@windriver.com>

Resolve static assertion failures caused by incorrect line numbers
after #include directives, introduced by the backport of PR108900 to GCC.
Update line map handling to correctly compute locations in large files,
including fixes for both LC_ENTER and LC_LEAVE to ensure accurate
line number resolution in rare edge cases.

https://gcc.gnu.org/cgit/gcc/commit/?id=edf745dc519ddbfef127e2789bf11bfbacd300b7

Signed-off-by: Yash Shinde <Yash.Shinde@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
 meta/recipes-devtools/gcc/gcc-14.2.inc        |   1 +
 ...-incorrect-preprocessor-line-numbers.patch | 475 ++++++++++++++++++
 2 files changed, 476 insertions(+)
 create mode 100644 meta/recipes-devtools/gcc/gcc/0028-fix-incorrect-preprocessor-line-numbers.patch

diff --git a/meta/recipes-devtools/gcc/gcc-14.2.inc b/meta/recipes-devtools/gcc/gcc-14.2.inc
index f4e364f692..fa9003f604 100644
--- a/meta/recipes-devtools/gcc/gcc-14.2.inc
+++ b/meta/recipes-devtools/gcc/gcc-14.2.inc
@@ -72,6 +72,7 @@ SRC_URI = "${BASEURI} \
            file://0027-gcc-backport-patch-to-fix-data-relocation-to-ENDBR-s.patch \
            file://gcc.git-ab884fffe3fc82a710bea66ad651720d71c938b8.patch \
            file://0001-arm-Fix-LDRD-register-overlap-PR117675.patch \
+           file://0028-fix-incorrect-preprocessor-line-numbers.patch \
 "
 
 S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/${SOURCEDIR}"
diff --git a/meta/recipes-devtools/gcc/gcc/0028-fix-incorrect-preprocessor-line-numbers.patch b/meta/recipes-devtools/gcc/gcc/0028-fix-incorrect-preprocessor-line-numbers.patch
new file mode 100644
index 0000000000..5185236a3d
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc/0028-fix-incorrect-preprocessor-line-numbers.patch
@@ -0,0 +1,475 @@
+From 8cbe033a8a88fe6437cc5d343ae0ddf8dd3455c8 Mon Sep 17 00:00:00 2001
+From: Jakub Jelinek <jakub@redhat.com>
+Date: Thu, 8 May 2025 11:14:24 +0200
+Subject: libcpp: Further fixes for incorrect line numbers in large files
+ [PR120061]
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The backport of the PR108900 fix to 14 branch broke building chromium
+because static_assert (__LINE__ == expected_line_number, ""); now triggers
+as the __LINE__ values are off by one.
+This isn't the case on the trunk and 15 branch because we've switched
+to 64-bit location_t and so one actually needs far longer header files
+to trigger it.
+https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c11
+https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c12
+contain (large) testcases in patch form which show on the 14 branch
+that the first one used to fail before the PR108900 backport and now
+works correctly, while the second one attempts to match the chromium
+behavior and it used to pass before the PR108900 backport and now it
+FAILs.
+The two testcases show rare problematic cases, because
+do_include_common -> parse_include -> check_eol -> check_eol_1 ->
+cpp_get_token_1 -> _cpp_lex_token -> _cpp_lex_direct -> linemap_line_start
+triggers there
+      /* Allocate the new line_map.  However, if the current map only has a
+         single line we can sometimes just increase its column_bits instead. */
+      if (line_delta < 0
+          || last_line != ORDINARY_MAP_STARTING_LINE_NUMBER (map)
+          || SOURCE_COLUMN (map, highest) >= (1U << (column_bits - range_bits))
+          || ( /* We can't reuse the map if the line offset is sufficiently
+                  large to cause overflow when computing location_t values.  */
+              (to_line - ORDINARY_MAP_STARTING_LINE_NUMBER (map))
+              >= (((uint64_t) 1)
+                  << (CHAR_BIT * sizeof (linenum_type) - column_bits)))
+          || range_bits < map->m_range_bits)
+        map = linemap_check_ordinary
+                (const_cast <line_map *>
+                  (linemap_add (set, LC_RENAME,
+                                ORDINARY_MAP_IN_SYSTEM_HEADER_P (map),
+                                ORDINARY_MAP_FILE_NAME (map),
+                                to_line)));
+and so creates a new ordinary map on the line right after the
+(problematic) #include line.
+Now, in the spot that r14-11679-g8a884140c2bcb7 patched,
+pfile->line_table->highest_location in all 3 tests (also
+https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c13
+) is before the decrement the start of the line after the #include line and so
+the decrement is really desirable in that case to put highest_location
+[jakub@tucnak gcc-15]$ git log -1 --format=%B r15-9638-gbfcb5da69a41f7a5e41faab39b763d9d7c8bd2ea | cat
+libcpp: Further fixes for incorrect line numbers in large files [PR120061]
+
+The backport of the PR108900 fix to 14 branch broke building chromium
+because static_assert (__LINE__ == expected_line_number, ""); now triggers
+as the __LINE__ values are off by one.
+This isn't the case on the trunk and 15 branch because we've switched
+to 64-bit location_t and so one actually needs far longer header files
+to trigger it.
+https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c11
+https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c12
+contain (large) testcases in patch form which show on the 14 branch
+that the first one used to fail before the PR108900 backport and now
+works correctly, while the second one attempts to match the chromium
+behavior and it used to pass before the PR108900 backport and now it
+FAILs.
+The two testcases show rare problematic cases, because
+do_include_common -> parse_include -> check_eol -> check_eol_1 ->
+cpp_get_token_1 -> _cpp_lex_token -> _cpp_lex_direct -> linemap_line_start
+triggers there
+      /* Allocate the new line_map.  However, if the current map only has a
+         single line we can sometimes just increase its column_bits instead. */
+      if (line_delta < 0
+          || last_line != ORDINARY_MAP_STARTING_LINE_NUMBER (map)
+          || SOURCE_COLUMN (map, highest) >= (1U << (column_bits - range_bits))
+          || ( /* We can't reuse the map if the line offset is sufficiently
+                  large to cause overflow when computing location_t values.  */
+              (to_line - ORDINARY_MAP_STARTING_LINE_NUMBER (map))
+              >= (((uint64_t) 1)
+                  << (CHAR_BIT * sizeof (linenum_type) - column_bits)))
+          || range_bits < map->m_range_bits)
+        map = linemap_check_ordinary
+                (const_cast <line_map *>
+                  (linemap_add (set, LC_RENAME,
+                                ORDINARY_MAP_IN_SYSTEM_HEADER_P (map),
+                                ORDINARY_MAP_FILE_NAME (map),
+                                to_line)));
+and so creates a new ordinary map on the line right after the
+(problematic) #include line.
+Now, in the spot that r14-11679-g8a884140c2bcb7 patched,
+pfile->line_table->highest_location in all 3 tests (also
+https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c13
+) is before the decrement the start of the line after the #include line and so
+the decrement is really desirable in that case to put highest_location
+somewhere on the line where the #include actually is.
+But at the same time it is also undesirable, because if we do decrement it,
+then linemap_add LC_ENTER called from _cpp_do_file_change will then
+  /* Generate a start_location above the current highest_location.
+     If possible, make the low range bits be zero.  */
+  location_t start_location = set->highest_location + 1;
+  unsigned range_bits = 0;
+  if (start_location < LINE_MAP_MAX_LOCATION_WITH_COLS)
+    range_bits = set->default_range_bits;
+  start_location += (1 << range_bits) - 1;
+  start_location &=  ~((1 << range_bits) - 1);
+
+  linemap_assert (!LINEMAPS_ORDINARY_USED (set)
+                  || (start_location
+                      >= MAP_START_LOCATION (LINEMAPS_LAST_ORDINARY_MAP (set))));
+and we can end up with the new LC_ENTER ordinary map having the same
+start_location as the preceding LC_RENAME one.
+Next thing that happens is computation of included_from:
+  if (reason == LC_ENTER)
+    {
+      if (set->depth == 0)
+        map->included_from = 0;
+      else
+        /* The location of the end of the just-closed map.  */
+        map->included_from
+          = (((map[0].start_location - 1 - map[-1].start_location)
+              & ~((1 << map[-1].m_column_and_range_bits) - 1))
+             + map[-1].start_location);
+The normal case (e.g. with the testcase included at the start of this comment) is
+that map[-1] starts somewhere earlier and so map->included_from computation above
+nicely computes location_t which expands to the start of the #include line.
+With r14-11679 reverted, for #c11 as well as #c12
+map[0].start_location == map[-1].start_location above, and so it is
+((location_t) -1 & ~((1 << map[-1].m_column_and_range_bits) - 1)))
++ map[-1].start_location,
+which happens to be start of the #include line.
+For #c11 map[0].start_location is 0x500003a0 and map[-1] has
+m_column_and_range_bits 7 and map[-2] has m_column_and_range_bits 12 and
+map[0].included_from is set to 0x50000320.
+For #c12 map[0].start_location is 0x606c0402 and map[-2].start_location is
+0x606c0400 and m_column_and_range_bits is 0 for all 3 maps.
+map[0].included_from is set to 0x606c0401.
+The last important part is again in linemap_add when doing LC_LEAVE:
+      /* (MAP - 1) points to the map we are leaving. The
+         map from which (MAP - 1) got included should be the map
+         that comes right before MAP in the same file.  */
+      from = linemap_included_from_linemap (set, map - 1);
+
+      /* A TO_FILE of NULL is special - we use the natural values.  */
+      if (to_file == NULL)
+        {
+          to_file = ORDINARY_MAP_FILE_NAME (from);
+          to_line = SOURCE_LINE (from, from[1].start_location);
+          sysp = ORDINARY_MAP_IN_SYSTEM_HEADER_P (from);
+        }
+Here it wants to compute the right to_line which ought to be the line after
+the #include directive.
+On the #c11 testcase that doesn't work correctly though, because
+map[-1].included_from is 0x50000320, from[0] for that is LC_ENTER with
+start_location 0x4080 and m_column_and_range_bits 12 but note that we've
+earlier computed map[-1].start_location + (-1 & 0xffffff80) and so only
+decreased by 7 bits, so to_line is still on the line with #include and not
+after it.  In the #c12 that doesn't happen, all the ordinary maps involved
+there had 0 m_column_and_range_bits and so this computes correct line.
+
+Below is a fix for the trunk including testcases using the
+location_overflow_plugin hack to simulate the bugs without needing huge
+files (in the 14 case it is just 330KB and almost 10MB, but in the 15
+case it would need to be far bigger).
+The pre- r15-9018 trunk has
+FAIL: gcc.dg/plugin/location-overflow-test-pr116047.c -fplugin=./location_overflow_plugin.so  scan-file static_assert[^\n\r]*6[^\n\r]*== 6
+and current trunk
+FAIL: gcc.dg/plugin/location-overflow-test-pr116047.c -fplugin=./location_overflow_plugin.so  scan-file static_assert[^\n\r]*6[^\n\r]*== 6
+FAIL: gcc.dg/plugin/location-overflow-test-pr120061.c -fplugin=./location_overflow_plugin.so  scan-file static_assert[^\n\r]*5[^\n\r]*== 5
+and with the patch everything PASSes.
+
+The patch reverts the r14-11679 change, because it is incorrect,
+we really need to decrement it even when crossing ordinary map
+boundaries, so that the location is not on the line after the #include
+line but somewhere on the #include line.  It also patches two spots
+in linemap_add mentioned above to make sure we get correct locations
+both in the included_from location_t when doing LC_ENTER (second
+line-map.cc hunk) and when doing LC_LEAVE to compute the right to_line
+(first line-map.cc hunk), both in presence of an added LC_RENAME
+with the same start_location as the following LC_ENTER (i.e. the
+problematic cases).
+The LC_ENTER hunk is mostly to ensure included_form location_t is
+at the start of the #include line (column 0), without it we can
+decrease include_from not enough and end up at some random column
+in the middle of the line, because it is masking away
+map[-1].m_column_and_range_bits bits even when in the end the resulting
+include_from location_t will be found in map[-2] map with perhaps
+different m_column_and_range_bits.  That alone doesn't fix the bug
+though.
+The more important is the LC_LEAVE hunk and the problem there is
+caused by linemap_line_start not actually doing
+    r = set->highest_line + (line_delta << map->m_column_and_range_bits);
+when adding a new map (the LC_RENAME one because we need to switch to
+different number of directly encoded ranges, or columns, etc.).
+So, in the original PR108900 case that
+  to_line = SOURCE_LINE (from, from[1].start_location);
+doesn't do the right thing, from there is the last < 0x50000000 map
+with m_column_and_range_bits 12, from[1] is the first one above it
+and map[-1].included_from is the correct location of column 0 on
+the #include line, but as the new LC_RENAME map has been created without
+actually increasing highest_location to be on the new line (we've just
+set to_line of the new LC_RENAME map to the correct line),
+  to_line = SOURCE_LINE (from, from[1].start_location);
+stays on the same source line.  I've tried to just replace that with
+  to_line = SOURCE_LINE (from, linemap_included_from (map - 1)) + 1;
+i.e. just find out the #include line from map[-1].included_from and
+add 1 to it, unfortunately that breaks the
+c-c++-common/cpp/line-4.c
+test where we expect to stay on the same 0 line for LC_LEAVE from
+<command line> and gcc.dg/cpp/trad/Wunused.c, gcc.dg/cpp/trad/builtins.c
+and c-c++-common/analyzer/named-constants-via-macros-traditional.c tests
+all with -traditional-cpp preprocessing where to_line is also off-by-one
+from the expected one.
+So, this patch instead conditionalizes it, uses the
+  to_line = SOURCE_LINE (from, linemap_included_from (map - 1)) + 1;
+way only if from[1] is a LC_RENAME map (rather than the usual
+LC_ENTER one), that should limit it to the problematic cases of when
+parse_include peeked after EOL and had to create LC_RENAME map with
+the same start_location as the LC_ENTER after it.
+
+Some further justification for the LC_ENTER hunk, using the
+https://gcc.gnu.org/pipermail/gcc-patches/2025-May/682774.html testcase
+(old is 14 before r14-11679, vanilla current 14 and new with the 14 patch)
+I get
+$ /usr/src/gcc-14/obj/gcc/cc1.old -quiet -std=c23 pr116047.c -nostdinc
+In file included from pr116047-1.h:327677:21,
+                 from pr116047.c:4:
+pr116047-2.h:1:1: error: unknown type name ‘a’
+    1 | a b c;
+      | ^
+pr116047-2.h:1:5: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘c’
+    1 | a b c;
+      |     ^
+pr116047-1.h:327677:1: error: static assertion failed: ""
+327677 | #include "pr116047-2.h"
+       | ^~~~~~~~~~~~~
+$ /usr/src/gcc-14/obj/gcc/cc1.vanilla -quiet -std=c23 pr116047.c -nostdinc
+In file included from pr116047-1.h:327678,
+                 from pr116047.c:4:
+pr116047-2.h:1:1: error: unknown type name ‘a’
+    1 | a b c;
+      | ^
+pr116047-2.h:1:5: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘c’
+    1 | a b c;
+      |     ^
+$ /usr/src/gcc-14/obj/gcc/cc1.new -quiet -std=c23 pr116047.c -nostdinc
+In file included from pr116047-1.h:327677,
+                 from pr116047.c:4:
+pr116047-2.h:1:1: error: unknown type name ‘a’
+    1 | a b c;
+      | ^
+pr116047-2.h:1:5: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘c’
+    1 | a b c;
+      |     ^
+
+pr116047-1.h has on lines 327677+327678:
+ #include "pr116047-2.h"
+ static_assert (__LINE__ == 327678, "");
+so the static_assert failure is something that was dealt mainly in the
+LC_LEAVE hunk and files.cc reversion, but please have a look at the
+In file included from lines.
+14.2 emits correct line (#include "pr116047-2.h" is indeed on line
+327677) but some random column in there (which is not normally printed
+for smaller headers; 21 is the . before extension in the filename).
+Current trunk emits incorrect line (327678 instead of 327677, clearly
+it didn't decrement).
+And the patched compiler emits the right line with no column, as would
+be printed if I remove e.g. 300000 newlines from the file.
+
+2025-05-08  Jakub Jelinek  <jakub@redhat.com>
+
+	PR preprocessor/108900
+	PR preprocessor/116047
+	PR preprocessor/120061
+	* files.cc (_cpp_stack_file): Revert 2025-03-28 change.
+	* line-map.cc (linemap_add): Use
+	SOURCE_LINE (from, linemap_included_from (map - 1)) + 1; instead of
+	SOURCE_LINE (from, from[1].start_location); to compute to_line
+	for LC_LEAVE if from[1].reason is LC_RENAME.  For LC_ENTER
+	included_from computation, look at map[-2] or even lower if map[-1]
+	has the same start_location as map[0].
+
+	* gcc.dg/plugin/plugin.exp: Add location-overflow-test-pr116047.c
+	and location-overflow-test-pr120061.c.
+	* gcc.dg/plugin/location_overflow_plugin.c (plugin_init): Don't error
+	on unknown values, instead just break.
+	* gcc.dg/plugin/location-overflow-test-pr116047.c: New test.
+	* gcc.dg/plugin/location-overflow-test-pr116047-1.h: New test.
+	* gcc.dg/plugin/location-overflow-test-pr116047-2.h: New test.
+	* gcc.dg/plugin/location-overflow-test-pr120061.c: New test.
+	* gcc.dg/plugin/location-overflow-test-pr120061-1.h: New test.
+	* gcc.dg/plugin/location-overflow-test-pr120061-2.h: New test.
+
+Upstream-Status: Backport [https://gcc.gnu.org/cgit/gcc/commit/?id=edf745dc519ddbfef127e2789bf11bfbacd300b7]
+Signed-off-by: Yash Shinde <Yash.Shinde@windriver.com>
+---
+ .../plugin/location-overflow-test-pr116047-1.h     |  6 +++
+ .../plugin/location-overflow-test-pr116047-2.h     |  1 +
+ .../plugin/location-overflow-test-pr116047.c       |  5 +++
+ .../plugin/location-overflow-test-pr120061-1.h     |  6 +++
+ .../plugin/location-overflow-test-pr120061-2.h     |  1 +
+ .../plugin/location-overflow-test-pr120061.c       |  6 +++
+ .../gcc.dg/plugin/location_overflow_plugin.c       |  2 +-
+ gcc/testsuite/gcc.dg/plugin/plugin.exp             |  4 +-
+ libcpp/line-map.cc                                 | 48 ++++++++++++++++++----
+ 10 files changed, 69 insertions(+), 18 deletions(-)
+ create mode 100644 gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr116047-1.h
+ create mode 100644 gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr116047-2.h
+ create mode 100644 gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr116047.c
+ create mode 100644 gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr120061-1.h
+ create mode 100644 gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr120061-2.h
+ create mode 100644 gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr120061.c
+
+diff --git a/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr116047-1.h b/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr116047-1.h
+new file mode 100644
+index 000000000000..3dd6434a938b
+--- /dev/null
++++ b/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr116047-1.h
+@@ -0,0 +1,6 @@
++
++
++
++
++#include "location-overflow-test-pr116047-2.h"
++static_assert (__LINE__ == 6, "");
+diff --git a/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr116047-2.h b/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr116047-2.h
+new file mode 100644
+index 000000000000..048f715b4656
+--- /dev/null
++++ b/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr116047-2.h
+@@ -0,0 +1 @@
++int i;
+diff --git a/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr116047.c b/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr116047.c
+new file mode 100644
+index 000000000000..33f2c4ce8def
+--- /dev/null
++++ b/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr116047.c
+@@ -0,0 +1,5 @@
++/* PR preprocessor/116047 */
++/* { dg-do preprocess } */
++/* { dg-options "-nostdinc -std=c23 -fplugin-arg-location_overflow_plugin-value=0x4fff8080" } */
++#include "location-overflow-test-pr116047-1.h"
++/* { dg-final { scan-file location-overflow-test-pr116047.i "static_assert\[^\n\r]\*6\[^\n\r]\*== 6" } } */
+diff --git a/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr120061-1.h b/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr120061-1.h
+new file mode 100644
+index 000000000000..ebf7704f568e
+--- /dev/null
++++ b/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr120061-1.h
+@@ -0,0 +1,6 @@
++
++
++
++
++#include "location-overflow-test-pr120061-2.h"
++
+diff --git a/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr120061-2.h b/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr120061-2.h
+new file mode 100644
+index 000000000000..048f715b4656
+--- /dev/null
++++ b/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr120061-2.h
+@@ -0,0 +1 @@
++int i;
+diff --git a/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr120061.c b/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr120061.c
+new file mode 100644
+index 000000000000..e8e803898da3
+--- /dev/null
++++ b/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr120061.c
+@@ -0,0 +1,6 @@
++/* PR preprocessor/120061 */
++/* { dg-do preprocess } */
++/* { dg-options "-nostdinc -std=c23 -fplugin-arg-location_overflow_plugin-value=0x61000000" } */
++#include "location-overflow-test-pr120061-1.h"
++static_assert (__LINE__ == 5, "");
++/* { dg-final { scan-file location-overflow-test-pr120061.i "static_assert\[^\n\r]\*5\[^\n\r]\*== 5" } } */
+diff --git a/gcc/testsuite/gcc.dg/plugin/location_overflow_plugin.c b/gcc/testsuite/gcc.dg/plugin/location_overflow_plugin.c
+index d0a6b0755648..6f4497a1cb16 100644
+--- a/gcc/testsuite/gcc.dg/plugin/location_overflow_plugin.c
++++ b/gcc/testsuite/gcc.dg/plugin/location_overflow_plugin.c
+@@ -101,7 +101,7 @@ plugin_init (struct plugin_name_args *plugin_info,
+       break;
+ 
+     default:
+-      error_at (UNKNOWN_LOCATION, "unrecognized value for plugin argument");
++      break;
+     }
+ 
+   return 0;
+diff --git a/gcc/testsuite/gcc.dg/plugin/plugin.exp b/gcc/testsuite/gcc.dg/plugin/plugin.exp
+index 933f9a5850bc..438c6d87aad9 100644
+--- a/gcc/testsuite/gcc.dg/plugin/plugin.exp
++++ b/gcc/testsuite/gcc.dg/plugin/plugin.exp
+@@ -126,7 +126,9 @@ set plugin_test_list [list \
+     { location_overflow_plugin.c \
+ 	  location-overflow-test-1.c \
+ 	  location-overflow-test-2.c \
+-	  location-overflow-test-pr83173.c } \
++	  location-overflow-test-pr83173.c \
++	  location-overflow-test-pr116047.c \
++	  location-overflow-test-pr120061.c } \
+     { must_tail_call_plugin.c \
+ 	  must-tail-call-1.c \
+ 	  must-tail-call-2.c } \
+diff --git a/libcpp/line-map.cc b/libcpp/line-map.cc
+index d5200b317eee..1e659638d9f7 100644
+--- a/libcpp/line-map.cc
++++ b/libcpp/line-map.cc
+@@ -618,8 +618,8 @@ linemap_add (line_maps *set, enum lc_reason reason,
+ 	 #include "included", inside the same "includer" file.  */
+ 
+       linemap_assert (!MAIN_FILE_P (map - 1));
+-      /* (MAP - 1) points to the map we are leaving. The
+-	 map from which (MAP - 1) got included should be the map
++      /* (MAP - 1) points to the map we are leaving.  The
++	 map from which (MAP - 1) got included should be usually the map
+ 	 that comes right before MAP in the same file.  */
+       from = linemap_included_from_linemap (set, map - 1);
+ 
+@@ -627,7 +627,24 @@ linemap_add (line_maps *set, enum lc_reason reason,
+       if (to_file == NULL)
+ 	{
+ 	  to_file = ORDINARY_MAP_FILE_NAME (from);
+-	  to_line = SOURCE_LINE (from, from[1].start_location);
++	  /* Compute the line on which the map resumes, for #include this
++	     should be the line after the #include line.  Usually FROM is
++	     the map right before LC_ENTER map - the first map of the included
++	     file, and in that case SOURCE_LINE (from, from[1].start_location);
++	     computes the right line (and does handle even some special cases
++	     (e.g. where for returning from <command line> we still want to
++	     be at line 0 or some -traditional-cpp cases).  In rare cases
++	     FROM can be followed by LC_RENAME created by linemap_line_start
++	     for line right after #include line.  If that happens,
++	     start_location of the FROM[1] map will be the same as
++	     start_location of FROM[2] LC_ENTER, but FROM[1] start_location
++	     might not have advance enough for moving to a full next line.
++	     In that case compute the line of #include line and add 1 to it
++	     to advance to the next line.  See PR120061.  */
++	  if (from[1].reason == LC_RENAME)
++	    to_line = SOURCE_LINE (from, linemap_included_from (map - 1)) + 1;
++	  else
++	    to_line = SOURCE_LINE (from, from[1].start_location);
+ 	  sysp = ORDINARY_MAP_IN_SYSTEM_HEADER_P (from);
+ 	}
+       else
+@@ -657,11 +674,26 @@ linemap_add (line_maps *set, enum lc_reason reason,
+       if (set->depth == 0)
+ 	map->included_from = 0;
+       else
+-	/* The location of the end of the just-closed map.  */
+-	map->included_from
+-	  = (((map[0].start_location - 1 - map[-1].start_location)
+-	      & ~((1 << map[-1].m_column_and_range_bits) - 1))
+-	     + map[-1].start_location);
++	{
++	  /* Compute location from whence this line map was included.
++	     For #include this should be preferrably column 0 of the
++	     line on which #include directive appears.
++	     map[-1] is the just closed map and usually included_from
++	     falls within that map.  In rare cases linemap_line_start
++	     can insert a new LC_RENAME map for the line immediately
++	     after #include line, in that case map[-1] will have the
++	     same start_location as the new one and so included_from
++	     would not be from map[-1] but likely map[-2].  If that
++	     happens, mask off map[-2] m_column_and_range_bits bits
++	     instead of map[-1].  See PR120061.  */
++	  int i = -1;
++	  while (map[i].start_location == map[0].start_location)
++	    --i;
++	  map->included_from
++	    = (((map[0].start_location - 1 - map[i].start_location)
++		& ~((1 << map[i].m_column_and_range_bits) - 1))
++	       + map[i].start_location);
++	}
+       set->depth++;
+       if (set->trace_includes)
+ 	trace_include (set, map);
+-- 
-- 
2.43.0



^ permalink raw reply related	[flat|nested] 15+ messages in thread

* [OE-core][walnascar 14/14] python3-pygobject: RDEPENDS on gobject-introspection
  2025-05-28 15:33 [OE-core][walnascar 00/14] Patch review Steve Sakoman
                   ` (12 preceding siblings ...)
  2025-05-28 15:33 ` [OE-core][walnascar 13/14] gcc: fix incorrect preprocessor line numbers in large files Steve Sakoman
@ 2025-05-28 15:33 ` Steve Sakoman
  13 siblings, 0 replies; 15+ messages in thread
From: Steve Sakoman @ 2025-05-28 15:33 UTC (permalink / raw)
  To: openembedded-core

From: Yi Zhao <yi.zhao@windriver.com>

Since 3.51.0, python3-pygobject depends on libgirepository 2.0 provided
by glib-2.0 instead of libgirepository 1.0 provided by
gobject-introspection[1]. It still needs the typelib files from
libgirepository-1.0 package. Add gobject-introspection as a runtime
dependency.

Fixes:
$ python3
Python 3.13.2 (main, Feb  4 2025, 14:51:09) [GCC 14.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import gi
>>> from gi.repository import Gtk
Traceback (most recent call last):
  File "/usr/lib64/python3.13/site-packages/gi/importer.py", line 139, in create_module
    introspection_module = get_introspection_module(namespace)
  File "/usr/lib64/python3.13/site-packages/gi/module.py", line 243, in get_introspection_module
    module = IntrospectionModule(namespace, version)
  File "/usr/lib64/python3.13/site-packages/gi/module.py", line 111, in __init__
    repository.require(namespace, version)
    ~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^
gi.RepositoryError: Typelib file for namespace 'xlib', version '2.0' not found

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<python-input-1>", line 1, in <module>
    from gi.repository import Gtk
  File "/usr/lib64/python3.13/site-packages/gi/importer.py", line 141, in create_module
    raise ImportError(e) from e
ImportError: Typelib file for namespace 'xlib', version '2.0' not found

[1] https://gitlab.gnome.org/GNOME/pygobject/-/merge_requests/320

(From OE-Core rev: 6f9e02292c9305e795f2651c3bb6ef5b671e1c74)

Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
 meta/recipes-devtools/python/python3-pygobject_3.52.2.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/python/python3-pygobject_3.52.2.bb b/meta/recipes-devtools/python/python3-pygobject_3.52.2.bb
index 08f7dc67b0..cf1dd07639 100644
--- a/meta/recipes-devtools/python/python3-pygobject_3.52.2.bb
+++ b/meta/recipes-devtools/python/python3-pygobject_3.52.2.bb
@@ -29,6 +29,7 @@ RDEPENDS:${PN} += " \
     python3-asyncio \
     python3-io \
     python3-pkgutil \
+    gobject-introspection \
 "
 
 # python3-pycairo is checked on configuration -> DEPENDS
-- 
2.43.0



^ permalink raw reply related	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2025-05-28 15:34 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-05-28 15:33 [OE-core][walnascar 00/14] Patch review Steve Sakoman
2025-05-28 15:33 ` [OE-core][walnascar 01/14] sqlite3: patch CVE-2025-3277 Steve Sakoman
2025-05-28 15:33 ` [OE-core][walnascar 02/14] sqlite3: patch CVE-2025-29088 Steve Sakoman
2025-05-28 15:33 ` [OE-core][walnascar 03/14] sqlite3: mark CVE-2025-29087 as patched Steve Sakoman
2025-05-28 15:33 ` [OE-core][walnascar 04/14] ofono: patch CVE-2024-7537 Steve Sakoman
2025-05-28 15:33 ` [OE-core][walnascar 05/14] xz: patch CVE-2025-31115 Steve Sakoman
2025-05-28 15:33 ` [OE-core][walnascar 06/14] binutils: drop obsolete CVE_STATUS Steve Sakoman
2025-05-28 15:33 ` [OE-core][walnascar 07/14] binutils: mark CVE-2025-1153 as fixed Steve Sakoman
2025-05-28 15:33 ` [OE-core][walnascar 08/14] binutils: Fix CVE-2025-1178 Steve Sakoman
2025-05-28 15:33 ` [OE-core][walnascar 09/14] binutils: Fix CVE-2025-1180 Steve Sakoman
2025-05-28 15:33 ` [OE-core][walnascar 10/14] libarchive: upgrade 3.7.8 -> 3.7.9 Steve Sakoman
2025-05-28 15:33 ` [OE-core][walnascar 11/14] epiphany: upgrade 48.0 -> 48.3 Steve Sakoman
2025-05-28 15:33 ` [OE-core][walnascar 12/14] libmatchbox: upgrade 1.13 -> 1.14 Steve Sakoman
2025-05-28 15:33 ` [OE-core][walnascar 13/14] gcc: fix incorrect preprocessor line numbers in large files Steve Sakoman
2025-05-28 15:33 ` [OE-core][walnascar 14/14] python3-pygobject: RDEPENDS on gobject-introspection Steve Sakoman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox