From nobody Tue Dec 2 02:33:25 2025 Received: from mail-io1-f71.google.com (mail-io1-f71.google.com [209.85.166.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5D0C1311950 for ; Wed, 19 Nov 2025 05:51:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.166.71 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763531490; cv=none; b=QULA48P54c7wJiHY3DKc08S3KVfXTEBBYZKJMWkHMW172wBy526TPj+iKVO9vZobzDkDXLPi6f3qVbuBfedVBE9SjgFTcprKxH7NDdOImGDp1Z9WJXe0nZFeny/k5p9Br1xXm4xpgmcUih4L2lsnEiKXScFqcw/4Ha4T/ni7uiI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763531490; c=relaxed/simple; bh=B8ex4X76A+oYgbzeLpUY24G1UvzWb5O8yZBBfNcFu9g=; h=MIME-Version:Date:In-Reply-To:Message-ID:Subject:From:To: Content-Type; b=EQUsap3wLw44mHBNSN/cCMgEQV9g1RhQFlnq6O6r4xqvJ0HE5m+THcMlaTxulmrCnZ24KcFnDNGIACWXxeZr096+e8uCcqE0XxAU+braTFZFVZ1gmzBFqJqQ+ryQYgxFaxvIEzpIFicWyKGrLmVjdylRAXCwUfAZIC8SYBvgLEM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com; arc=none smtp.client-ip=209.85.166.71 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com Received: by mail-io1-f71.google.com with SMTP id ca18e2360f4ac-9434f5350bcso45324039f.1 for ; Tue, 18 Nov 2025 21:51:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763531487; x=1764136287; h=to:from:subject:message-id:in-reply-to:date:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=DDw2L3oBCepxfF4IXbJj/vI83/rg2KLfstyXexNI8cg=; b=EAnljD3CHEkLTaJX/1HsJl+n6e0BWwIbCxYwHOfNB08LNFPXNCcFHWthnzGoi8KGZG a3meG0ctgpSZFheyacoWu6DCx43tRzTQ1h6H26L47lzziCc4o9DLGD8uPuxQ8tU/gQDa UZTbnWDIFGZYfC+QgksnvkbD/LYsTAuOAS/IFq4Yiek9tyBVnFX9YQE1Xtdsf4B0eS35 DBqJEZMm04/5DFu6O9MwPl8NpJhBLHLzDAWSyZwTU49N8dKjrIl6J6WhSll05Cen1qqp SrSM+XUNHvtEakH7T63aTF2sgYDt1n1BjNKkRb4cH/3mL2/rB4EB7DVD6xA4wfb9m1tP VRBg== X-Gm-Message-State: AOJu0Yx+qxZLDMiaNyixzvEpGYYUhlett7oCu7tLYmOOSc70MGIqCzJy dUp8TbqhzgzOhnLBJK84TpNgFNCwP/vInM5J+Nz6YCEh5eDkImc8RKP1n6N8qaY5xuzw625Udg3 MYVlKQqmgGCKLprDb/Z0BxVenGhUDAacX/ElTrOwmkPWqcXYAIl5HGVtKJyg= X-Google-Smtp-Source: AGHT+IEq3zfxVInXiUr3F3LOYpMxfdqE4L+WBzqr4whcdBQMP1LCcI/7L5EpMMuj6OeR2bxc6KwUd1PGs12RdKO7s2a5tCCqGB0g Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Received: by 2002:a05:6602:1849:b0:949:55d:4a41 with SMTP id ca18e2360f4ac-9492bce82ecmr123070939f.7.1763531487551; Tue, 18 Nov 2025 21:51:27 -0800 (PST) Date: Tue, 18 Nov 2025 21:51:27 -0800 In-Reply-To: <69136cdb.a70a0220.22f260.0142.GAE@google.com> X-Google-Appengine-App-Id: s~syzkaller X-Google-Appengine-App-Id-Alias: syzkaller Message-ID: <691d5adf.a70a0220.d98e3.0008.GAE@google.com> Subject: Forwarded: [PATCH] tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs From: syzbot To: linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" For archival purposes, forwarding an incoming command email to linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com. *** Subject: [PATCH] tracing: Fix WARN_ON in tracing_buffers_mmap_close for spl= it VMAs Author: kartikey406@gmail.com #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git= master When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Fix this by handling -ENODEV gracefully in tracing_buffers_mmap_close(). When ring_buffer_unmap() returns -ENODEV, it means this VMA was a split portion that doesn't hold a reference, so simply return without calling put_snapshot_map(). Closes: https://syzkaller.appspot.com/bug?extid=3Da72c325b042aae6403c7 Reported-by: syzbot+a72c325b042aae6403c7@syzkaller.appspotmail.com Signed-off-by: Deepanshu Kartikey --- kernel/trace/trace.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index d1e527cf2aae..fe593dd2c387 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -8776,8 +8776,17 @@ static void tracing_buffers_mmap_close(struct vm_are= a_struct *vma) { struct ftrace_buffer_info *info =3D vma->vm_file->private_data; struct trace_iterator *iter =3D &info->iter; + int ret; =20 - WARN_ON(ring_buffer_unmap(iter->array_buffer->buffer, iter->cpu_file)); + ret =3D ring_buffer_unmap(iter->array_buffer->buffer, iter->cpu_file); + if (ret =3D=3D -ENODEV) { + /* + * This VMA was split from the original mapping. Since + * ring buffer mappings do not support partial mappings, + * the split VMA does not hold a reference. + */ + return; + } put_snapshot_map(iter->tr); } =20 --=20 2.43.0