[<prev] [<thread-prev] [day] [month] [year] [list]
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
