-------------------
NOTE, this is the LAST 5.18.y stable release. This tree will be
end-of-life after this one. Please move to 5.19.y at this point in time
or let us know why that is not possible.
-------------------
This is the start of the stable review cycle for the 5.18.19 release.
There are 6 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sun, 21 Aug 2022 15:36:59 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.18.19-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.18.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 5.18.19-rc1
Coiby Xu <[email protected]>
arm64: kexec_file: use more system keyrings to verify kernel image signature
Coiby Xu <[email protected]>
kexec, KEYS: make the code in bzImage64_verify_sig generic
Qu Wenruo <[email protected]>
btrfs: raid56: don't trust any cached sector in __raid56_parity_recover()
Qu Wenruo <[email protected]>
btrfs: only write the sectors in the vertical stripe which has data stripes
Jamal Hadi Salim <[email protected]>
net_sched: cls_route: disallow handle of 0
Jens Wiklander <[email protected]>
tee: add overflow check in register_shm_helper()
-------------
Diffstat:
Makefile | 4 +--
arch/arm64/kernel/kexec_image.c | 11 +-----
arch/x86/kernel/kexec-bzimage64.c | 20 +----------
drivers/tee/tee_shm.c | 3 ++
fs/btrfs/raid56.c | 74 ++++++++++++++++++++++++++++++---------
include/linux/kexec.h | 7 ++++
kernel/kexec_file.c | 17 +++++++++
net/sched/cls_route.c | 10 ++++++
8 files changed, 98 insertions(+), 48 deletions(-)
From: Coiby Xu <[email protected]>
commit 0d519cadf75184a24313568e7f489a7fc9b1be3b upstream.
Currently, when loading a kernel image via the kexec_file_load() system
call, arm64 can only use the .builtin_trusted_keys keyring to verify
a signature whereas x86 can use three more keyrings i.e.
.secondary_trusted_keys, .machine and .platform keyrings. For example,
one resulting problem is kexec'ing a kernel image would be rejected
with the error "Lockdown: kexec: kexec of unsigned images is restricted;
see man kernel_lockdown.7".
This patch set enables arm64 to make use of the same keyrings as x86 to
verify the signature kexec'ed kernel image.
Fixes: 732b7b93d849 ("arm64: kexec_file: add kernel signature verification support")
Cc: [email protected] # 105e10e2cf1c: kexec_file: drop weak attribute from functions
Cc: [email protected] # 34d5960af253: kexec: clean up arch_kexec_kernel_verify_sig
Cc: [email protected] # 83b7bb2d49ae: kexec, KEYS: make the code in bzImage64_verify_sig generic
Acked-by: Baoquan He <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Co-developed-by: Michal Suchanek <[email protected]>
Signed-off-by: Michal Suchanek <[email protected]>
Acked-by: Will Deacon <[email protected]>
Signed-off-by: Coiby Xu <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm64/kernel/kexec_image.c | 11 +----------
1 file changed, 1 insertion(+), 10 deletions(-)
--- a/arch/arm64/kernel/kexec_image.c
+++ b/arch/arm64/kernel/kexec_image.c
@@ -14,7 +14,6 @@
#include <linux/kexec.h>
#include <linux/pe.h>
#include <linux/string.h>
-#include <linux/verification.h>
#include <asm/byteorder.h>
#include <asm/cpufeature.h>
#include <asm/image.h>
@@ -130,18 +129,10 @@ static void *image_load(struct kimage *i
return NULL;
}
-#ifdef CONFIG_KEXEC_IMAGE_VERIFY_SIG
-static int image_verify_sig(const char *kernel, unsigned long kernel_len)
-{
- return verify_pefile_signature(kernel, kernel_len, NULL,
- VERIFYING_KEXEC_PE_SIGNATURE);
-}
-#endif
-
const struct kexec_file_ops kexec_image_ops = {
.probe = image_probe,
.load = image_load,
#ifdef CONFIG_KEXEC_IMAGE_VERIFY_SIG
- .verify_sig = image_verify_sig,
+ .verify_sig = kexec_kernel_verify_pe_sig,
#endif
};
From: Jamal Hadi Salim <[email protected]>
commit 02799571714dc5dd6948824b9d080b44a295f695 upstream.
Follows up on:
https://lore.kernel.org/all/[email protected]/
handle of 0 implies from/to of universe realm which is not very
sensible.
Lets see what this patch will do:
$sudo tc qdisc add dev $DEV root handle 1:0 prio
//lets manufacture a way to insert handle of 0
$sudo tc filter add dev $DEV parent 1:0 protocol ip prio 100 \
route to 0 from 0 classid 1:10 action ok
//gets rejected...
Error: handle of 0 is not valid.
We have an error talking to the kernel, -1
//lets create a legit entry..
sudo tc filter add dev $DEV parent 1:0 protocol ip prio 100 route from 10 \
classid 1:10 action ok
//what did the kernel insert?
$sudo tc filter ls dev $DEV parent 1:0
filter protocol ip pref 100 route chain 0
filter protocol ip pref 100 route chain 0 fh 0x000a8000 flowid 1:10 from 10
action order 1: gact action pass
random type none pass val 0
index 1 ref 1 bind 1
//Lets try to replace that legit entry with a handle of 0
$ sudo tc filter replace dev $DEV parent 1:0 protocol ip prio 100 \
handle 0x000a8000 route to 0 from 0 classid 1:10 action drop
Error: Replacing with handle of 0 is invalid.
We have an error talking to the kernel, -1
And last, lets run Cascardo's POC:
$ ./poc
0
0
-22
-22
-22
Signed-off-by: Jamal Hadi Salim <[email protected]>
Acked-by: Stephen Hemminger <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/sched/cls_route.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/net/sched/cls_route.c
+++ b/net/sched/cls_route.c
@@ -424,6 +424,11 @@ static int route4_set_parms(struct net *
return -EINVAL;
}
+ if (!nhandle) {
+ NL_SET_ERR_MSG(extack, "Replacing with handle of 0 is invalid");
+ return -EINVAL;
+ }
+
h1 = to_hash(nhandle);
b = rtnl_dereference(head->table[h1]);
if (!b) {
@@ -477,6 +482,11 @@ static int route4_change(struct net *net
int err;
bool new = true;
+ if (!handle) {
+ NL_SET_ERR_MSG(extack, "Creating with handle of 0 is invalid");
+ return -EINVAL;
+ }
+
if (opt == NULL)
return handle ? -EINVAL : 0;
From: Coiby Xu <[email protected]>
commit c903dae8941deb55043ee46ded29e84e97cd84bb upstream.
commit 278311e417be ("kexec, KEYS: Make use of platform keyring for
signature verify") adds platform keyring support on x86 kexec but not
arm64.
The code in bzImage64_verify_sig uses the keys on the
.builtin_trusted_keys, .machine, if configured and enabled,
.secondary_trusted_keys, also if configured, and .platform keyrings
to verify the signed kernel image as PE file.
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Reviewed-by: Michal Suchanek <[email protected]>
Signed-off-by: Coiby Xu <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kernel/kexec-bzimage64.c | 20 +-------------------
include/linux/kexec.h | 7 +++++++
kernel/kexec_file.c | 17 +++++++++++++++++
3 files changed, 25 insertions(+), 19 deletions(-)
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -17,7 +17,6 @@
#include <linux/kernel.h>
#include <linux/mm.h>
#include <linux/efi.h>
-#include <linux/verification.h>
#include <asm/bootparam.h>
#include <asm/setup.h>
@@ -528,28 +527,11 @@ static int bzImage64_cleanup(void *loade
return 0;
}
-#ifdef CONFIG_KEXEC_BZIMAGE_VERIFY_SIG
-static int bzImage64_verify_sig(const char *kernel, unsigned long kernel_len)
-{
- int ret;
-
- ret = verify_pefile_signature(kernel, kernel_len,
- VERIFY_USE_SECONDARY_KEYRING,
- VERIFYING_KEXEC_PE_SIGNATURE);
- if (ret == -ENOKEY && IS_ENABLED(CONFIG_INTEGRITY_PLATFORM_KEYRING)) {
- ret = verify_pefile_signature(kernel, kernel_len,
- VERIFY_USE_PLATFORM_KEYRING,
- VERIFYING_KEXEC_PE_SIGNATURE);
- }
- return ret;
-}
-#endif
-
const struct kexec_file_ops kexec_bzImage64_ops = {
.probe = bzImage64_probe,
.load = bzImage64_load,
.cleanup = bzImage64_cleanup,
#ifdef CONFIG_KEXEC_BZIMAGE_VERIFY_SIG
- .verify_sig = bzImage64_verify_sig,
+ .verify_sig = kexec_kernel_verify_pe_sig,
#endif
};
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -19,6 +19,7 @@
#include <asm/io.h>
#include <uapi/linux/kexec.h>
+#include <linux/verification.h>
/* Location of a reserved region to hold the crash kernel.
*/
@@ -212,6 +213,12 @@ static inline void *arch_kexec_kernel_im
}
#endif
+#ifdef CONFIG_KEXEC_SIG
+#ifdef CONFIG_SIGNED_PE_FILE_VERIFICATION
+int kexec_kernel_verify_pe_sig(const char *kernel, unsigned long kernel_len);
+#endif
+#endif
+
extern int kexec_add_buffer(struct kexec_buf *kbuf);
int kexec_locate_mem_hole(struct kexec_buf *kbuf);
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -123,6 +123,23 @@ void kimage_file_post_load_cleanup(struc
}
#ifdef CONFIG_KEXEC_SIG
+#ifdef CONFIG_SIGNED_PE_FILE_VERIFICATION
+int kexec_kernel_verify_pe_sig(const char *kernel, unsigned long kernel_len)
+{
+ int ret;
+
+ ret = verify_pefile_signature(kernel, kernel_len,
+ VERIFY_USE_SECONDARY_KEYRING,
+ VERIFYING_KEXEC_PE_SIGNATURE);
+ if (ret == -ENOKEY && IS_ENABLED(CONFIG_INTEGRITY_PLATFORM_KEYRING)) {
+ ret = verify_pefile_signature(kernel, kernel_len,
+ VERIFY_USE_PLATFORM_KEYRING,
+ VERIFYING_KEXEC_PE_SIGNATURE);
+ }
+ return ret;
+}
+#endif
+
static int kexec_image_verify_sig(struct kimage *image, void *buf,
unsigned long buf_len)
{
On 8/19/22 9:40 AM, Greg Kroah-Hartman wrote:
> -------------------
> NOTE, this is the LAST 5.18.y stable release. This tree will be
> end-of-life after this one. Please move to 5.19.y at this point in time
> or let us know why that is not possible.
> -------------------
>
> This is the start of the stable review cycle for the 5.18.19 release.
> There are 6 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun, 21 Aug 2022 15:36:59 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.18.19-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.18.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
Tested-by: Shuah Khan <[email protected]>
thanks,
-- Shuah
On Fri, 19 Aug 2022 at 21:10, Greg Kroah-Hartman
<[email protected]> wrote:
>
> -------------------
> NOTE, this is the LAST 5.18.y stable release. This tree will be
> end-of-life after this one. Please move to 5.19.y at this point in time
> or let us know why that is not possible.
> -------------------
>
> This is the start of the stable review cycle for the 5.18.19 release.
> There are 6 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun, 21 Aug 2022 15:36:59 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.18.19-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.18.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Results from Linaro's test farm.
No regressions on arm64, arm, x86_64, and i386.
Tested-by: Linux Kernel Functional Testing <[email protected]>
## Build
* kernel: 5.18.19-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.18.y
* git commit: f06dacf3d236cd8b16b2a869572c0e849f2aa156
* git describe: v5.18.18-7-gf06dacf3d236
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.18.y/build/v5.18.18-7-gf06dacf3d236
## No test Regressions (compared to v5.18.18)
## No metric Regressions (compared to v5.18.18)
## No test Fixes (compared to v5.18.18)
## No metric Fixes (compared to v5.18.18)
## Test result summary
total: 138885, pass: 123740, fail: 932, skip: 13421, xfail: 792
## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 313 total, 310 passed, 3 failed
* arm64: 76 total, 74 passed, 2 failed
* i386: 64 total, 58 passed, 6 failed
* mips: 50 total, 47 passed, 3 failed
* parisc: 14 total, 14 passed, 0 failed
* powerpc: 65 total, 56 passed, 9 failed
* riscv: 32 total, 27 passed, 5 failed
* s390: 23 total, 20 passed, 3 failed
* sh: 26 total, 24 passed, 2 failed
* sparc: 14 total, 14 passed, 0 failed
* x86_64: 69 total, 67 passed, 2 failed
## Test suites summary
* fwts
* igt-gpu-tools
* kunit
* kvm-unit-tests
* libgpiod
* libgpiod[
* libhugetlbfs
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-open-posix-tests
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* network-basic-tests
* packetdrill
* rcutorture
* ssuite
* v4l2-compliance
* vdso
--
Linaro LKFT
https://lkft.linaro.org
On 8/19/22 8:40 AM, Greg Kroah-Hartman wrote:
> -------------------
> NOTE, this is the LAST 5.18.y stable release. This tree will be
> end-of-life after this one. Please move to 5.19.y at this point in time
> or let us know why that is not possible.
> -------------------
>
> This is the start of the stable review cycle for the 5.18.19 release.
> There are 6 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun, 21 Aug 2022 15:36:59 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.18.19-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.18.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Tested-by: Ron Economos <[email protected]>
Hi Greg,
On Fri, Aug 19, 2022 at 05:40:12PM +0200, Greg Kroah-Hartman wrote:
> -------------------
> NOTE, this is the LAST 5.18.y stable release. This tree will be
> end-of-life after this one. Please move to 5.19.y at this point in time
> or let us know why that is not possible.
> -------------------
>
> This is the start of the stable review cycle for the 5.18.19 release.
> There are 6 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun, 21 Aug 2022 15:36:59 +0000.
> Anything received after that time might be too late.
Build test (gcc version 12.2.1 20220819):
mips: 59 configs -> 1 failure
arm: 99 configs -> no failure
arm64: 3 configs -> no failure
x86_64: 4 configs -> no failure
alpha allmodconfig -> no failure
csky allmodconfig -> fails
powerpc allmodconfig -> fais
riscv allmodconfig -> no failure
s390 allmodconfig -> no failure
xtensa allmodconfig -> no failure
Note:
csky and mips allmodconfig fails with gcc-12, passes with gcc-11.
Already reported for mainline.
powerpc failure is not seen in mainline. Same error as csky and mips.
In function 'memcmp',
inlined from 'bacmp' at ./include/net/bluetooth/bluetooth.h:302:9,
inlined from 'l2cap_global_chan_by_psm' at net/bluetooth/l2cap_core.c:2002:15:
./include/linux/fortify-string.h:44:33: error: '__builtin_memcmp' specified bound 6 exceeds source size 0 [-Werror=stringop-overread]
44 | #define __underlying_memcmp __builtin_memcmp
| ^
./include/linux/fortify-string.h:404:16: note: in expansion of macro '__underlying_memcmp'
404 | return __underlying_memcmp(p, q, size);
| ^~~~~~~~~~~~~~~~~~~
In function 'memcmp',
inlined from 'bacmp' at ./include/net/bluetooth/bluetooth.h:302:9,
inlined from 'l2cap_global_chan_by_psm' at net/bluetooth/l2cap_core.c:2003:15:
./include/linux/fortify-string.h:44:33: error: '__builtin_memcmp' specified bound 6 exceeds source size 0 [-Werror=stringop-overread]
44 | #define __underlying_memcmp __builtin_memcmp
| ^
./include/linux/fortify-string.h:404:16: note: in expansion of macro '__underlying_memcmp'
404 | return __underlying_memcmp(p, q, size);
| ^~~~~~~~~~~~~~~~~~~
I am bisecting now to find out what caused it.
Boot test:
x86_64: Booted on my test laptop. No regression.
x86_64: Booted on qemu. No regression. [1]
mips: Booted on ci20 board. No regression. [2]
[1]. https://openqa.qa.codethink.co.uk/tests/1660
[2]. https://openqa.qa.codethink.co.uk/tests/1667
Tested-by: Sudip Mukherjee <[email protected]>
--
Regards
Sudip
On Sat, Aug 20, 2022 at 11:03 AM Sudip Mukherjee (Codethink)
<[email protected]> wrote:
>
> Hi Greg,
>
> On Fri, Aug 19, 2022 at 05:40:12PM +0200, Greg Kroah-Hartman wrote:
> > -------------------
> > NOTE, this is the LAST 5.18.y stable release. This tree will be
> > end-of-life after this one. Please move to 5.19.y at this point in time
> > or let us know why that is not possible.
> > -------------------
> >
> > This is the start of the stable review cycle for the 5.18.19 release.
> > There are 6 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sun, 21 Aug 2022 15:36:59 +0000.
> > Anything received after that time might be too late.
>
<snip>
>
> powerpc failure is not seen in mainline. Same error as csky and mips.
>
> In function 'memcmp',
> inlined from 'bacmp' at ./include/net/bluetooth/bluetooth.h:302:9,
> inlined from 'l2cap_global_chan_by_psm' at net/bluetooth/l2cap_core.c:2002:15:
> ./include/linux/fortify-string.h:44:33: error: '__builtin_memcmp' specified bound 6 exceeds source size 0 [-Werror=stringop-overread]
> 44 | #define __underlying_memcmp __builtin_memcmp
> | ^
> ./include/linux/fortify-string.h:404:16: note: in expansion of macro '__underlying_memcmp'
> 404 | return __underlying_memcmp(p, q, size);
> | ^~~~~~~~~~~~~~~~~~~
> In function 'memcmp',
> inlined from 'bacmp' at ./include/net/bluetooth/bluetooth.h:302:9,
> inlined from 'l2cap_global_chan_by_psm' at net/bluetooth/l2cap_core.c:2003:15:
> ./include/linux/fortify-string.h:44:33: error: '__builtin_memcmp' specified bound 6 exceeds source size 0 [-Werror=stringop-overread]
> 44 | #define __underlying_memcmp __builtin_memcmp
> | ^
> ./include/linux/fortify-string.h:404:16: note: in expansion of macro '__underlying_memcmp'
> 404 | return __underlying_memcmp(p, q, size);
> | ^~~~~~~~~~~~~~~~~~~
>
> I am bisecting now to find out what caused it.
Introduced in v5.18.18 due to 11e008e59970 ("Bluetooth: L2CAP: Fix
l2cap_global_chan_by_psm regression").
But v5.19.y and mainline does not show the build failure as they also
have 41b7a347bf14 ("powerpc: Book3S 64-bit outline-only KASAN
support").
--
Regards
Sudip
On Fri, Aug 19, 2022 at 05:40:12PM +0200, Greg Kroah-Hartman wrote:
> -------------------
> NOTE, this is the LAST 5.18.y stable release. This tree will be
> end-of-life after this one. Please move to 5.19.y at this point in time
> or let us know why that is not possible.
> -------------------
>
> This is the start of the stable review cycle for the 5.18.19 release.
> There are 6 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun, 21 Aug 2022 15:36:59 +0000.
> Anything received after that time might be too late.
>
Build results:
total: 154 pass: 154 fail: 0
Qemu test results:
total: 487 pass: 486 fail: 1
Failed tests:
arm:bletchley-bmc:aspeed_g5_defconfig:notests:usb0:net,nic:aspeed-bmc-facebook-bletchley:rootfs
No new failures. As with v5.15.y, I did not receive this e-mail and had
to copy it from lore instead.
Tested-by: Guenter Roeck <[email protected]>
Guenter
On Sat, Aug 20, 2022 at 11:32:36AM +0100, Sudip Mukherjee wrote:
> On Sat, Aug 20, 2022 at 11:03 AM Sudip Mukherjee (Codethink)
> <[email protected]> wrote:
> >
> > Hi Greg,
> >
> > On Fri, Aug 19, 2022 at 05:40:12PM +0200, Greg Kroah-Hartman wrote:
> > > -------------------
> > > NOTE, this is the LAST 5.18.y stable release. This tree will be
> > > end-of-life after this one. Please move to 5.19.y at this point in time
> > > or let us know why that is not possible.
> > > -------------------
> > >
> > > This is the start of the stable review cycle for the 5.18.19 release.
> > > There are 6 patches in this series, all will be posted as a response
> > > to this one. If anyone has any issues with these being applied, please
> > > let me know.
> > >
> > > Responses should be made by Sun, 21 Aug 2022 15:36:59 +0000.
> > > Anything received after that time might be too late.
> >
>
> <snip>
>
> >
> > powerpc failure is not seen in mainline. Same error as csky and mips.
> >
> > In function 'memcmp',
> > inlined from 'bacmp' at ./include/net/bluetooth/bluetooth.h:302:9,
> > inlined from 'l2cap_global_chan_by_psm' at net/bluetooth/l2cap_core.c:2002:15:
> > ./include/linux/fortify-string.h:44:33: error: '__builtin_memcmp' specified bound 6 exceeds source size 0 [-Werror=stringop-overread]
> > 44 | #define __underlying_memcmp __builtin_memcmp
> > | ^
> > ./include/linux/fortify-string.h:404:16: note: in expansion of macro '__underlying_memcmp'
> > 404 | return __underlying_memcmp(p, q, size);
> > | ^~~~~~~~~~~~~~~~~~~
> > In function 'memcmp',
> > inlined from 'bacmp' at ./include/net/bluetooth/bluetooth.h:302:9,
> > inlined from 'l2cap_global_chan_by_psm' at net/bluetooth/l2cap_core.c:2003:15:
> > ./include/linux/fortify-string.h:44:33: error: '__builtin_memcmp' specified bound 6 exceeds source size 0 [-Werror=stringop-overread]
> > 44 | #define __underlying_memcmp __builtin_memcmp
> > | ^
> > ./include/linux/fortify-string.h:404:16: note: in expansion of macro '__underlying_memcmp'
> > 404 | return __underlying_memcmp(p, q, size);
> > | ^~~~~~~~~~~~~~~~~~~
> >
> > I am bisecting now to find out what caused it.
>
> Introduced in v5.18.18 due to 11e008e59970 ("Bluetooth: L2CAP: Fix
> l2cap_global_chan_by_psm regression").
> But v5.19.y and mainline does not show the build failure as they also
> have 41b7a347bf14 ("powerpc: Book3S 64-bit outline-only KASAN
> support").
Ick, that's a mess. This is going to be the last 5.18 tree, so I'm just
going to leave this alone...
thanks,
greg k-h