Message-ID: <CAJfuBxzRpKLqgSbjEvBJuOFdjb+nrF-REiBA0o1myZ++Z9bnDA@mail.gmail.com>
Date: Thu, 19 Dec 2024 14:33:31 -0500
From: jim.cromie@...il.com
To: Muni Sekhar <munisekharrms@...il.com>
Cc: kernel-hardening@...ts.openwall.com, 
	kasan-dev <kasan-dev@...glegroups.com>, LKML <linux-kernel@...r.kernel.org>, 
	kernelnewbies <kernelnewbies@...nelnewbies.org>
Subject: Re: Help Needed: Debugging Memory Corruption results GPF

Can you run this in a KVM ?

My go-to is virtme-ng, where I can run my hacks on my laptop,
in its own VM - on a copy of my whole system.
with the tools I'm familiar with.

then you can attach gdb to the VM.

then Id try a watchpoint on the memory.


On Fri, Nov 15, 2024 at 11:19 AM Muni Sekhar <munisekharrms@...il.com> wrote:
>
> Hi all,
>
> I am encountering a memory corruption issue in the function
> msm_set_laddr() from the Slimbus MSM Controller driver source code.
> https://android.googlesource.com/kernel/msm/+/refs/heads/android-msm-sunfish-4.14-android12/drivers/slimbus/slim-msm-ctrl.c
>
> In msm_set_laddr(), one of the arguments is ea (enumeration address),
> which is a pointer to constant data. While testing, I observed strange
> behavior:
>
> The contents of the ea buffer get corrupted during a timeout scenario
> in the call to:
>
> timeout = wait_for_completion_timeout(&done, HZ);
>
> Specifically, the ea buffer's contents differ before and after the
> wait_for_completion_timeout() call, even though it's declared as a
> pointer to constant data (const u8 *ea).
> To debug this issue, I enabled KASAN, but it didn't reveal any memory
> corruption. After the buffer corruption, random memory allocations in
> other parts of the kernel occasionally result in a GPF crash.
>
> Here is the relevant part of the code:
>
> static int msm_set_laddr(struct slim_controller *ctrl, const u8 *ea,
>                          u8 elen, u8 laddr)
> {
>     struct msm_slim_ctrl *dev = slim_get_ctrldata(ctrl);
>     struct completion done;
>     int timeout, ret, retries = 0;
>     u32 *buf;
> retry_laddr:
>     init_completion(&done);
>     mutex_lock(&dev->tx_lock);
>     buf = msm_get_msg_buf(dev, 9, &done);
>     if (buf == NULL)
>         return -ENOMEM;
>     buf[0] = SLIM_MSG_ASM_FIRST_WORD(9, SLIM_MSG_MT_CORE,
>                                      SLIM_MSG_MC_ASSIGN_LOGICAL_ADDRESS,
>                                      SLIM_MSG_DEST_LOGICALADDR,
>                                      ea[5] | ea[4] << 8);
>     buf[1] = ea[3] | (ea[2] << 8) | (ea[1] << 16) | (ea[0] << 24);
>     buf[2] = laddr;
>     ret = msm_send_msg_buf(dev, buf, 9, MGR_TX_MSG);
>     timeout = wait_for_completion_timeout(&done, HZ);
>     if (!timeout)
>         dev->err = -ETIMEDOUT;
>     if (dev->err) {
>         ret = dev->err;
>         dev->err = 0;
>     }
>     mutex_unlock(&dev->tx_lock);
>     if (ret) {
>         pr_err("set LADDR:0x%x failed:ret:%d, retrying", laddr, ret);
>         if (retries < INIT_MX_RETRIES) {
>             msm_slim_wait_retry(dev);
>             retries++;
>             goto retry_laddr;
>         } else {
>             pr_err("set LADDR failed after retrying:ret:%d", ret);
>         }
>     }
>     return ret;
> }
>
> What I've Tried:
> KASAN: Enabled it but couldn't identify the source of the corruption.
> Debugging Logs: Added logs to print the ea contents before and after
> the wait_for_completion_timeout() call. The logs show a mismatch in
> the data.
>
> Question:
> How can I efficiently trace the source of the memory corruption in
> this scenario?
> Could wait_for_completion_timeout() or a related function cause
> unintended side effects?
> Are there additional tools or techniques (e.g., dynamic debugging or
> specific kernel config options) that can help identify this
> corruption?
> Any insights or suggestions would be greatly appreciated!
>
>
>
> --
> Thanks,
> Sekhar
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@...nelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Powered by blists - more mailing lists