Hi,
I notice a regression report on Bugzilla [1]. Quoting from it:
> Null pointer deref
>
> after reverting 326e1c208f3f24d14b93f910b8ae32c94923d22c the problem is gone and the kernel does not crash anymore
>
> See this discussion for details:
>
> https://bbs.archlinux.org/viewtopic.php?pid=2102715#p2102715
>
See Bugzilla for the full thread and attached journal log.
On the other hand, from linked Archlinux forum link:
> Hi,
>
> I am running arch successfully since a couple of years on my Acer ConceptD 7 laptop. Since a kernel update on 24th of May I am having strange issues (never seen this before):
>
> - sometimes I cannot even login (using gdm) - after entering password just a blank screen
> - if I can login I can start working - after a while commands I enter in the console are accepted but do nothing (i.e. grub-mkconfig -o ..... can enter the command but just no output - it does nothing - happens with most other command then as well....)
> - Reboot does not work - stuck somewhere - have to switch the machine off the hard way
> - this happens even when entering runlevel 3 (so no window manager)
> - same happens on the laptop of a friend (exact same model) - unfortunately I have no other piece of hardware which I could use for testing to potentially reproduce the problem
>
> Managed to trace this down to all kernels after 6.3.3.arch1-1 - so 6.3.3.arch1-1 it the last one which works without any problems
> Same applies for the LTS kernels - not 100% sure but think 6.1.29 ist the last one which works
>
> Currently I have marked linux linux-headers and nvidia to not upgrade. LTS kernels are upgraded but the latest two kernels (latest from today) up until 6.1.31-1 do NOT work
>
> Problem: Since most of the command fail when using one of the latest kernel - it is almost impossible to debug - at least I am not knowledgable enough to know where to look.
Anyway, I'm adding it to regzbot:
#regzbot introduced: 326e1c208f3f24 https://bugzilla.kernel.org/show_bug.cgi?id=217517
#regzbot title: USB typec quirk for Asus Zenbook UM325 triggers system freeze on Acer ConceptD 7
#regzbot link: https://bbs.archlinux.org/viewtopic.php?pid=2102715
Thanks.
[1]: https://bugzilla.kernel.org/show_bug.cgi?id=217517
--
An old man doll... just what I always wanted! - Clara
Currently the offset into the device when looking for OTP
bits can go outside of the address of the MTD NOR devices,
and if that memory isn't readable, bad things happen
on the IXP4xx (added prints that illustrate the problem before
the crash):
cfi_intelext_otp_walk walk OTP on chip 0 start at reg_prot_offset 0x00000100
ixp4xx_copy_from copy from 0x00000100 to 0xc880dd78
cfi_intelext_otp_walk walk OTP on chip 0 start at reg_prot_offset 0x12000000
ixp4xx_copy_from copy from 0x12000000 to 0xc880dd78
8<--- cut here ---
Unable to handle kernel paging request at virtual address db000000
[db000000] *pgd=00000000
(...)
This happens in this case because the IXP4xx is big endian and
the 32- and 16-bit fields in the struct cfi_intelext_otpinfo are not
properly byteswapped. Compare to how the code in read_pri_intelext()
byteswaps the fields in struct cfi_pri_intelext.
Adding some byte swapping after casting the &extp->extra[0] into
a struct cfi_intelext_otpinfo * pointer, and the crash goes away.
The problem went unnoticed for many years until I enabled
CONFIG_MTD_OTP on the IXP4xx as well, triggering the bug.
Cc: Nicolas Pitre <npitre(a)baylibre.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
---
ChangeLog v1->v2:
- Drill deeper and discover a big endian compatibility issue.
---
drivers/mtd/chips/cfi_cmdset_0001.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c b/drivers/mtd/chips/cfi_cmdset_0001.c
index 54f92d09d9cf..7603b0052a16 100644
--- a/drivers/mtd/chips/cfi_cmdset_0001.c
+++ b/drivers/mtd/chips/cfi_cmdset_0001.c
@@ -2336,6 +2336,11 @@ static int cfi_intelext_otp_walk(struct mtd_info *mtd, loff_t from, size_t len,
chip = &cfi->chips[chip_num];
otp = (struct cfi_intelext_otpinfo *)&extp->extra[0];
+ /* Do some byteswapping if necessary */
+ otp->ProtRegAddr = le32_to_cpu(otp->ProtRegAddr);
+ otp->FactGroups = le16_to_cpu(otp->FactGroups);
+ otp->UserGroups = le16_to_cpu(otp->UserGroups);
+
/* first OTP region */
field = 0;
reg_prot_offset = extp->ProtRegAddr;
--
2.40.1
Especially on 32-bit systems, it is possible for the pointer arithmetic
to overflow and cause a userspace pointer to be dereferenced in the
kernel.
Signed-off-by: Demi Marie Obenour <demi(a)invisiblethingslab.com>
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable(a)vger.kernel.org
---
drivers/md/dm-ioctl.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c
index 34fa74c6a70db8aa67aaba3f6a2fc4f38ef736bc..64e8f16d344c47057de5e2d29e3d63202197dca0 100644
--- a/drivers/md/dm-ioctl.c
+++ b/drivers/md/dm-ioctl.c
@@ -1396,6 +1396,25 @@ static int next_target(struct dm_target_spec *last, uint32_t next, void *end,
{
static_assert(_Alignof(struct dm_target_spec) <= 8,
"struct dm_target_spec has excessive alignment requirements");
+ static_assert(offsetof(struct dm_ioctl, data) >= sizeof(struct dm_target_spec),
+ "struct dm_target_spec too big");
+
+ /*
+ * Number of bytes remaining, starting with last. This is always
+ * sizeof(struct dm_target_spec) or more, as otherwise *last was
+ * out of bounds already.
+ */
+ size_t remaining = (char *)end - (char *)last;
+
+ /*
+ * There must be room for both the next target spec and the
+ * NUL-terminator of the target itself.
+ */
+ if (remaining - sizeof(struct dm_target_spec) <= next) {
+ DMERR("Target spec extends beyond end of parameters");
+ return -EINVAL;
+ }
+
if (next % 8) {
DMERR("Next target spec (offset %u) is not 8-byte aligned", next);
return -EINVAL;
--
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab