<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/usb/mon, branch linux-6.9.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.9.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.9.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2024-01-05T09:36:08Z</updated>
<entry>
<title>usb: mon: Fix atomicity violation in mon_bin_vma_fault</title>
<updated>2024-01-05T09:36:08Z</updated>
<author>
<name>Gui-Dong Han</name>
<email>2045gemini@gmail.com</email>
</author>
<published>2024-01-05T05:24:12Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=2dd23cc4d0e6aa55cf9fb3b05f2f4165b01de81c'/>
<id>urn:sha1:2dd23cc4d0e6aa55cf9fb3b05f2f4165b01de81c</id>
<content type='text'>
In mon_bin_vma_fault():
    offset = vmf-&gt;pgoff &lt;&lt; PAGE_SHIFT;
    if (offset &gt;= rp-&gt;b_size)
        return VM_FAULT_SIGBUS;
    chunk_idx = offset / CHUNK_SIZE;
    pageptr = rp-&gt;b_vec[chunk_idx].pg;
The code is executed without holding any lock.

In mon_bin_vma_close():
    spin_lock_irqsave(&amp;rp-&gt;b_lock, flags);
    rp-&gt;mmap_active--;
    spin_unlock_irqrestore(&amp;rp-&gt;b_lock, flags);

In mon_bin_ioctl():
    spin_lock_irqsave(&amp;rp-&gt;b_lock, flags);
    if (rp-&gt;mmap_active) {
        ...
    } else {
        ...
        kfree(rp-&gt;b_vec);
        rp-&gt;b_vec  = vec;
        rp-&gt;b_size = size;
        ...
    }
    spin_unlock_irqrestore(&amp;rp-&gt;b_lock, flags);

Concurrent execution of mon_bin_vma_fault() with mon_bin_vma_close() and
mon_bin_ioctl() could lead to atomicity violations. mon_bin_vma_fault()
accesses rp-&gt;b_size and rp-&gt;b_vec without locking, risking array
out-of-bounds access or use-after-free bugs due to possible modifications
in mon_bin_ioctl().

This possible bug is found by an experimental static analysis tool
developed by our team, BassCheck[1]. This tool analyzes the locking APIs
to extract function pairs that can be concurrently executed, and then
analyzes the instructions in the paired functions to identify possible
concurrency bugs including data races and atomicity violations. The above
possible bug is reported when our tool analyzes the source code of
Linux 6.2.

To address this issue, it is proposed to add a spin lock pair in
mon_bin_vma_fault() to ensure atomicity. With this patch applied, our tool
never reports the possible bug, with the kernel configuration allyesconfig
for x86_64. Due to the lack of associated hardware, we cannot test the
patch in runtime testing, and just verify it according to the code logic.

[1] https://sites.google.com/view/basscheck/

Fixes: 19e6317d24c2 ("usb: mon: Fix a deadlock in usbmon between ...")
Cc:  &lt;stable@vger.kernel.org&gt;
Signed-off-by: Gui-Dong Han &lt;2045gemini@gmail.com&gt;
Link: https://lore.kernel.org/r/20240105052412.9377-1-2045gemini@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: mon_text: Replace snprintf() with the safer scnprintf() variant</title>
<updated>2023-12-15T12:55:30Z</updated>
<author>
<name>Lee Jones</name>
<email>lee@kernel.org</email>
</author>
<published>2023-12-13T16:42:39Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=9d4e3d15d7bf3439a6f3fb4aafc4f92ea2c5c5fd'/>
<id>urn:sha1:9d4e3d15d7bf3439a6f3fb4aafc4f92ea2c5c5fd</id>
<content type='text'>
There is a general misunderstanding amongst engineers that {v}snprintf()
returns the length of the data *actually* encoded into the destination
array.  However, as per the C99 standard {v}snprintf() really returns
the length of the data that *would have been* written if there were
enough space for it.  This misunderstanding has led to buffer-overruns
in the past.  It's generally considered safer to use the {v}scnprintf()
variants in their place (or even sprintf() in simple cases).  So let's
do that.

Link: https://lwn.net/Articles/69419/
Link: https://github.com/KSPP/linux/issues/105
Signed-off-by: Lee Jones &lt;lee@kernel.org&gt;
Link: https://lore.kernel.org/r/20231213164246.1021885-11-lee@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: mon_stat: Replace snprintf() with the safer scnprintf() variant</title>
<updated>2023-12-15T12:55:30Z</updated>
<author>
<name>Lee Jones</name>
<email>lee@kernel.org</email>
</author>
<published>2023-12-13T16:42:38Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=79632569619f4d57ff745398dba98e09105b5108'/>
<id>urn:sha1:79632569619f4d57ff745398dba98e09105b5108</id>
<content type='text'>
There is a general misunderstanding amongst engineers that {v}snprintf()
returns the length of the data *actually* encoded into the destination
array.  However, as per the C99 standard {v}snprintf() really returns
the length of the data that *would have been* written if there were
enough space for it.  This misunderstanding has led to buffer-overruns
in the past.  It's generally considered safer to use the {v}scnprintf()
variants in their place (or even sprintf() in simple cases).  So let's
do that.

Link: https://lwn.net/Articles/69419/
Link: https://github.com/KSPP/linux/issues/105
Signed-off-by: Lee Jones &lt;lee@kernel.org&gt;
Link: https://lore.kernel.org/r/20231213164246.1021885-10-lee@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usbmon: Use list_for_each_entry() helper</title>
<updated>2023-10-02T14:19:01Z</updated>
<author>
<name>Jinjie Ruan</name>
<email>ruanjinjie@huawei.com</email>
</author>
<published>2023-08-30T08:56:58Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=80920e21269265fd6fc5abf825af77ea2d100c8a'/>
<id>urn:sha1:80920e21269265fd6fc5abf825af77ea2d100c8a</id>
<content type='text'>
Convert list_for_each() to list_for_each_entry() so that the p/pos
list_head pointer and list_entry() call are no longer needed, which
can reduce a few lines of code. No functional changed.

Signed-off-by: Jinjie Ruan &lt;ruanjinjie@huawei.com&gt;
Link: https://lore.kernel.org/r/20230830085658.527752-1-ruanjinjie@huawei.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>USB: mon: make mon_bin_class a static const structure</title>
<updated>2023-06-20T14:20:45Z</updated>
<author>
<name>Ivan Orlov</name>
<email>ivan.orlov0322@gmail.com</email>
</author>
<published>2023-06-20T09:44:15Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=e571e843f0ce005503471707fa02e892ba2a6f35'/>
<id>urn:sha1:e571e843f0ce005503471707fa02e892ba2a6f35</id>
<content type='text'>
Now that the driver core allows for struct class to be in read-only
memory, move the mon_bin_class structure to be declared at build time
placing it into read-only memory, instead of having to be dynamically
allocated at load time.

Suggested-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Ivan Orlov &lt;ivan.orlov0322@gmail.com&gt;
Link: https://lore.kernel.org/r/20230620094412.508580-9-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>driver core: class: remove module * from class_create()</title>
<updated>2023-03-17T14:16:33Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2023-03-13T18:18:35Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=1aaba11da9aa7d7d6b52a74d45b31cac118295a1'/>
<id>urn:sha1:1aaba11da9aa7d7d6b52a74d45b31cac118295a1</id>
<content type='text'>
The module pointer in class_create() never actually did anything, and it
shouldn't have been requred to be set as a parameter even if it did
something.  So just remove it and fix up all callers of the function in
the kernel tree at the same time.

Cc: "Rafael J. Wysocki" &lt;rafael@kernel.org&gt;
Acked-by: Benjamin Tissoires &lt;benjamin.tissoires@redhat.com&gt;
Link: https://lore.kernel.org/r/20230313181843.1207845-4-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mm: replace vma-&gt;vm_flags direct modifications with modifier calls</title>
<updated>2023-02-10T00:51:39Z</updated>
<author>
<name>Suren Baghdasaryan</name>
<email>surenb@google.com</email>
</author>
<published>2023-01-26T19:37:49Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=1c71222e5f2393b5ea1a41795c67589eea7e3490'/>
<id>urn:sha1:1c71222e5f2393b5ea1a41795c67589eea7e3490</id>
<content type='text'>
Replace direct modifications to vma-&gt;vm_flags with calls to modifier
functions to be able to track flag changes and to keep vma locking
correctness.

[akpm@linux-foundation.org: fix drivers/misc/open-dice.c, per Hyeonggon Yoo]
Link: https://lkml.kernel.org/r/20230126193752.297968-5-surenb@google.com
Signed-off-by: Suren Baghdasaryan &lt;surenb@google.com&gt;
Acked-by: Michal Hocko &lt;mhocko@suse.com&gt;
Acked-by: Mel Gorman &lt;mgorman@techsingularity.net&gt;
Acked-by: Mike Rapoport (IBM) &lt;rppt@kernel.org&gt;
Acked-by: Sebastian Reichel &lt;sebastian.reichel@collabora.com&gt;
Reviewed-by: Liam R. Howlett &lt;Liam.Howlett@Oracle.com&gt;
Reviewed-by: Hyeonggon Yoo &lt;42.hyeyoo@gmail.com&gt;
Cc: Andy Lutomirski &lt;luto@kernel.org&gt;
Cc: Arjun Roy &lt;arjunroy@google.com&gt;
Cc: Axel Rasmussen &lt;axelrasmussen@google.com&gt;
Cc: David Hildenbrand &lt;david@redhat.com&gt;
Cc: David Howells &lt;dhowells@redhat.com&gt;
Cc: Davidlohr Bueso &lt;dave@stgolabs.net&gt;
Cc: David Rientjes &lt;rientjes@google.com&gt;
Cc: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Greg Thelen &lt;gthelen@google.com&gt;
Cc: Hugh Dickins &lt;hughd@google.com&gt;
Cc: Ingo Molnar &lt;mingo@redhat.com&gt;
Cc: Jann Horn &lt;jannh@google.com&gt;
Cc: Joel Fernandes &lt;joelaf@google.com&gt;
Cc: Johannes Weiner &lt;hannes@cmpxchg.org&gt;
Cc: Kent Overstreet &lt;kent.overstreet@linux.dev&gt;
Cc: Laurent Dufour &lt;ldufour@linux.ibm.com&gt;
Cc: Lorenzo Stoakes &lt;lstoakes@gmail.com&gt;
Cc: Matthew Wilcox &lt;willy@infradead.org&gt;
Cc: Minchan Kim &lt;minchan@google.com&gt;
Cc: Paul E. McKenney &lt;paulmck@kernel.org&gt;
Cc: Peter Oskolkov &lt;posk@google.com&gt;
Cc: Peter Xu &lt;peterx@redhat.com&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Punit Agrawal &lt;punit.agrawal@bytedance.com&gt;
Cc: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Cc: Shakeel Butt &lt;shakeelb@google.com&gt;
Cc: Soheil Hassas Yeganeh &lt;soheil@google.com&gt;
Cc: Song Liu &lt;songliubraving@fb.com&gt;
Cc: Vlastimil Babka &lt;vbabka@suse.cz&gt;
Cc: Will Deacon &lt;will@kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>usb: mon: make mmapped memory read only</title>
<updated>2022-09-22T13:52:29Z</updated>
<author>
<name>Tadeusz Struk</name>
<email>tadeusz.struk@linaro.org</email>
</author>
<published>2022-09-19T21:59:57Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a659daf63d16aa883be42f3f34ff84235c302198'/>
<id>urn:sha1:a659daf63d16aa883be42f3f34ff84235c302198</id>
<content type='text'>
Syzbot found an issue in usbmon module, where the user space client can
corrupt the monitor's internal memory, causing the usbmon module to
crash the kernel with segfault, UAF, etc.

The reproducer mmaps the /dev/usbmon memory to user space, and
overwrites it with arbitrary data, which causes all kinds of issues.

Return an -EPERM error from mon_bin_mmap() if the flag VM_WRTIE is set.
Also clear VM_MAYWRITE to make it impossible to change it to writable
later.

Cc: "Dmitry Vyukov" &lt;dvyukov@google.com&gt;
Cc: stable &lt;stable@kernel.org&gt;
Fixes: 6f23ee1fefdc ("USB: add binary API to usbmon")
Suggested-by: PaX Team &lt;pageexec@freemail.hu&gt;	# for the VM_MAYRITE portion
Link: https://syzkaller.appspot.com/bug?id=2eb1f35d6525fa4a74d75b4244971e5b1411c95a
Reported-by: syzbot+23f57c5ae902429285d7@syzkaller.appspotmail.com
Signed-off-by: Tadeusz Struk &lt;tadeusz.struk@linaro.org&gt;
Link: https://lore.kernel.org/r/20220919215957.205681-1-tadeusz.struk@linaro.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>USB: mon: Use scnprintf() for avoiding potential buffer overflow</title>
<updated>2020-03-12T08:49:28Z</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2020-03-11T09:30:03Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=0de005d0e4270f2dad5289d6dea8db041fba6199'/>
<id>urn:sha1:0de005d0e4270f2dad5289d6dea8db041fba6199</id>
<content type='text'>
Since snprintf() returns the would-be-output size instead of the
actual output size, the succeeding calls may go beyond the given
buffer limit.  Fix it by replacing with scnprintf().

Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Link: https://lore.kernel.org/r/20200311093003.24604-1-tiwai@suse.de
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: mon: Fix a deadlock in usbmon between mmap and read</title>
<updated>2019-12-10T10:41:20Z</updated>
<author>
<name>Pete Zaitcev</name>
<email>zaitcev@redhat.com</email>
</author>
<published>2019-12-05T02:39:41Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=19e6317d24c25ee737c65d1ffb7483bdda4bb54a'/>
<id>urn:sha1:19e6317d24c25ee737c65d1ffb7483bdda4bb54a</id>
<content type='text'>
The problem arises because our read() function grabs a lock of the
circular buffer, finds something of interest, then invokes copy_to_user()
straight from the buffer, which in turn takes mm-&gt;mmap_sem. In the same
time, the callback mon_bin_vma_fault() is invoked under mm-&gt;mmap_sem.
It attempts to take the fetch lock and deadlocks.

This patch does away with protecting of our page list with any
semaphores, and instead relies on the kernel not close the device
while mmap is active in a process.

In addition, we prohibit re-sizing of a buffer while mmap is active.
This way, when (now unlocked) fault is processed, it works with the
page that is intended to be mapped-in, and not some other random page.
Note that this may have an ABI impact, but hopefully no legitimate
program is this wrong.

Signed-off-by: Pete Zaitcev &lt;zaitcev@redhat.com&gt;
Reported-by: syzbot+56f9673bb4cdcbeb0e92@syzkaller.appspotmail.com
Reviewed-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Fixes: 46eb14a6e158 ("USB: fix usbmon BUG trigger")
Cc: &lt;stable@vger.kernel.org&gt;
Link: https://lore.kernel.org/r/20191204203941.3503452b@suzdal.zaitcev.lan
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
