Date   

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


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

Jan Kiszka
 

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?

Jan

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


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

Quirin Gylstorff
 

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"

--
2.20.1


Re: [cip-members] FW: [kernelci-members] KernelCI Hackfest #2 - Sept 6-10 2021

Chris Paterson
 

Hello Iwamatsu-san,

From: cip-members@... <cip-members@...
project.org> On Behalf Of Nobuhiro Iwamatsu via lists.cip-project.org
Sent: 07 August 2021 07:11

Hi Chris,

I am interested in this.
Do you still accept this?
Of course! Thank you.
I'll forward your name to Guillaume.

Kind regards, Chris


Best regards,
Nobuhiro

2021年8月3日(火) 5:59 Chris Paterson <chris.paterson2@...>:

Hello all,

The KernelCI project has announced it's second hackfest in September.
The first one was pretty successful in getting some new features added to
KernelCI, and the hope is the same will happen next time as well.

One hope from Alice and I is that we can get some CIP members involved
to try and advance KernelCI + CIP integration/collaboration.
If you have any time available during the hackfest and would like to get
involved, please let me and/or Guillaume know.

Kind regards, Chris


-----Original Message-----
From: kernelci-members@groups.io <kernelci-members@groups.io> On
Behalf Of Guillaume Tucker via groups.io
Sent: 02 August 2021 10:00
To: kernelci@groups.io
Cc: kernelci-members <kernelci-members@groups.io>; automated-
testing@...; Collabora Kernel ML
<kernel@...>; linux-kernel@...; Jesse Barnes
<jsbarnes@...>; Summer Wang <wangsummer@...>;
linux-kselftest@...; workflows@...; kunit-
dev@...; clang-built-linux <clang-built-
linux@...>
Subject: [kernelci-members] KernelCI Hackfest #2 - Sept 6-10 2021

The first KernelCI hackfest[1] early June was successful in getting
a number of kernel developers to work alongside the core KernelCI
team. Test coverage was increased in particular with kselftest,
LTP, KUnit and a new test suite for libcamera. We're now improving
documentation and tooling to make it easier for anyone to get
started. Find out more about KernelCI on
https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkerne
lci.org%2F&amp;data=04%7C01%7Cchris.paterson2%40renesas.com%7C832b
1ef74f4e4951645208d9596a33b2%7C53d82571da1947e49cb4625a166a4a2a%7
C0%7C0%7C637639134934176687%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C100
0&amp;sdata=qAQvSZ4jek6NLkInJD3HBWtj%2BAfopqMKOwX0IkN4hlM%3D
&amp;reserved=0.

The second hackfest is scheduled for the 6th-10th September. It
should be a good opportunity to start discussing and working on
upstream kernel testing topics ahead of the Linux Plumbers
Conference[2].

Here's the project board where anyone can already add some ideas:

https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
b.com%2Forgs%2Fkernelci%2Fprojects%2F5&amp;data=04%7C01%7Cchris.p
aterson2%40renesas.com%7C832b1ef74f4e4951645208d9596a33b2%7C53d82
571da1947e49cb4625a166a4a2a%7C0%7C0%7C637639134934176687%7CUnkn
own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=orLWUKzJUOtPN9nf98KUN
UPPEaz5OAW%2BRz%2FD2Vb9Big%3D&amp;reserved=0

There is no registration system, but please reply to this email or
send a message on IRC (#kernelci libera.chat) or kernelci.slack.com
if you would like to take part so you'll get email updates and
invitations to the meetings and open hours sessions online. You
may just drop in and out at any point during the hackfest as you
see fit.

The hackfest features:

* Daily open hours online using Big Blue Button to discuss things
and get support from the KernelCI team

* KernelCI team members available across most time zones to provide
quick feedback

* A curated list of topics and a project board to help set
objectives and coordinate efforts between all contributors


As always, KernelCI is at the service of the kernel community so
please share any feedback you may have to help shape this upcoming
hackfest in the best possible way.

Thanks,
Guillaume


[1]
https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffoun
dation.kernelci.org%2Fblog%2F2021%2F06%2F24%2Fthe-first-ever-kernelci-
hackfest%2F&amp;data=04%7C01%7Cchris.paterson2%40renesas.com%7C83
2b1ef74f4e4951645208d9596a33b2%7C53d82571da1947e49cb4625a166a4a2a
%7C0%7C0%7C637639134934176687%7CUnknown%7CTWFpbGZsb3d8eyJWIj
oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1
000&amp;sdata=5qpPNgUnH0ykUFzsJ0Apv2Ho3T7%2FdEewxf6elAfDAKA%3
D&amp;reserved=0
[2]
https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
.linuxplumbersconf.org%2Fevent%2F11%2Fpage%2F104-accepted-
microconferences%23cont-
test&amp;data=04%7C01%7Cchris.paterson2%40renesas.com%7C832b1ef74
f4e4951645208d9596a33b2%7C53d82571da1947e49cb4625a166a4a2a%7C0%7
C0%7C637639134934176687%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&am
p;sdata=uugp%2BNxYO6iwP6VGA4vrl0Wwm0QOjgF7h0qYJI7G6LU%3D&amp
;reserved=0






--
Nobuhiro Iwamatsu




Re: lts-commit-lists updated: up to 5.10.55 and 4.19.200

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

Pavel-san,

Thanks very much! They are very helpful.

Best regards,
--
M. Kudo

-----Original Message-----
From: cip-dev@... <cip-dev@...> On Behalf Of Pavel Machek
Sent: Sunday, August 8, 2021 6:33 PM
To: cip-dev@...
Subject: [cip-dev] lts-commit-lists updated: up to 5.10.55 and 4.19.200

Hi!

I have pushed updates to lts-commit-lists, it should now include reviews up-to 5.10.55 and 4.19.200.

I'm not primarily focusing on reviewing 4.4.X patches, but due to way reviews are done, I have some reviews for 4.4.X, too. I'll merge them soon, unless someone objects.

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


lts-commit-lists updated: up to 5.10.55 and 4.19.200

Pavel Machek
 

Hi!

I have pushed updates to lts-commit-lists, it should now include
reviews up-to 5.10.55 and 4.19.200.

I'm not primarily focusing on reviewing 4.4.X patches, but due to way
reviews are done, I have some reviews for 4.4.X, too. I'll merge them
soon, unless someone objects.

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


Re: [cip-members] FW: [kernelci-members] KernelCI Hackfest #2 - Sept 6-10 2021

Nobuhiro Iwamatsu <iwamatsu@...>
 

Hi Chris,

I am interested in this.
Do you still accept this?

Best regards,
Nobuhiro

2021年8月3日(火) 5:59 Chris Paterson <chris.paterson2@...>:


Hello all,

The KernelCI project has announced it's second hackfest in September.
The first one was pretty successful in getting some new features added to KernelCI, and the hope is the same will happen next time as well.

One hope from Alice and I is that we can get some CIP members involved to try and advance KernelCI + CIP integration/collaboration.
If you have any time available during the hackfest and would like to get involved, please let me and/or Guillaume know.

Kind regards, Chris


-----Original Message-----
From: kernelci-members@groups.io <kernelci-members@groups.io> On Behalf Of Guillaume Tucker via groups.io
Sent: 02 August 2021 10:00
To: kernelci@groups.io
Cc: kernelci-members <kernelci-members@groups.io>; automated-testing@...; Collabora Kernel ML <kernel@...>; linux-kernel@...; Jesse Barnes <jsbarnes@...>; Summer Wang <wangsummer@...>; linux-kselftest@...; workflows@...; kunit-dev@...; clang-built-linux <clang-built-linux@...>
Subject: [kernelci-members] KernelCI Hackfest #2 - Sept 6-10 2021

The first KernelCI hackfest[1] early June was successful in getting
a number of kernel developers to work alongside the core KernelCI
team. Test coverage was increased in particular with kselftest,
LTP, KUnit and a new test suite for libcamera. We're now improving
documentation and tooling to make it easier for anyone to get
started. Find out more about KernelCI on https://kernelci.org/.

The second hackfest is scheduled for the 6th-10th September. It
should be a good opportunity to start discussing and working on
upstream kernel testing topics ahead of the Linux Plumbers
Conference[2].

Here's the project board where anyone can already add some ideas:

https://github.com/orgs/kernelci/projects/5

There is no registration system, but please reply to this email or
send a message on IRC (#kernelci libera.chat) or kernelci.slack.com
if you would like to take part so you'll get email updates and
invitations to the meetings and open hours sessions online. You
may just drop in and out at any point during the hackfest as you
see fit.

The hackfest features:

* Daily open hours online using Big Blue Button to discuss things
and get support from the KernelCI team

* KernelCI team members available across most time zones to provide
quick feedback

* A curated list of topics and a project board to help set
objectives and coordinate efforts between all contributors


As always, KernelCI is at the service of the kernel community so
please share any feedback you may have to help shape this upcoming
hackfest in the best possible way.

Thanks,
Guillaume


[1] https://foundation.kernelci.org/blog/2021/06/24/the-first-ever-kernelci-hackfest/
[2] https://www.linuxplumbersconf.org/event/11/page/104-accepted-microconferences#cont-test





--
Nobuhiro Iwamatsu


Re: New CVE entries this week

Masami Ichikawa
 

Hi!

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

Hi!

** Updated CVEs
CVE-2021-22543: v4.19 and v5.10 are fixed. v4.4 uses another way to
get pfn. If v4.4 is vulnerable it needs to write its own patch.
4.4 is very different in that area, and KVM is not exactly our
focus. A lot of research would be needed. I guess we can simply ignore
this one.

* CVE detail

CVE-2021-35477: unprivileged BPF program can obtain sensitive
information from kernel memory via a speculative store bypass
side-channel attack because the technique used by the BPF verifier to
manage speculation is unreliable

CVE-2021-34556 and CVE-2021-35477 are fixed by the same commits.
commit 2039f26f3aca fixes af86ca4e3088(introduced by v4.17-rc7) and
f7cf25b2026d(introduced by v5.3-rc1).

Fixed status
mainline: [f5e81d1117501546b7be050c5fbafa6efd2c722c,
2039f26f3aca5b0e419b98f65dd36481337b86ee]
stable/5.10: [bea9e2fd180892eba2574711b05b794f1d0e7b73,
0e9280654aa482088ee6ef3deadef331f5ac5fb0]
stable/5.13: [ddab060f996e17b38bb181c5fd11a83fd1bfa0df,
0b27bdf02c400684225ee5ee99970bcbf5082282]
Yes, speculation is huge problem, and getting BPF right with broken
CPUs will be hard. I'd hope CIP people are not using untrusted BTF
programs, and that we can ignore it.
I agree. Don't run untrusted programs on production system is most
important thing.
Ignore both CVE-2021-34556 and CVE-2021-35477.

CVE-2021-3669: reading /proc/sysvipc/shm does not scale with large
shared memory segment counts

According to redhat bugzilla, it said "Not reported upstream, patches
are being worked on. It is not considered high impact because of the
requirements and need to have massive amount of shm (usually well
above ulimits) ".

https://bugzilla.redhat.com/show_bug.cgi?id=1986473#c10
DoS only, and only in unusual configuration. I believe we can ignore
this one.
I agree.

CVE-2021-37159: hso_free_net_device in drivers/net/usb/hso.c in the
Linux kernel through 5.13.4 calls unregister_netdev without checking
for the NETREG_REGISTERED state, leading to a use-after-free and a
double free.

The mainline, 5.10, 5.13 are fixed.

Fixed status
mainline: [a6ecfb39ba9d7316057cea823b196b734f6b18ca]
stable/5.10: [115e4f5b64ae8d9dd933167cafe2070aaac45849]
stable/5.13: [eeaa4b8d1e2e6f10362673d283a97dccc7275afa]
I guess we could try to rework the function in similar way 5.10 did,
but... we are not using HSO in our configs, and I have hard time
imagining how "attacker" would trigger it. So this is... just a
bug. I'd suggest ignoring.
Thank you for checking the configuration. We don't use HSO configs so
that we don't have attack surface therefore we can ignore it.

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!

** Updated CVEs
CVE-2021-22543: v4.19 and v5.10 are fixed. v4.4 uses another way to
get pfn. If v4.4 is vulnerable it needs to write its own patch.
4.4 is very different in that area, and KVM is not exactly our
focus. A lot of research would be needed. I guess we can simply ignore
this one.

* CVE detail

CVE-2021-35477: unprivileged BPF program can obtain sensitive
information from kernel memory via a speculative store bypass
side-channel attack because the technique used by the BPF verifier to
manage speculation is unreliable

CVE-2021-34556 and CVE-2021-35477 are fixed by the same commits.
commit 2039f26f3aca fixes af86ca4e3088(introduced by v4.17-rc7) and
f7cf25b2026d(introduced by v5.3-rc1).

Fixed status
mainline: [f5e81d1117501546b7be050c5fbafa6efd2c722c,
2039f26f3aca5b0e419b98f65dd36481337b86ee]
stable/5.10: [bea9e2fd180892eba2574711b05b794f1d0e7b73,
0e9280654aa482088ee6ef3deadef331f5ac5fb0]
stable/5.13: [ddab060f996e17b38bb181c5fd11a83fd1bfa0df,
0b27bdf02c400684225ee5ee99970bcbf5082282]
Yes, speculation is huge problem, and getting BPF right with broken
CPUs will be hard. I'd hope CIP people are not using untrusted BTF
programs, and that we can ignore it.

CVE-2021-3669: reading /proc/sysvipc/shm does not scale with large
shared memory segment counts

According to redhat bugzilla, it said "Not reported upstream, patches
are being worked on. It is not considered high impact because of the
requirements and need to have massive amount of shm (usually well
above ulimits) ".

https://bugzilla.redhat.com/show_bug.cgi?id=1986473#c10
DoS only, and only in unusual configuration. I believe we can ignore
this one.

CVE-2021-37159: hso_free_net_device in drivers/net/usb/hso.c in the
Linux kernel through 5.13.4 calls unregister_netdev without checking
for the NETREG_REGISTERED state, leading to a use-after-free and a
double free.

The mainline, 5.10, 5.13 are fixed.

Fixed status
mainline: [a6ecfb39ba9d7316057cea823b196b734f6b18ca]
stable/5.10: [115e4f5b64ae8d9dd933167cafe2070aaac45849]
stable/5.13: [eeaa4b8d1e2e6f10362673d283a97dccc7275afa]
I guess we could try to rework the function in similar way 5.10 did,
but... we are not using HSO in our configs, and I have hard time
imagining how "attacker" would trigger it. So this is... just a
bug. I'd suggest ignoring.

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-3659: stable kernels are fixed

CVE-2021-35477: mainline, v5.10, and v5.13 are fixed

CVE-2021-34556: mainline, v5.10, and v5.13 are fixed

CVE-2021-3669: According to redhat bugzilla, it said "Not reported
upstream, patches are being worked on."

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

** Updated CVEs

CVE-2021-29256: vulnerability is in 3rd party module.

CVE-2021-31829: v4.4 is not affected this vulnerability. other stable
kernels are fixed

CVE-2021-3655: Updated v4.4 fixed status. stable kernels are fixed.

CVE-2021-22543: v4.19 and v5.10 are fixed. v4.4 uses another way to
get pfn. If v4.4 is vulnerable it needs to write its own patch.

CVE-2021-21781: v4.4 and v4.9 are fixed. all stable kernels are fixed.

CVE-2021-37159: mainline, v5.10, v5.13 are fixed as of 2021/08/05


** Traking CVEs

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

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


* CVE detail

New CVEs

CVE-2021-3659: NULL pointer dereference in llsec_key_alloc() in
net/mac802154/llsec.c

Stable kernels are fixed.

Fixed status

mainline: [1165affd484889d4986cf3b724318935a0b120d8]
stable/4.14: [d103fd20f0539e2bd615ed6f6159537cb7e2c5ba]
stable/4.19: [c166c0f5311dc9de687b8985574a5ee5166d367e]
stable/4.4: [cd19d85e6d4a361beb11431af3d22248190f5b48]
stable/4.9: [c3883480ce4ebe5b13dbfdc9f2c6503bc9e8ab69]
stable/5.10: [38731bbcd9f0bb8228baaed5feb4a1f76530e49c]
stable/5.4: [38ea2b3ed00fb4632a706f2c796d6aa4a884f573]


CVE-2021-35477: unprivileged BPF program can obtain sensitive
information from kernel memory via a speculative store bypass
side-channel attack because the technique used by the BPF verifier to
manage speculation is unreliable

CVE-2021-34556 and CVE-2021-35477 are fixed by the same commits.
commit 2039f26f3aca fixes af86ca4e3088(introduced by v4.17-rc7) and
f7cf25b2026d(introduced by v5.3-rc1).

Fixed status
mainline: [f5e81d1117501546b7be050c5fbafa6efd2c722c,
2039f26f3aca5b0e419b98f65dd36481337b86ee]
stable/5.10: [bea9e2fd180892eba2574711b05b794f1d0e7b73,
0e9280654aa482088ee6ef3deadef331f5ac5fb0]
stable/5.13: [ddab060f996e17b38bb181c5fd11a83fd1bfa0df,
0b27bdf02c400684225ee5ee99970bcbf5082282]

CVE-2021-34556: unprivileged BPF program can obtain sensitive
information from kernel memory via a speculative store bypass
side-channel attack because of the possibility of uninitialized memory
locations on the BPF stack

CVE-2021-34556 and CVE-2021-35477 are fixed by same commits. commit
2039f26f3aca fixes af86ca4e3088(introduced by v4.17-rc7) and
f7cf25b2026d(introduced by v5.3-rc1).

Fixed status
mainline: [f5e81d1117501546b7be050c5fbafa6efd2c722c,
2039f26f3aca5b0e419b98f65dd36481337b86ee]
stable/5.10: [bea9e2fd180892eba2574711b05b794f1d0e7b73,
0e9280654aa482088ee6ef3deadef331f5ac5fb0]
stable/5.13: [ddab060f996e17b38bb181c5fd11a83fd1bfa0df,
0b27bdf02c400684225ee5ee99970bcbf5082282]

CVE-2021-3669: reading /proc/sysvipc/shm does not scale with large
shared memory segment counts

According to redhat bugzilla, it said "Not reported upstream, patches
are being worked on. It is not considered high impact because of the
requirements and need to have massive amount of shm (usually well
above ulimits) ".

https://bugzilla.redhat.com/show_bug.cgi?id=1986473#c10

CVE-2021-3679: racing: Fix bug in rb_per_cpu_empty() that might cause deadloop

mainline and stable kernels are fixed.

Fixed status
mainline: [67f0d6d9883c13174669f88adac4f0ee656cc16a]
stable/4.14: [76598512d5d7fc407c319ca4448cf5348b65058a]
stable/4.19: [6a99bfee7f5625d2577a5c3b09a2bd2a845feb8a]
stable/4.4: [afa091792525dfa6c3c854069ec6b8a5ccc62c11]
stable/4.9: [7db12bae1a239d872d17e128fd5271da789bf99c]
stable/5.10: [757bdba8026be19b4f447487695cd0349a648d9e]
stable/5.13: [917a5bdd114a27c159796928cb3c09723a51d1c7]
stable/5.4: [f899f24d34d964593b16122a774c192a78e2ca56]

Updated CVEs

CVE-2021-29256: The Arm Mali GPU kernel driver allows an unprivileged
user to achieve access to freed memory, leading to information
disclosure or root privilege escalation

This driver is 3rd party module which is provided by ARM. Mainline
kernel doesn't provide driver code.
Bifrost and Valhall are fixed but Midgard driver is not fixed as of 2021/08/03.

CVE-2021-31829: kernel/bpf/verifier.c in the Linux kernel through
5.12.1 performs undesirable speculative loads, leading to disclosure
of stack content via side-channel attacks, aka CID-801c6058d14a

According to commit b9b34ddbe207, this CVE is introdueced by
979d63d50c0c. Also 979d63d50c0c fixes commit b215739 which was
released v4.15-rc8. so v4.4 is not affected this vulnerability.

Fixed status
mainline: [b9b34ddbe2076ade359cd5ce7537d5ed019e9807,
801c6058d14a82179a7ee17a4b532cac6fad067f]
stable/4.14: [4d542ddb88fb2f39bf7f14caa2902f3e8d06f6ba,
19e4f40ce75079b9532f35f92780db90104648f1]
stable/4.19: [0e2dfdc74a7f4036127356d42ea59388f153f42c,
bd9df99da9569befff2234b1201ac4e065e363d0]
stable/5.10: [2cfa537674cd1051a3b8111536d77d0558f33d5d,
2fa15d61e4cbaaa1d1250e67b251ff96952fa614]
stable/5.4: [53e0db429b37a32b8fc706d0d90eb4583ad13848,
8ba25a9ef9b9ca84d085aea4737e6c0852aa5bfd]

CVE-2021-3655: missing size validations on inbound SCTP packets

Update v4.4 fixed status. stable kernels are fixed.

Fixed status
mainline: [0c5dc070ff3d6246d22ddd931f23a6266249e3db,
50619dbf8db77e98d821d615af4f634d08e22698,
b6ffe7671b24689c09faa5675dd58f93758a97ae,
ef6c8d6ccf0c1dccdda092ebe8782777cd7803c9]
stable/4.19: [c7a03ebace4f9cd40d9cd9dd5fb2af558025583c,
dd16e38e1531258d332b0fc7c247367f60c6c381]
stable/4.4: [48cd035cad5b5fad0648aa8294c4223bedb166dd]
stable/4.9: [c7da1d1ed43a6c2bece0d287e2415adf2868697e]
stable/5.10: [d4dbef7046e24669278eba4455e9e8053ead6ba0,
6ef81a5c0e22233e13c748e813c54d3bf0145782]

CVE-2021-22543: An issue was discovered in the Linux: KVM through
Improper handling of VM_IO|VM_PFNMAP vmas in KVM can bypass RO checks
and can lead to pages being freed while still accessible by the VMM
and guest

The hva_to_pfn_remapped() doesn't exist in v4.4 kernel and it use
different way to get pfn.
If v4.4 affects this CVE, it'll need to write a patch.

Fixed status
mainline: [f8be156be163a052a067306417cd0ff679068c97]
stable/4.19: [117777467bc015f0dc5fc079eeba0fa80c965149]
stable/5.10: [dd8ed6c9bc2224c1ace5292d01089d3feb7ebbc3]
stable/5.12: [c36fbd888dcc27d365c865e6c959d7f7802a207c]
stable/5.4: [bb85717e3797123ae7724751af21d0c9d605d61e]

CVE-2021-21781: Arm SIGPAGE information disclosure vulnerability

All stable kernels are fixed.

Fixed status
mainline: [9c698bff66ab4914bb3d71da7dc6112519bde23e]
stable/4.14: [b71cc506778eb283b752400e234784ee86b5891c]
stable/4.19: [80ef523d2cb719c3de66787e922a96b5099d2fbb]
stable/4.4: [8db77dca7e1d1d1d6aa9334207ead57853832bb7]
stable/4.9: [aa1b5f2fe4532e99986f1eee2c04bb7d314e3007]
stable/5.10: [7913ec05fc02ccd7df83280451504b0a3e543097]
stable/5.4: [f49bff85b6dbb60a410c7f7dc53b52ee1dc22470]

CVE-2021-37159: hso_free_net_device in drivers/net/usb/hso.c in the
Linux kernel through 5.13.4 calls unregister_netdev without checking
for the NETREG_REGISTERED state, leading to a use-after-free and a
double free.

The mainline, 5.10, 5.13 are fixed.

Fixed status
mainline: [a6ecfb39ba9d7316057cea823b196b734f6b18ca]
stable/5.10: [115e4f5b64ae8d9dd933167cafe2070aaac45849]
stable/5.13: [eeaa4b8d1e2e6f10362673d283a97dccc7275afa]

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/03

CVE-2021-3640: UAF in sco_send_frame function

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

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=5&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/07/cip.2021-07-29-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: [ANNOUNCE] Release v4.4.277-cip60

Pavel Machek
 

Hi!

CIP kernel team has released Linux kernel v4.4.277-cip60.
The 4.4.y tree was scheduled to be released next week, but we have
rescheduled it for the release of the CIP-RT tree.

The linux-4.4.y-cip tree has been updated base version from v4.4.274
to v4.4.277. No CIP-specific patches have been added to this version.
Thank you, it was very useful for getting 4.4-rt released.

I noticed that linux-4.4.y-cip-rebase was not updated, but as there
were no changes between -cip59 and -cip60, it did not pose a problem.
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-4.4.y-cip-rebase

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

2901 - 2920 of 9573