<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers/misc, branch v4.9.203</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.9.203</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.9.203'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2019-11-25T08:53:52Z</updated>
<entry>
<title>misc: cxl: Fix possible null pointer dereference</title>
<updated>2019-11-25T08:53:52Z</updated>
<author>
<name>zhong jiang</name>
<email>zhongjiang@huawei.com</email>
</author>
<published>2018-10-04T05:02:53Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b8199f6a79919919fe043f719baffab13c585bf0'/>
<id>urn:sha1:b8199f6a79919919fe043f719baffab13c585bf0</id>
<content type='text'>
[ Upstream commit 3dac3583bf1a61db6aaf31dfd752c677a4400afd ]

It is not safe to dereference an object before a null test. It is
not needed and just remove them. Ftrace can be used instead.

Signed-off-by: zhong jiang &lt;zhongjiang@huawei.com&gt;
Acked-by: Andrew Donnellan &lt;andrew.donnellan@au1.ibm.com&gt;
Acked-by: Frederic Barrat &lt;fbarrat@linux.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>misc: genwqe: should return proper error value.</title>
<updated>2019-11-25T08:52:54Z</updated>
<author>
<name>zhong jiang</name>
<email>zhongjiang@huawei.com</email>
</author>
<published>2018-09-20T02:29:13Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=19d875ecbd055b616880d00a5292334ed78a6385'/>
<id>urn:sha1:19d875ecbd055b616880d00a5292334ed78a6385</id>
<content type='text'>
[ Upstream commit 02241995b004faa7d9ff628e97f24056190853f8 ]

The function should return -EFAULT when copy_from_user fails. Even
though the caller does not distinguish them. but we should keep backward
compatibility.

Signed-off-by: zhong jiang &lt;zhongjiang@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>misc: kgdbts: Fix restrict error</title>
<updated>2019-11-25T08:52:54Z</updated>
<author>
<name>Laura Abbott</name>
<email>labbott@redhat.com</email>
</author>
<published>2018-09-11T17:44:03Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=4f15bdce673e56b0fa863d604fb9c5a03581a96c'/>
<id>urn:sha1:4f15bdce673e56b0fa863d604fb9c5a03581a96c</id>
<content type='text'>
[ Upstream commit fa0218ef733e6f247a1a3986e3eb12460064ac77 ]

kgdbts current fails when compiled with restrict:

drivers/misc/kgdbts.c: In function ‘configure_kgdbts’:
drivers/misc/kgdbts.c:1070:2: error: ‘strcpy’ source argument is the same as destination [-Werror=restrict]
  strcpy(config, opt);
  ^~~~~~~~~~~~~~~~~~~

As the error says, config is being used in both the source and destination.
Refactor the code to avoid the extra copy and put the parsing closer to
the actual location.

Signed-off-by: Laura Abbott &lt;labbott@redhat.com&gt;
Acked-by: Daniel Thompson &lt;daniel.thompson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>VMCI: Release resource if the work is already queued</title>
<updated>2019-09-06T08:19:52Z</updated>
<author>
<name>Nadav Amit</name>
<email>namit@vmware.com</email>
</author>
<published>2019-08-20T20:26:38Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=925bf2d80f8374b5080b764461da6b885a0317d7'/>
<id>urn:sha1:925bf2d80f8374b5080b764461da6b885a0317d7</id>
<content type='text'>
commit ba03a9bbd17b149c373c0ea44017f35fc2cd0f28 upstream.

Francois reported that VMware balloon gets stuck after a balloon reset,
when the VMCI doorbell is removed. A similar error can occur when the
balloon driver is removed with the following splat:

[ 1088.622000] INFO: task modprobe:3565 blocked for more than 120 seconds.
[ 1088.622035]       Tainted: G        W         5.2.0 #4
[ 1088.622087] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1088.622205] modprobe        D    0  3565   1450 0x00000000
[ 1088.622210] Call Trace:
[ 1088.622246]  __schedule+0x2a8/0x690
[ 1088.622248]  schedule+0x2d/0x90
[ 1088.622250]  schedule_timeout+0x1d3/0x2f0
[ 1088.622252]  wait_for_completion+0xba/0x140
[ 1088.622320]  ? wake_up_q+0x80/0x80
[ 1088.622370]  vmci_resource_remove+0xb9/0xc0 [vmw_vmci]
[ 1088.622373]  vmci_doorbell_destroy+0x9e/0xd0 [vmw_vmci]
[ 1088.622379]  vmballoon_vmci_cleanup+0x6e/0xf0 [vmw_balloon]
[ 1088.622381]  vmballoon_exit+0x18/0xcc8 [vmw_balloon]
[ 1088.622394]  __x64_sys_delete_module+0x146/0x280
[ 1088.622408]  do_syscall_64+0x5a/0x130
[ 1088.622410]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 1088.622415] RIP: 0033:0x7f54f62791b7
[ 1088.622421] Code: Bad RIP value.
[ 1088.622421] RSP: 002b:00007fff2a949008 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
[ 1088.622426] RAX: ffffffffffffffda RBX: 000055dff8b55d00 RCX: 00007f54f62791b7
[ 1088.622426] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 000055dff8b55d68
[ 1088.622427] RBP: 000055dff8b55d00 R08: 00007fff2a947fb1 R09: 0000000000000000
[ 1088.622427] R10: 00007f54f62f5cc0 R11: 0000000000000206 R12: 000055dff8b55d68
[ 1088.622428] R13: 0000000000000001 R14: 000055dff8b55d68 R15: 00007fff2a94a3f0

The cause for the bug is that when the "delayed" doorbell is invoked, it
takes a reference on the doorbell entry and schedules work that is
supposed to run the appropriate code and drop the doorbell entry
reference. The code ignores the fact that if the work is already queued,
it will not be scheduled to run one more time. As a result one of the
references would not be dropped. When the code waits for the reference
to get to zero, during balloon reset or module removal, it gets stuck.

Fix it. Drop the reference if schedule_work() indicates that the work is
already queued.

Note that this bug got more apparent (or apparent at all) due to
commit ce664331b248 ("vmw_balloon: VMCI_DOORBELL_SET does not check status").

Fixes: 83e2ec765be03 ("VMCI: doorbell implementation.")
Reported-by: Francois Rigault &lt;rigault.francois@gmail.com&gt;
Cc: Jorgen Hansen &lt;jhansen@vmware.com&gt;
Cc: Adit Ranadive &lt;aditr@vmware.com&gt;
Cc: Alexios Zavras &lt;alexios.zavras@intel.com&gt;
Cc: Vishnu DASA &lt;vdasa@vmware.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Nadav Amit &lt;namit@vmware.com&gt;
Reviewed-by: Vishnu Dasa &lt;vdasa@vmware.com&gt;
Link: https://lore.kernel.org/r/20190820202638.49003-1-namit@vmware.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>eeprom: at24: make spd world-readable again</title>
<updated>2019-08-06T16:29:42Z</updated>
<author>
<name>Jean Delvare</name>
<email>jdelvare@suse.de</email>
</author>
<published>2019-07-28T16:41:38Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=0b326994892a2f8ed76cd4867c3aebcec9e6b54d'/>
<id>urn:sha1:0b326994892a2f8ed76cd4867c3aebcec9e6b54d</id>
<content type='text'>
commit 25e5ef302c24a6fead369c0cfe88c073d7b97ca8 upstream.

The integration of the at24 driver into the nvmem framework broke the
world-readability of spd EEPROMs. Fix it.

Signed-off-by: Jean Delvare &lt;jdelvare@suse.de&gt;
Cc: stable@vger.kernel.org
Fixes: 57d155506dd5 ("eeprom: at24: extend driver to plug into the NVMEM framework")
Cc: Andrew Lunn &lt;andrew@lunn.ch&gt;
Cc: Srinivas Kandagatla &lt;srinivas.kandagatla@linaro.org&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Bartosz Golaszewski &lt;brgl@bgdev.pl&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Bartosz Golaszewski &lt;bgolaszewski@baylibre.com&gt;
[Bartosz: backported the patch to older branches]
Signed-off-by: Bartosz Golaszewski &lt;bgolaszewski@baylibre.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>VMCI: Fix integer overflow in VMCI handle arrays</title>
<updated>2019-07-21T07:06:03Z</updated>
<author>
<name>Vishnu DASA</name>
<email>vdasa@vmware.com</email>
</author>
<published>2019-05-24T15:13:10Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=6f56992a4e66b699f072459e3333946078f6cc83'/>
<id>urn:sha1:6f56992a4e66b699f072459e3333946078f6cc83</id>
<content type='text'>
commit 1c2eb5b2853c9f513690ba6b71072d8eb65da16a upstream.

The VMCI handle array has an integer overflow in
vmci_handle_arr_append_entry when it tries to expand the array. This can be
triggered from a guest, since the doorbell link hypercall doesn't impose a
limit on the number of doorbell handles that a VM can create in the
hypervisor, and these handles are stored in a handle array.

In this change, we introduce a mandatory max capacity for handle
arrays/lists to avoid excessive memory usage.

Signed-off-by: Vishnu Dasa &lt;vdasa@vmware.com&gt;
Reviewed-by: Adit Ranadive &lt;aditr@vmware.com&gt;
Reviewed-by: Jorgen Hansen &lt;jhansen@vmware.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Drivers: misc: fix out-of-bounds access in function param_set_kgdbts_var</title>
<updated>2019-06-22T06:17:19Z</updated>
<author>
<name>Young Xiao</name>
<email>YangX92@hotmail.com</email>
</author>
<published>2019-04-12T07:45:06Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=32f99125fe6227128ec4e8996884db74b9dc3062'/>
<id>urn:sha1:32f99125fe6227128ec4e8996884db74b9dc3062</id>
<content type='text'>
[ Upstream commit b281218ad4311a0342a40cb02fb17a363df08b48 ]

There is an out-of-bounds access to "config[len - 1]" array when the
variable "len" is zero.

See commit dada6a43b040 ("kgdboc: fix KASAN global-out-of-bounds bug
in param_set_kgdboc_var()") for details.

Signed-off-by: Young Xiao &lt;YangX92@hotmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>genwqe: Prevent an integer overflow in the ioctl</title>
<updated>2019-06-11T10:22:48Z</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2019-05-07T08:36:34Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ef1a4a38f52791a2b7580af3f999656d489a70ae'/>
<id>urn:sha1:ef1a4a38f52791a2b7580af3f999656d489a70ae</id>
<content type='text'>
commit 110080cea0d0e4dfdb0b536e7f8a5633ead6a781 upstream.

There are a couple potential integer overflows here.

	round_up(m-&gt;size + (m-&gt;addr &amp; ~PAGE_MASK), PAGE_SIZE);

The first thing is that the "m-&gt;size + (...)" addition could overflow,
and the second is that round_up() overflows to zero if the result is
within PAGE_SIZE of the type max.

In this code, the "m-&gt;size" variable is an u64 but we're saving the
result in "map_size" which is an unsigned long and genwqe_user_vmap()
takes an unsigned long as well.  So I have used ULONG_MAX as the upper
bound.  From a practical perspective unsigned long is fine/better than
trying to change all the types to u64.

Fixes: eaf4722d4645 ("GenWQE Character device and DDCB queue")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>lkdtm: Add tests for NULL pointer dereference</title>
<updated>2019-04-20T07:07:53Z</updated>
<author>
<name>Christophe Leroy</name>
<email>christophe.leroy@c-s.fr</email>
</author>
<published>2018-12-14T15:26:20Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=14c328b46e23fcac4d9e2e38b989827e612e6d1e'/>
<id>urn:sha1:14c328b46e23fcac4d9e2e38b989827e612e6d1e</id>
<content type='text'>
[ Upstream commit 59a12205d3c32aee4c13ca36889fdf7cfed31126 ]

Introduce lkdtm tests for NULL pointer dereference: check access or exec
at NULL address, since these errors tend to be reported differently from
the general fault error text. For example from x86:

    pr_alert("BUG: unable to handle kernel %s at %px\n",
        address &lt; PAGE_SIZE ? "NULL pointer dereference" : "paging request",
        (void *)address);

Signed-off-by: Christophe Leroy &lt;christophe.leroy@c-s.fr&gt;
Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>eeprom: at24: add support for 24c2048</title>
<updated>2019-02-20T09:18:25Z</updated>
<author>
<name>Adrian Bunk</name>
<email>bunk@kernel.org</email>
</author>
<published>2019-02-17T11:14:52Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=bc6f7dc0b2e8bf9ad6f192d718c014e2c07ef2f1'/>
<id>urn:sha1:bc6f7dc0b2e8bf9ad6f192d718c014e2c07ef2f1</id>
<content type='text'>
commit 37cf28d3b5bca1b532a0b6aac722e7f2788a9294 upstream.

Works with ST M24M02.

Signed-off-by: Adrian Bunk &lt;bunk@kernel.org&gt;
Signed-off-by: Bartosz Golaszewski &lt;brgl@bgdev.pl&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
