From: "Weiming Shi" <bestswngs@gmail.com>
To: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Weiming Shi" <bestswngs@gmail.com>
Cc: "Jiri Slaby" <jirislaby@kernel.org>,
<linux-kernel@vger.kernel.org>, <linux-serial@vger.kernel.org>,
"Xiang Mei" <xmei5@asu.edu>
Subject: Re: [PATCH] tty: serial: core: fix NULL pointer deref in uart_resume_port()
Date: Sat, 13 Jun 2026 13:37:36 +0800 [thread overview]
Message-ID: <DJ7OG7DECH0U.NUGR9GOP7EP2@gmail.com> (raw)
In-Reply-To: <2026061238-utmost-amusement-4664@gregkh>
On Fri Jun 12, 2026 at 6:01 PM CST, Greg Kroah-Hartman wrote:
> On Mon, Jun 08, 2026 at 09:52:17AM -0700, Weiming Shi wrote:
>> uart_resume_port() looks up the tty device child with device_find_child()
>> and passes the result straight to device_may_wakeup(). device_find_child()
>> returns NULL when the port has no matching tty device child,
>
> How can that happen in a real system? Have you triggered this before,
> if so, what hardware does it?
>
>> and
>> device_may_wakeup() dereferences dev->power.can_wakeup, so a NULL tty_dev
>> faults. uart_suspend_port() already guards the same call with
>> "tty_dev && device_may_wakeup(tty_dev)"; the resume path does not.
>>
>> Oops: general protection fault, probably for non-canonical address
>> KASAN: null-ptr-deref in range [0x148-0x14f]
>> RIP: 0010:uart_resume_port (pm_wakeup.h:84 serial_core.c:2477)
>> serial_pnp_resume (8250/8250_pnp.c:522)
>> pnp_bus_resume (drivers/pnp/driver.c:234)
>
> Is this a real oops, or a made up one?
>
>> Mirror the NULL guard from uart_suspend_port(). put_device(tty_dev)
>> already tolerates a NULL argument, so only the device_may_wakeup() call
>> needs the check; the non-NULL path is unchanged.
>>
>> Fixes: b3b708fa2780 ("wake up from a serial port")
>> Reported-by: Xiang Mei <xmei5@asu.edu>
>
> Where was this reported?
>
> Why isn't this cc: stable? And why hasn't anyone tripped over it in the
> past 19 years?
>
> thanks,
>
> greg k-h
Hi greg,
This is a false positive, please drop it.
Sorry for wasting your time. I'll check reachability before sending anything next time.
Best,
Weiming Shi
prev parent reply other threads:[~2026-06-13 5:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-08 16:52 [PATCH] tty: serial: core: fix NULL pointer deref in uart_resume_port() Weiming Shi
2026-06-12 10:01 ` Greg Kroah-Hartman
2026-06-13 5:37 ` Weiming Shi [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DJ7OG7DECH0U.NUGR9GOP7EP2@gmail.com \
--to=bestswngs@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=xmei5@asu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.