Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33;
From:   Lizhi Xu <lizhi.xu@windriver.com>
To:     <syzbot+8a78ecea7ac1a2ea26e5@syzkaller.appspotmail.com>
CC:     <davem@davemloft.net>, <linux-kernel@vger.kernel.org>,
        <netdev@vger.kernel.org>, <reibax@gmail.com>,
        <richardcochran@gmail.com>, <rrameshbabu@nvidia.com>,
        <syzkaller-bugs@googlegroups.com>
Subject: [PATCH] ptp: fix null ptr deref in ptp_ioctrl
Date:   Mon, 6 Nov 2023 09:19:26 +0800
Message-ID: <20231106011926.2928881-1-lizhi.xu@windriver.com>
In-Reply-To: <000000000000e7b62806096c7d67@google.com>
References: <000000000000e7b62806096c7d67@google.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Precedence: bulk

In the logs recorded in the strace log,
https://syzkaller.appspot.com/text?tag=CrashLog&x=11aa125f680000
...
openat(AT_FDCWD, "/dev/ptp0", O_RDONLY) = 3
read(3, 0x20000080, 90)                 = -1 EINVAL (Invalid argument)
general protection fault, probably for non-canonical address 0xdffffc000000020b: 0000 [#1] PREEMPT SMP KASAN
KASAN: probably user-memory-access in range [0x0000000000001058-0x000000000000105f]
CPU: 0 PID: 5053 Comm: syz-executor353 Not tainted 6.6.0-syzkaller-10396-g4652b8e4f3ff #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023
RIP: 0010:ptp_ioctl+0xcb7/0x1d10
Code: 81 fe 13 3d 00 00 0f 85 9c 02 00 00 e8 c2 83 23 fa 49 8d bc 24 58 10 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 dc 0e 00 00 49 8b bc 24 58 10 00 00 ba 00 01 00
RSP: 0018:ffffc90003a37ba0 EFLAGS: 00010212
RAX: dffffc0000000000 RBX: ffff88814a78a000 RCX: ffffffff8764f81f
RDX: 000000000000020b RSI: ffffffff8765028e RDI: 0000000000001058
RBP: ffffc90003a37ec0 R08: 0000000000000005 R09: ffffc90003a37c40
R10: 0000000000003d13 R11: 0000000000000000 R12: 0000000000000000
R13: ffffc90003a37c80 R14: 0000000000003d13 R15: ffffffff92ac78e8
FS:  00005555569a9380(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000040 CR3: 0000000076e09000 CR4: 0000000000350ef0
Call Trace:
 <TASK>
 ? show_regs+0x8f/0xa0
 ? die_addr+0x4f/0xd0
 ? exc_general_protection+0x154/0x230
 ? asm_exc_general_protection+0x26/0x30
 ? ptp_ioctl+0x22f/0x1d10
 ? ptp_ioctl+0xc9e/0x1d10
 ? ptp_ioctl+0xcb7/0x1d10
 ? ptp_release+0x2b0/0x2b0
 ? lockdep_hardirqs_on_prepare+0x410/0x410
 ? lock_sync+0x190/0x190
 ? find_held_lock+0x2d/0x110
 ? ptp_release+0x2b0/0x2b0
 posix_clock_ioctl+0xf8/0x160
...

It can be confirmed that after the execution of "read (3, 0x20000080, 90)",
ptp_release() will be called to release the queue and set
pccontext->private_clkdata = NULL at the same time, this is unreasonable and
incorrect. The queue is not the memory requested in ptp_read() and should not
be released in ptp_read().

Signed-off-by: Lizhi Xu <lizhi.xu@windriver.com>
---
 drivers/ptp/ptp_chardev.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/ptp/ptp_chardev.c b/drivers/ptp/ptp_chardev.c
index 282cd7d24077..27c1ef493617 100644
--- a/drivers/ptp/ptp_chardev.c
+++ b/drivers/ptp/ptp_chardev.c
@@ -585,7 +585,5 @@ ssize_t ptp_read(struct posix_clock_context *pccontext, uint rdflags,
 free_event:
 	kfree(event);
 exit:
-	if (result < 0)
-		ptp_release(pccontext);
 	return result;
 }
-- 
2.25.1