Date   

IRC meeting start time

masashi.kudo@cybertrust.co.jp <masashi.kudo@...>
 

Hi, All,

This is a heads-up.

We will change start time of IRC meetings held every Thursday.
We will start the meeting at UTC 13:00. That is:
- Summer Time: USWest 06:00, USEast 09:00, UK 14:00, DE 15:00, TW 21:00, JP 22:00
- Winter Time: USWest 05:00, USEast 08:00, UK 13:00, DE 14:00, TW 21:00, JP 22:00

This change is effective starting tomorrow.

Best regards,
--
M. Kudo


Re: [isar-cip-core][WIP][PATCH] Add kconfig menu

Jan Kiszka
 

On 17.08.21 10:12, Jan Kiszka wrote:
From: Jan Kiszka <jan.kiszka@...>

Use the new kas menu plugin to present available image options to the
user. This also allows to model their dependencies, specifically as not
all options are supported on all boards.

Signed-off-by: Jan Kiszka <jan.kiszka@...>
---

Only for preview as the underlying kas feature is not yet merged. Try it
out by fetching kas-container from the kas next branch and then run

KAS_IMAGE_VERSION=next kas-container menu

This is the first more complex layer modeled via kconfig/kas-menu. I
think it nicely demonstrates the potential of this approach.

Kconfig | 146 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 146 insertions(+)
create mode 100644 Kconfig

diff --git a/Kconfig b/Kconfig
new file mode 100644
index 0000000..72c75bf
--- /dev/null
+++ b/Kconfig
@@ -0,0 +1,146 @@
+mainmenu "Isar core layer of the Civil Infrastructure Platform project"
+
+config KAS_INCLUDE_MAIN
+ string
+ default "kas-cip.yml"
+
+config KAS_BUILD_SYSTEM
+ string
+ default "isar"
+
+choice
+ prompt "Target board"
+ default TARGET_QEMU_AMD64
+
+config TARGET_QEMU_AMD64
+ bool "QEMU AMD64 (x86-64)"
+
+config TARGET_SIMATIC_IPC227E
+ bool "Siemens SIMATIC IPC227E"
+
+config TARGET_QEMU_ARM64
+ bool "QEMU ARM64 (aarch64)"
+
+config TARGET_HIHOPE_RZG2M
+ bool "HopeRun HiHope-RZ/G2M"
+
+config TARGET_QEMU_ARM
+ bool "QEMU ARM (armhf)"
+
+config TARGET_BBB
+ bool "BeagleBone Black"
+
+config TARGET_IWG20D
+ bool "iWave Systems RainboW-G20D-Qseven"
+
+endchoice
+
+config KAS_INCLUDE_BOARD
+ string
+ default "kas/board/qemu-amd64.yml" if TARGET_QEMU_AMD64
+ default "kas/board/simatic-ipc227e.yml" if TARGET_SIMATIC_IPC227E
+ default "kas/board/qemu-arm64.yml" if TARGET_QEMU_ARM64
+ default "kas/board/hihope-rzg2m.yml" if TARGET_HIHOPE_RZG2M
+ default "kas/board/qemu-arm.yml" if TARGET_QEMU_ARM
+ default "kas/board/bbb.yml" if TARGET_BBB
+ default "kas/board/iwg20m.yml" if TARGET_IWG20D
+
+comment "Kernel options"
+
+choice
+ prompt "CIP kernel version"
+ default KERNEL_4_19
+
+config KERNEL_4_4
+ bool "Kernel 4.4.x-cip"
+
+config KERNEL_4_19
+ bool "Kernel 4.19.x-cip"
+
+endchoice
+
+config KAS_INCLUDE_KERNEL
+ string
+ default "kas/opt/4.4.yml"
+ depends on KERNEL_4_4
+
+config KERNEL_RT
+ bool "Real-time CIP kernel"
+
+config KAS_INCLUDE_KERNEL_RT
+ string
+ default "kas/opt/rt.yml"
+ depends on KERNEL_RT
+
+comment "Debian distribution options"
+
+choice
+ prompt "Debian Release"
+ default DEBIAN_BUSTER
+
+config DEBIAN_STRETCH
+ bool "stretch (9)"
+
+config DEBIAN_BUSTER
+ bool "buster (10)"
+
+config DEBIAN_BULLSEYE
+ bool "bullseye (11)"
+
+endchoice
+
+config KAS_INCLUDE_DEBIAN
+ string
+ default "kas/opt/stretch.yml" if DEBIAN_STRETCH
+ default "kas/opt/bullseye.yml" if DEBIAN_BULLSEYE
+
+comment "Image features"
+
+choice
+ prompt "Image formats"
+ default IMAGE_FLASH
+
+config IMAGE_FLASH
+ bool "Flashable image"
+
+config IMAGE_ARTIFACTS
+ bool "Separate artifacts for NFS boot"
+
+endchoice
+
+config KAS_INCLUDE_IMAGE_FORMAT
+ string
+ default "kas/opt/targz.yml" if IMAGE_ARTIFACTS && (TARGET_QEMU_AMD64 || TARGET_QEMU_ARM64 || TARGET_QEMU_ARM)
+ default "kas/opt/wic-targz.yml" if IMAGE_ARTIFACTS && !(TARGET_QEMU_AMD64 || TARGET_QEMU_ARM64 || TARGET_QEMU_ARM)
+
+config IMAGE_SECURITY
+ bool "Security extensions"
+
+config KAS_INCLUDE_SECURITY
+ string
+ default "kas/opt/security.yml" if IMAGE_SECURITY
+
+config IMAGE_TESTING
+ bool "Test extensions"
+
+config KAS_INCLUDE_TESTING
+ string
+ default "kas/opt/test.yml" if IMAGE_TESTING
+
+if IMAGE_FLASH
+
+config IMAGE_SWUPDATE
+ bool "SWUpdate support for root partition"
+ depends on TARGET_QEMU_AMD64 || TARGET_SIMATIC_IPC227E
+
+config IMAGE_SECURE_BOOT
+ bool "Secure boot support"
+ depends on TARGET_QEMU_AMD64
+
+config KAS_INCLUDE_SWUPDATE_SECBOOT
+ string
+ default "kas/opt/ebg-swu.yml" if IMAGE_SWUPDATE && !IMAGE_SECURE_BOOT
+ default "kas/opt/ebg-secure-boot-snakeoil.yml" if !IMAGE_SWUPDATE && IMAGE_SECURE_BOOT
+ default "kas/opt/ebg-snakeoil-swu.yml" if IMAGE_SWUPDATE && IMAGE_SECURE_BOOT
+
+endif
Oh, wrong primary list. Was supposed to go to cip-dev, but possibly not
uninteresting for Isar as well.

Jan

--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux


Re: -stable-rc tests failing

Nobuhiro Iwamatsu
 

Hi,

-----Original Message-----
From: cip-dev@... [mailto:cip-dev@...] On Behalf Of Chris Paterson
Sent: Tuesday, August 17, 2021 5:58 AM
To: cip-dev@...
Subject: Re: [cip-dev] -stable-rc tests failing

Hello,

From: cip-dev@... <cip-dev@...> On
Behalf Of Chris Paterson via lists.cip-project.org
Sent: 16 August 2021 21:39

Hello,
[...]

But I still see problems with x86_qemu... the "2h timeout".
QEMU's queue is full. And QEMU of each lab is not working and it seems
that it can not be processed correctly.
All of the QEMU machines have somehow got stuck in the "reserved" state.
I'm trying to fix it. Will update you asap.
I've got these devices un-stuck now by editing their state in the database directly.
However, in the process of debugging I rebooted the LAVA server instance, so we'll now need to reboot the various labs,
which is dependent on the local admins.
Hopefully normal service will be resumed soon.
Thanks for your work!


Kind regards, Chris


Chris
Best regards,
Nobuhiro


Re: -stable-rc tests failing

Chris Paterson
 

Hello,

From: cip-dev@... <cip-dev@...> On
Behalf Of Chris Paterson via lists.cip-project.org
Sent: 16 August 2021 21:39

Hello,
[...]

But I still see problems with x86_qemu... the "2h timeout".
QEMU's queue is full. And QEMU of each lab is not working and it seems
that it can not be processed correctly.
All of the QEMU machines have somehow got stuck in the "reserved" state.
I'm trying to fix it. Will update you asap.
I've got these devices un-stuck now by editing their state in the database directly.
However, in the process of debugging I rebooted the LAVA server instance, so we'll now need to reboot the various labs, which is dependent on the local admins.
Hopefully normal service will be resumed soon.

Kind regards, Chris


Chris


Best regards,
Nobuhiro


Re: -stable-rc tests failing

Chris Paterson
 

Hello,

From: cip-dev@... <cip-dev@...> On
Behalf Of Nobuhiro Iwamatsu via lists.cip-project.org
Sent: 16 August 2021 00:15

Hi,

-----Original Message-----
From: cip-dev@... [mailto:cip-dev@...]
On Behalf Of Pavel Machek
Sent: Saturday, August 14, 2021 4:47 AM
To: Chris Paterson <Chris.Paterson2@...>
Cc: Pavel Machek <pavel@...>; cip-dev@...
Subject: Re: [cip-dev] -stable-rc tests failing

Hi!

WARNING: Retrying...                                error=invalid argument
2170ERROR: Downloading artifacts from coordinator... error couldn't
execute
GET against
https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab
.com%2Fapi%2Fv4%2Fjobs%2F1492901612%2Fartifacts&amp;data=04%7C01
%7Cchris.paterson2%40renesas.com%7C4479c8657b2a40a46e3108d960428bd
8%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C6376466612029063
02%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=qwhRPtRSueYf9
7CTKC1JVJbJGJWHpfwkWq9GebqwLs4%3D&amp;reserved=0?: Get
https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab
.com%2Fapi%2Fv4%2Fjobs%2F1492901612%2Fartifacts&amp;data=04%7C01
%7Cchris.paterson2%40renesas.com%7C4479c8657b2a40a46e3108d960428bd
8%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C6376466612029063
02%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=qwhRPtRSueYf9
7CTKC1JVJbJGJWHpfwkWq9GebqwLs4%3D&amp;reserved=0?: dial tcp: i/o
timeout
id=1492901612 token=9gNGsuaZ
2171FATAL: invalid argument
2173
Uploading artifacts for failed job

But I don't usually see this one:

https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab
.com%2Fcip-project%2Fcip-testing%2Flinux-stable-rc-ci%2F-
&amp;data=04%7C01%7Cchris.paterson2%40renesas.com%7C4479c8657b2a4
0a46e3108d960428bd8%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%
7C637646661202906302%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sda
ta=7bk5d%2FyboUuOw0l12NBKvIDvsnVLmzwvyVSniEUOjI4%3D&amp;reserv
ed=0
/jobs/1492901660

Job #371616: Submitted
219Health: Unknown
220Device Type: r8a7743-iwg20d-q7
221Device: None
222Test: boot
223URL:
https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flava.c
iplatform.org%2Fscheduler%2Fjob%2F371616&amp;data=04%7C01%7Cchris.
paterson2%40renesas.com%7C4479c8657b2a40a46e3108d960428bd8%7C53d
82571da1947e49cb4625a166a4a2a%7C0%7C0%7C637646661202906302%7CUn
known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Mkr7BDJRwjM%2F1Oeg4Q
GEOpN%2Bj6%2B8C2%2BZ8mtbOppdhY0%3D&amp;reserved=0
224
226ERROR: Job failed: execution took longer than 2h0m0s seconds
It looks like the LAVA server has stopped processing jobs. Our queue has
become very large!
I'll have to see what died and no doubt reboot it and the labs.

Sorry for the pain.
Thank you, it seems to be better now, and it looks like ctj_zynqmp is
available, too (I have not yet seen successful test, but it at least
tries).

But I still see problems with x86_qemu... the "2h timeout".
QEMU's queue is full. And QEMU of each lab is not working and it seems
that it can not be processed correctly.
All of the QEMU machines have somehow got stuck in the "reserved" state.
I'm trying to fix it. Will update you asap.

Chris


Best regards,
Nobuhiro


Re: -stable-rc tests failing

Nobuhiro Iwamatsu
 

Hi,

-----Original Message-----
From: cip-dev@... [mailto:cip-dev@...] On Behalf Of Pavel Machek
Sent: Saturday, August 14, 2021 4:47 AM
To: Chris Paterson <Chris.Paterson2@...>
Cc: Pavel Machek <pavel@...>; cip-dev@...
Subject: Re: [cip-dev] -stable-rc tests failing

Hi!

WARNING: Retrying...                                error=invalid argument
2170ERROR: Downloading artifacts from coordinator... error couldn't execute
GET against https://gitlab.com/api/v4/jobs/1492901612/artifacts?: Get
https://gitlab.com/api/v4/jobs/1492901612/artifacts?: dial tcp: i/o timeout
id=1492901612 token=9gNGsuaZ
2171FATAL: invalid argument
2173
Uploading artifacts for failed job

But I don't usually see this one:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-
/jobs/1492901660

Job #371616: Submitted
219Health: Unknown
220Device Type: r8a7743-iwg20d-q7
221Device: None
222Test: boot
223URL: https://lava.ciplatform.org/scheduler/job/371616
224
226ERROR: Job failed: execution took longer than 2h0m0s seconds
It looks like the LAVA server has stopped processing jobs. Our queue has become very large!
I'll have to see what died and no doubt reboot it and the labs.

Sorry for the pain.
Thank you, it seems to be better now, and it looks like ctj_zynqmp is
available, too (I have not yet seen successful test, but it at least
tries).

But I still see problems with x86_qemu... the "2h timeout".
QEMU's queue is full. And QEMU of each lab is not working and it seems
that it can not be processed correctly.

Best regards,
Nobuhiro


Re: -stable-rc tests failing

Pavel Machek
 

Hi!

WARNING: Retrying...                                error=invalid argument
2170ERROR: Downloading artifacts from coordinator... error couldn't execute
GET against https://gitlab.com/api/v4/jobs/1492901612/artifacts?: Get
https://gitlab.com/api/v4/jobs/1492901612/artifacts?: dial tcp: i/o timeout
id=1492901612 token=9gNGsuaZ
2171FATAL: invalid argument
2173
Uploading artifacts for failed job

But I don't usually see this one:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-
/jobs/1492901660

Job #371616: Submitted
219Health: Unknown
220Device Type: r8a7743-iwg20d-q7
221Device: None
222Test: boot
223URL: https://lava.ciplatform.org/scheduler/job/371616
224
226ERROR: Job failed: execution took longer than 2h0m0s seconds
It looks like the LAVA server has stopped processing jobs. Our queue has become very large!
I'll have to see what died and no doubt reboot it and the labs.

Sorry for the pain.
Thank you, it seems to be better now, and it looks like ctj_zynqmp is
available, too (I have not yet seen successful test, but it at least
tries).

But I still see problems with x86_qemu... the "2h timeout".

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: xilinx_emaclite CVE -- was Re: [cip-dev] New CVE entries this week

Masami Ichikawa
 

Hi !

On Thu, Aug 12, 2021 at 6:52 PM Pavel Machek <pavel@...> wrote:

Hi!

* CVE detail

New CVEs
CVE-2021-38205: net: xilinx_emaclite: Do not print real IOMEM pointer

xemaclite_of_probe() in drivers/net/ethernet/xilinx/xilinx_emaclite.c
leaks kernel memory layout.

Fixed status

mainline: [d0d62baa7f505bd4c59cd169692ff07ec49dde37]
stable/5.13: [8722275b41d5127048e1422a8a1b6370b4878533]
This affects our kernels (I looked at 5.10.57 and 4.4.277). On one
hand we could ask for backport, on the other... I'm not sure it is
serious enough to warrant any action.
I think this vulnerability seems to be low priority because an
attacker needs another vulnerability to abuse this vulnerability.
However, it would be nice to backport the patch too.
So I tried to apply the patch to 4.4, but it rejects, because types
changed in the meantime.

In particular eccd5403814b4e762e270ef0464bb86fb217b1bf and
18af77c50fede5b3fc22aa9f0a9b255a5c5285c9 change the printk.

It seems we are actually using the driver in one of the configs:

./4.4.y-cip/arm/toshiba_zynq.sources:drivers/net/ethernet/xilinx/xilinx_emaclite.c

Patch for 4.4 should look like this:

diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
index 909a008f9927..26cd42bfef0c 100644
--- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
+++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
@@ -1180,9 +1180,8 @@ static int xemaclite_of_probe(struct platform_device *ofdev)
}

dev_info(dev,
- "Xilinx EmacLite at 0x%08X mapped to 0x%08X, irq=%d\n",
- (unsigned int __force)ndev->mem_start,
- (unsigned int __force)lp->base_addr, ndev->irq);
+ "Xilinx EmacLite at 0x%08X mapped to 0x%p, irq=%d\n",
+ (unsigned int __force)ndev->mem_start, lp->base_addr, ndev->irq);
return 0;

error:
Thank you for your work!
This patch looks good to me.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Regarads,

--
Masami Ichikawa
Cybertrust Japan Co., Ltd.

Email :masami.ichikawa@...
:masami.ichikawa@...


xilinx_emaclite CVE -- was Re: [cip-dev] New CVE entries this week

Pavel Machek
 

Hi!

* CVE detail

New CVEs
CVE-2021-38205: net: xilinx_emaclite: Do not print real IOMEM pointer

xemaclite_of_probe() in drivers/net/ethernet/xilinx/xilinx_emaclite.c
leaks kernel memory layout.

Fixed status

mainline: [d0d62baa7f505bd4c59cd169692ff07ec49dde37]
stable/5.13: [8722275b41d5127048e1422a8a1b6370b4878533]
This affects our kernels (I looked at 5.10.57 and 4.4.277). On one
hand we could ask for backport, on the other... I'm not sure it is
serious enough to warrant any action.
I think this vulnerability seems to be low priority because an
attacker needs another vulnerability to abuse this vulnerability.
However, it would be nice to backport the patch too.
So I tried to apply the patch to 4.4, but it rejects, because types
changed in the meantime.

In particular eccd5403814b4e762e270ef0464bb86fb217b1bf and
18af77c50fede5b3fc22aa9f0a9b255a5c5285c9 change the printk.

It seems we are actually using the driver in one of the configs:

./4.4.y-cip/arm/toshiba_zynq.sources:drivers/net/ethernet/xilinx/xilinx_emaclite.c

Patch for 4.4 should look like this:

diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
index 909a008f9927..26cd42bfef0c 100644
--- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
+++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
@@ -1180,9 +1180,8 @@ static int xemaclite_of_probe(struct platform_device *ofdev)
}

dev_info(dev,
- "Xilinx EmacLite at 0x%08X mapped to 0x%08X, irq=%d\n",
- (unsigned int __force)ndev->mem_start,
- (unsigned int __force)lp->base_addr, ndev->irq);
+ "Xilinx EmacLite at 0x%08X mapped to 0x%p, irq=%d\n",
+ (unsigned int __force)ndev->mem_start, lp->base_addr, ndev->irq);
return 0;

error:

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: New CVE entries this week

Masami Ichikawa
 

Hi !

On Thu, Aug 12, 2021 at 2:43 PM Pavel Machek <pavel@...> wrote:

Hi!

* CVE detail

New CVEs
CVE-2021-38205: net: xilinx_emaclite: Do not print real IOMEM pointer

xemaclite_of_probe() in drivers/net/ethernet/xilinx/xilinx_emaclite.c
leaks kernel memory layout.

Fixed status

mainline: [d0d62baa7f505bd4c59cd169692ff07ec49dde37]
stable/5.13: [8722275b41d5127048e1422a8a1b6370b4878533]
This affects our kernels (I looked at 5.10.57 and 4.4.277). On one
hand we could ask for backport, on the other... I'm not sure it is
serious enough to warrant any action.
I think this vulnerability seems to be low priority because an
attacker needs another vulnerability to abuse this vulnerability.
However, it would be nice to backport the patch too.

Best regards,
Pavel

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Regards,
--
Masami Ichikawa
Cybertrust Japan Co., Ltd.

Email :masami.ichikawa@...
:masami.ichikawa@...


Re: New CVE entries this week

Pavel Machek
 

Hi!

* CVE detail

New CVEs
CVE-2021-38205: net: xilinx_emaclite: Do not print real IOMEM pointer

xemaclite_of_probe() in drivers/net/ethernet/xilinx/xilinx_emaclite.c
leaks kernel memory layout.

Fixed status

mainline: [d0d62baa7f505bd4c59cd169692ff07ec49dde37]
stable/5.13: [8722275b41d5127048e1422a8a1b6370b4878533]
This affects our kernels (I looked at 5.10.57 and 4.4.277). On one
hand we could ask for backport, on the other... I'm not sure it is
serious enough to warrant any action.

Best regards,
Pavel

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


New CVE entries this week

Masami Ichikawa
 

Hi !

It's this week's CVE report.

* CVE short summary

** New CVEs

CVE-2021-3635: There is no detailed information as of 2021/08/12

CVE-2021-38160: mainline and stable kernels are fixed.

CVE-2021-38166: Fixed in bfp tree. Not fixed in mainline as of 2021/08/12

CVE-2021-38198: mainline and v5.10 are fixed as of 2021/08/12

CVE-2021-38199: mainline, v4.19, and v5.X kernels are fixed. This CVE
introduced by commit 5c6e5b6 which is in since v4.8-rc1

CVE-2021-38200: This CVE only affects PowerPC architecture

CVE-2021-38201: This CVE is introduced since v5.11-rc1 so before 5.11
kernels aren't affected

CVE-2021-38202: This CVE is introduced since v5.13-rc1 so before 5.13
kernels aren't affected

CVE-2021-38203: This CVE is introduced since v5.13-rc1 so before 5.13
kernels aren't affected

CVE-2021-38204: mainline and stable kernels are fixed

CVE-2021-38205: mainline is fixed as of 2021/08/12

CVE-2021-38206: mainline and 5.10 are fixed. This CVE affects since v5.9

CVE-2021-38207: mainline and 5.10 are fixed. This CVE affects since v5.6-rc4

CVE-2021-38208: mainline and stable kernels are fixed as of 2021/08/21

CVE-2021-38209: mainline and 5.10 are fixed. This CVE is introduced
since 5.7-rc1 so before 5.7 kernels aren't affected this CVE.

** Updated CVEs

No update.

** Traking CVEs

CVE-2021-31615: there is no fixed information as of 2021/08/12

CVE-2021-3640: there is no fixed information as of 2021/08/12


* CVE detail

New CVEs

CVE-2021-3635: flowtable list del corruption with kernel BUG at
lib/list_debug.c:50

According to the redhat bugzilla, it said "A flaw was found in the
Linux kernels netfilter implementation. A missing generation check
during DELTABLE processing causes it to queue the DELFLOWTABLE
operation a second time possibly leading to data corruption and denial
of service. An attacker must have either root or CAP_SYS_ADMIN
capabilities to exploit this flaw." However, there is no more
detailed information as of 2021/08/12.

Fixed status

None

CVE-2021-38160: virtio_console: Assure used length from device is limited

Fixed status

mainline: [d00d8da5869a2608e97cfede094dfc5e11462a46]
stable/4.14: [56cf748562d3cbfd33d1ba2eb4a7603a5e20da88]
stable/4.19: [b5fba782ccd3d12a14f884cd20f255fc9c0eec0c]
stable/4.4: [187f14fb88a9e62d55924748a274816fe6f34de6]
stable/4.9: [9e2b8368b2079437c6840f3303cb0b7bc9b896ee]
stable/5.10: [f6ec306b93dc600a0ab3bb2693568ef1cc5f7f7a]
stable/5.13: [21a06a244d2576f93cbc9ce9bf95814c2810c36a]
stable/5.4: [52bd1bce8624acb861fa96b7c8fc2e75422dc8f7]

CVE-2021-38166: bpf: Fix integer overflow involving bucket_size

This CVE is introcued by commit 057996380a42 ("bpf: Add batch ops to
all htab bpf map") which was in since 5.6-rc1.

Fixed status

None

CVE-2021-38198: KVM: X86: MMU: Use the correct inherited permissions
to get shadow page

Fixed status

mainline: [b1bd5cba3306691c771d558e94baa73e8b0b96b7]
stable/5.10: [6b6ff4d1f349cb35a7c7d2057819af1b14f80437]

CVE-2021-38199: NFSv4: Initialise connection to the server in
nfs4_alloc_client()

This CVE is introduced by commit 5c6e5b6 ("NFS: Fix an Oops in the
pNFS files and flexfiles connection setup to the DS") which was in
v4.8-rc1. So, v4.4 is not affected this CVE.

Fixed status

mainline: [dd99e9f98fbf423ff6d365b37a98e8879170f17c]
stable/4.19: [743f6b973c8ba8a0a5ed15ab11e1d07fa00d5368]
stable/5.10: [ff4023d0194263a0827c954f623c314978cf7ddd]
stable/5.13: [b0bfac939030181177373f549398ba94c384713d]
stable/5.4: [81e03fe5bf8f5f66b8a62429fb4832b11ec6b272]

CVE-2021-38200: powerpc/perf: Fix crash with
'perf_instruction_pointer' when pmu is not set

This CVE only affects PowerPC architecture so we don't have to track it.

Fixed status

mainline: [60b7ed54a41b550d50caf7f2418db4a7e75b5bdc]

CVE-2021-38201: net/sunrpc/xdr.c in the Linux kernel before 5.13.4
allows remote attackers to cause a denial of service
(xdr_set_page_base slab-out-of-bounds access) by performing many NFS
4.2 READ_PLUS operations.

This CVE is introduced by commit 8d86e37 ("SUNRPC: Clean up helpers
xdr_set_iov() and xdr_set_page_base()") which is in since v5.11-rc1.
So, we don't have to track it.

Fixed status

mainline: [6d1c0f3d28f98ea2736128ed3e46821496dc3a8c]
stable/5.13: [a02357d7532b88e97329bd7786c7e72601109704]

CVE-2021-38202: fs/nfsd/trace.h in the Linux kernel before 5.13.4
might allow remote attackers to cause a denial of service
(out-of-bounds read in strlen) by sending NFS traffic when the trace
event framework is being used for nfsd.

This CVE is introduced by commit 6019ce0 ("NFSD: Add a tracepoint to
record directory entry encoding") which is in since v5.13-rc1.
We don't have to track it.

Fixed status

mainline: [7b08cf62b1239a4322427d677ea9363f0ab677c6]
stable/5.13: [7605bff387a9972038b217b6c60998778dbae931]

CVE-2021-38203: btrfs: fix deadlock with concurrent chunk allocations
involving system chunks

This CVE is introduced since v5.13-rc1 so 5.10, 4.19, 4.4 kernels
aren't affected. We don't have to track it.

Fixed status

mainline: [1cb3db1cf383a3c7dbda1aa0ce748b0958759947]
stable/5.13: [789b24d9950d3e67b227f81b3fab912a8fb257af]

CVE-2021-38204: usb: max-3421: Prevent corruption of freed memory

Fixed status

mainline: [b5fdf5c6e6bee35837e160c00ac89327bdad031b]
stable/4.14: [edddc79c4391f8001095320d3ca423214b9aa4bf]
stable/4.19: [51fc12f4d37622fa0c481604833f98f11b1cac4f]
stable/4.4: [fc2a7c2280fa2be8ff9b5af702368fcd49a0acdb]
stable/4.9: [ae3209b9fb086661ec1de4d8f4f0b951b272bbcd]
stable/5.10: [7af54a4e221e5619a87714567e2258445dc35435]
stable/5.13: [d4179cdb769a651f2ae89c325612a69bf6fbdf70]
stable/5.4: [863d071dbcd54dacf47192a1365faec46b7a68ca]

CVE-2021-38205: net: xilinx_emaclite: Do not print real IOMEM pointer

xemaclite_of_probe() in drivers/net/ethernet/xilinx/xilinx_emaclite.c
leaks kernel memory layout.

Fixed status

mainline: [d0d62baa7f505bd4c59cd169692ff07ec49dde37]
stable/5.13: [8722275b41d5127048e1422a8a1b6370b4878533]

CVE-2021-38206: mac80211: Fix NULL ptr deref for injected rate info

This CVE is introduced by commit cb17ed2 ("mac80211: parse radiotap
header when selecting Tx queue") which is in since 5.9-rc1.
Therefore before 5.9 kernels aren't affected.

Fixed status

mainline: [bddc0c411a45d3718ac535a070f349be8eca8d48]
stable/5.10: [f74df6e086083dc435f7500bdbc86b05277d17af]
stable/5.4: [b6c0ab11c88fb016bfc85fa4f6f878f5f4263646]

CVE-2021-38207: net: ll_temac: Fix TX BD buffer overwrite

This CVE is introduced by commit 84823ff ("net: ll_temac: Fix race
condition causing TX hang") which is in since v5.6-rc4. so before
5.6-rc kernels aren't affected.

Fixed status

mainline: [c364df2489b8ef2f5e3159b1dff1ff1fdb16040d]
stable/5.10: [cfe403f209b11fad123a882100f0822a52a7630f]
stable/5.4: [b6c0ab11c88fb016bfc85fa4f6f878f5f4263646]

CVE-2021-38208: net/nfc/llcp_sock.c in the Linux kernel before 5.12.10
allows local unprivileged users to cause a denial of service (NULL
pointer dereference and BUG) by making a getsockname call after a
certain type of failure of a bind call.

Fixed status

mainline: [4ac06a1e013cf5fdd963317ffd3b968560f33bba]
stable/4.14: [ffff05b9ee5c74c04bba2801c1f99b31975d74d9]
stable/4.19: [93e4ac2a9979a9a4ecc158409ed9c3044dc0ae1f]
stable/4.4: [eb6875d48590d8e564092e831ff07fa384d7e477]
stable/4.9: [39c15bd2e5d11bcf7f4c3dba2aad9e1e110a5d94]
stable/5.10: [48ee0db61c8299022ec88c79ad137f290196cac2]
stable/5.4: [5d4c4b06ed9fb7a69d0b2e2a73fc73226d25ab70]

CVE-2021-38209: net/netfilter/nf_conntrack_standalone.c in the Linux
kernel before 5.12.2 allows observation of changes in any net
namespace because these changes are leaked into all other net
namespaces. This is related to the NF_SYSCTL_CT_MAX,
NF_SYSCTL_CT_EXPECT_MAX, and NF_SYSCTL_CT_BUCKETS sysctls.

This CVE is introduced by commit d0febd8 ("netfilter: conntrack:
re-visit sysctls in unprivileged namespaces") which is in since
5.7-rc1. Therefore before 5.7 kernels aren't affected this CVE.

Fixed status

mainline: [2671fa4dc0109d3fb581bc3078fdf17b5d9080f6]
stable/4.14: [68122479c128a929f8f7bdd951cfdc8dd0e75b8f]
stable/4.19: [9b288479f7a901a14ce703938596438559d7df55]
stable/4.9: [da50f56e826e1db141693297afb99370ebc160dd]
stable/5.10: [d3598eb3915cc0c0d8cab42f4a6258ff44c4033e]
stable/5.4: [baea536cf51f8180ab993e374cb134b5edad25e2]

Updated CVEs

No update.

Currenty traking CVEs

CVE-2021-31615: Unencrypted Bluetooth Low Energy baseband links in
Bluetooth Core Specifications 4.0 through 5.2

There is no fixed information as of 2021/08/12.

CVE-2021-3640: UAF in sco_send_frame function

There is no fixed information as of 2021/08/12.

Regards,

--
Masami Ichikawa
Cybertrust Japan Co., Ltd.

Email :masami.ichikawa@...
:masami.ichikawa@...


CIP IRC weekly meeting today on libera.chat

masashi.kudo@cybertrust.co.jp <masashi.kudo@...>
 

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

Please note that we already moved from Freenode to libera.chat, and our channel is the following:
irc:irc.libera.chat:6667/cip

*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2021&month=8&day=12&hour=9&min=0&sec=0&p1=224&p2=179&p3=136&p4=37&p5=241&p6=248

USWest USEast UK DE TW JP
02:00 05:00 10:00 11:00 17:00 18:00


Last meeting minutes:
https://irclogs.baserock.org/meetings/cip/2021/08/cip.2021-08-05-09.00.log.html

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu & alicef
2. Do some experiment to lower burdens on CI - patersonc

* Kernel maintenance updates
* Kernel testing
* AOB

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.

Best regards,
--
M. Kudo
Cybertrust Japan Co., Ltd.


Re: -stable-rc tests failing

Chris Paterson
 

Hello Pavel,

From: Pavel Machek <pavel@...>
Sent: 11 August 2021 07:40

Hi!

-stable-rc testing seems to be failing more than usual.

This is the "usual" failure:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-
/jobs/1493077012

WARNING: Retrying...                                error=invalid argument
2170ERROR: Downloading artifacts from coordinator... error couldn't execute
GET against https://gitlab.com/api/v4/jobs/1492901612/artifacts?: Get
https://gitlab.com/api/v4/jobs/1492901612/artifacts?: dial tcp: i/o timeout
id=1492901612 token=9gNGsuaZ
2171FATAL: invalid argument
2173
Uploading artifacts for failed job

But I don't usually see this one:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-
/jobs/1492901660

Job #371616: Submitted
219Health: Unknown
220Device Type: r8a7743-iwg20d-q7
221Device: None
222Test: boot
223URL: https://lava.ciplatform.org/scheduler/job/371616
224
226ERROR: Job failed: execution took longer than 2h0m0s seconds
It looks like the LAVA server has stopped processing jobs. Our queue has become very large!
I'll have to see what died and no doubt reboot it and the labs.

Sorry for the pain.

Kind regards, Chris


Links where all the failures can be seen are:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-
4.4.y
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-
4.19.y
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-
5.10.y

I'll try hitting some resubmit buttons, but help would be welcome.

Best regards,
                                                              Pavel
--
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


-stable-rc tests failing

Pavel Machek
 

Hi!

-stable-rc testing seems to be failing more than usual.

This is the "usual" failure:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/jobs/1493077012

WARNING: Retrying... error=invalid argument
2170ERROR: Downloading artifacts from coordinator... error couldn't execute GET against https://gitlab.com/api/v4/jobs/1492901612/artifacts?: Get https://gitlab.com/api/v4/jobs/1492901612/artifacts?: dial tcp: i/o timeout id=1492901612 token=9gNGsuaZ
2171FATAL: invalid argument
2173
Uploading artifacts for failed job

But I don't usually see this one:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/jobs/1492901660

Job #371616: Submitted
219Health: Unknown
220Device Type: r8a7743-iwg20d-q7
221Device: None
222Test: boot
223URL: https://lava.ciplatform.org/scheduler/job/371616
224
226ERROR: Job failed: execution took longer than 2h0m0s seconds

Links where all the failures can be seen are:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-4.4.y
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-4.19.y
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y

I'll try hitting some resubmit buttons, but help would be welcome.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Duplicity & python3

Pavel Machek
 

Hi!

There was a lot of talk about Duplicity alternatives because of
python3 issues. I believe we should re-evaluate Duplicity, because
AFAICT it should work with python3 from version 0.8.10+:

http://duplicity.nongnu.org/vers8/CHANGELOG.md

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [isar-cip-core][PATCH] swupdate-config: Remove runtime dependency efibootguard-dev

Christian Storm
 

efibootguard-dev is only a build time dependency and
not an runtime dependency.

Signed-off-by: Quirin Gylstorff <quirin.gylstorff@...>
---
  classes/swupdate-config.bbclass | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/classes/swupdate-config.bbclass
b/classes/swupdate-config.bbclass
index dfa3579..e4879c7 100644
--- a/classes/swupdate-config.bbclass
+++ b/classes/swupdate-config.bbclass
@@ -38,7 +38,7 @@ KFEATURE_DEPS[luahandler] = "lua"
    KFEATURE_efibootguard = ""
  KFEATURE_efibootguard[BUILD_DEB_DEPENDS] = "efibootguard-dev"
-KFEATURE_efibootguard[DEBIAN_DEPENDS] = "efibootguard-dev"
+KFEATURE_efibootguard[DEBIAN_DEPENDS] = ""
  KFEATURE_efibootguard[DEPENDS] = "efibootguard-dev"
  KFEATURE_efibootguard[KCONFIG_SNIPPETS] =
"file://swupdate_defconfig_efibootguard.snippet"
 
-dev makes no sense, but don't we have any dep on libs? Or are they
statically linked?
It is statically linked - efibootguard-dev contains only libebgenv.a.
Ah, yeah, part the SWUpdate's problems...
Well, meanwhile, this pattern has been deprecated in favor of
using https://github.com/sbabic/libubootenv
I guess it's about time for EFI Boot Guard to catch up..


Kind regards,
Christian

--
Dr. Christian Storm
Siemens AG, Technology, T RDA IOT SES-DE
Otto-Hahn-Ring 6, 81739 München, Germany


[isar-cip-dev][PATCH] Uprevision the cip-kernel-config to latest one

Srinuvasan A
 

From: Srinuvasan A <srinuvasan_a@...>

Uprevision the cip-kernel-config to latest one.

Signed-off-by: Srinuvasan A <srinuvasan_a@...>
---
recipes-kernel/linux/linux-cip-common.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-kernel/linux/linux-cip-common.inc b/recipes-kernel/linux/linux-cip-common.inc
index 6362408..1afec88 100644
--- a/recipes-kernel/linux/linux-cip-common.inc
+++ b/recipes-kernel/linux/linux-cip-common.inc
@@ -25,6 +25,6 @@ SRC_URI_append = " ${@ "git://gitlab.com/cip-project/cip-kernel/cip-kernel-confi

SRC_URI_append_bbb = "file://${KERNEL_DEFCONFIG}"

-SRCREV_cip-kernel-config ?= "b72318b9346f7262f6dd7511384ca61bd8b545c8"
+SRCREV_cip-kernel-config ?= "cd5d43e99f4d5f20707d7ac1e721bb22d4c9e16e"

S = "${WORKDIR}/linux-cip-v${PV}"
--
2.25.1


Re: [isar-cip-core][PATCH] swupdate-config: Remove runtime dependency efibootguard-dev

Jan Kiszka
 

On 09.08.21 15:49, Gylstorff Quirin wrote:


On 8/9/21 2:54 PM, Jan Kiszka wrote:
On 09.08.21 12:29, Q. Gylstorff wrote:
From: Quirin Gylstorff <quirin.gylstorff@...>

efibootguard-dev is only a build time dependency and
not an runtime dependency.

Signed-off-by: Quirin Gylstorff <quirin.gylstorff@...>
---
  classes/swupdate-config.bbclass | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/classes/swupdate-config.bbclass
b/classes/swupdate-config.bbclass
index dfa3579..e4879c7 100644
--- a/classes/swupdate-config.bbclass
+++ b/classes/swupdate-config.bbclass
@@ -38,7 +38,7 @@ KFEATURE_DEPS[luahandler] = "lua"
    KFEATURE_efibootguard = ""
  KFEATURE_efibootguard[BUILD_DEB_DEPENDS] = "efibootguard-dev"
-KFEATURE_efibootguard[DEBIAN_DEPENDS] = "efibootguard-dev"
+KFEATURE_efibootguard[DEBIAN_DEPENDS] = ""
  KFEATURE_efibootguard[DEPENDS] = "efibootguard-dev"
  KFEATURE_efibootguard[KCONFIG_SNIPPETS] =
"file://swupdate_defconfig_efibootguard.snippet"
 
-dev makes no sense, but don't we have any dep on libs? Or are they
statically linked?
It is statically linked - efibootguard-dev contains only libebgenv.a.
Ah, yeah, part the SWUpdate's problems...

Thanks, applied.

Jan

--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux


Re: [isar-cip-core][PATCH] swupdate-config: Remove runtime dependency efibootguard-dev

Quirin Gylstorff
 

On 8/9/21 2:54 PM, Jan Kiszka wrote:
On 09.08.21 12:29, Q. Gylstorff wrote:
From: Quirin Gylstorff <quirin.gylstorff@...>

efibootguard-dev is only a build time dependency and
not an runtime dependency.

Signed-off-by: Quirin Gylstorff <quirin.gylstorff@...>
---
classes/swupdate-config.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/classes/swupdate-config.bbclass b/classes/swupdate-config.bbclass
index dfa3579..e4879c7 100644
--- a/classes/swupdate-config.bbclass
+++ b/classes/swupdate-config.bbclass
@@ -38,7 +38,7 @@ KFEATURE_DEPS[luahandler] = "lua"
KFEATURE_efibootguard = ""
KFEATURE_efibootguard[BUILD_DEB_DEPENDS] = "efibootguard-dev"
-KFEATURE_efibootguard[DEBIAN_DEPENDS] = "efibootguard-dev"
+KFEATURE_efibootguard[DEBIAN_DEPENDS] = ""
KFEATURE_efibootguard[DEPENDS] = "efibootguard-dev"
KFEATURE_efibootguard[KCONFIG_SNIPPETS] = "file://swupdate_defconfig_efibootguard.snippet"
-dev makes no sense, but don't we have any dep on libs? Or are they
statically linked?
It is statically linked - efibootguard-dev contains only libebgenv.a.

Quirin

Jan

3441 - 3460 of 10124