<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers/misc, branch v4.19.54</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.19.54</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.19.54'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2019-06-19T06:18:02Z</updated>
<entry>
<title>Drivers: misc: fix out-of-bounds access in function param_set_kgdbts_var</title>
<updated>2019-06-19T06:18:02Z</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=32f26da4b769ee7bd81ecf11af3d96ff9f08d3b9'/>
<id>urn:sha1:32f26da4b769ee7bd81ecf11af3d96ff9f08d3b9</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>misc: pci_endpoint_test: Fix test_reg_bar to be updated in pci_endpoint_test</title>
<updated>2019-06-15T09:54:06Z</updated>
<author>
<name>Kishon Vijay Abraham I</name>
<email>kishon@ti.com</email>
</author>
<published>2019-03-25T09:39:47Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a7f27994b20709d27f83deda48a5d0eca427bf75'/>
<id>urn:sha1:a7f27994b20709d27f83deda48a5d0eca427bf75</id>
<content type='text'>
[ Upstream commit 8f220664570e755946db1282f48e07f26e1f2cb4 ]

commit 834b90519925 ("misc: pci_endpoint_test: Add support for
PCI_ENDPOINT_TEST regs to be mapped to any BAR") while adding
test_reg_bar in order to map PCI_ENDPOINT_TEST regs to be mapped to any
BAR failed to update test_reg_bar in pci_endpoint_test, resulting in
test_reg_bar having invalid value when used outside probe.

Fix it.

Fixes: 834b90519925 ("misc: pci_endpoint_test: Add support for PCI_ENDPOINT_TEST regs to be mapped to any BAR")
Signed-off-by: Kishon Vijay Abraham I &lt;kishon@ti.com&gt;
Signed-off-by: Lorenzo Pieralisi &lt;lorenzo.pieralisi@arm.com&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:20:54Z</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=67bdeb0c6f5ce3187edbe650ed976d67ee888dbd'/>
<id>urn:sha1:67bdeb0c6f5ce3187edbe650ed976d67ee888dbd</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:16:04Z</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=2be8987a076fd6d501935e51c23ebc738b233a63'/>
<id>urn:sha1:2be8987a076fd6d501935e51c23ebc738b233a63</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>lkdtm: Print real addresses</title>
<updated>2019-04-20T07:16:03Z</updated>
<author>
<name>Christophe Leroy</name>
<email>christophe.leroy@c-s.fr</email>
</author>
<published>2018-11-07T20:14:10Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=55588aebde384375fe301ded672e16c925ce3599'/>
<id>urn:sha1:55588aebde384375fe301ded672e16c925ce3599</id>
<content type='text'>
[ Upstream commit 4c411157a42f122051ae3469bee0b5cabe89e139 ]

Today, when doing a lkdtm test before the readiness of the
random generator, (ptrval) is printed instead of the address
at which it perform the fault:

[ 1597.337030] lkdtm: Performing direct entry EXEC_USERSPACE
[ 1597.337142] lkdtm: attempting ok execution at (ptrval)
[ 1597.337398] lkdtm: attempting bad execution at (ptrval)
[ 1597.337460] kernel tried to execute user page (77858000) -exploit attempt? (uid: 0)
[ 1597.344769] Unable to handle kernel paging request for instruction fetch
[ 1597.351392] Faulting instruction address: 0x77858000
[ 1597.356312] Oops: Kernel access of bad area, sig: 11 [#1]

If the lkdtm test is done later on, it prints an hashed address.

In both cases this is pointless. The purpose of the test is to
ensure the kernel generates an Oops at the expected address,
so real addresses needs to be printed. This patch fixes that.

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>cxl: Wrap iterations over afu slices inside 'afu_list_lock'</title>
<updated>2019-03-23T19:10:03Z</updated>
<author>
<name>Vaibhav Jain</name>
<email>vaibhav@linux.ibm.com</email>
</author>
<published>2019-01-29T11:06:18Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c335b49379b5cd509e441822fa7c4317cee7f5aa'/>
<id>urn:sha1:c335b49379b5cd509e441822fa7c4317cee7f5aa</id>
<content type='text'>
commit edeb304f659792fb5bab90d7d6f3408b4c7301fb upstream.

Within cxl module, iteration over array 'adapter-&gt;afu' may be racy
at few points as it might be simultaneously read during an EEH and its
contents being set to NULL while driver is being unloaded or unbound
from the adapter. This might result in a NULL pointer to 'struct afu'
being de-referenced during an EEH thereby causing a kernel oops.

This patch fixes this by making sure that all access to the array
'adapter-&gt;afu' is wrapped within the context of spin-lock
'adapter-&gt;afu_list_lock'.

Fixes: 9e8df8a21963 ("cxl: EEH support")
Cc: stable@vger.kernel.org # v4.3+
Acked-by: Andrew Donnellan &lt;andrew.donnellan@au1.ibm.com&gt;
Acked-by: Frederic Barrat &lt;fbarrat@linux.ibm.com&gt;
Acked-by: Christophe Lombard &lt;clombard@linux.vnet.ibm.com&gt;
Signed-off-by: Vaibhav Jain &lt;vaibhav@linux.ibm.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mei: bus: move hw module get/put to probe/release</title>
<updated>2019-03-23T19:09:39Z</updated>
<author>
<name>Alexander Usyskin</name>
<email>alexander.usyskin@intel.com</email>
</author>
<published>2019-02-25T09:09:28Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a253d1f3e490068fb017855da481762c53f01ab5'/>
<id>urn:sha1:a253d1f3e490068fb017855da481762c53f01ab5</id>
<content type='text'>
commit b5958faa34e2f99f3475ad89c52d98dfea079d33 upstream.

Fix unbalanced module reference counting during internal reset, which
prevents the drivers unloading.
Tracking mei_me/txe modules on mei client bus via
mei_cldev_enable/disable is error prone due to possible internal
reset flow, where clients are disconnected underneath.
Moving reference counting to probe and release of mei bus client
driver solves this issue in simplest way, as each client provides only
a single connection to a client bus driver.

Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Alexander Usyskin &lt;alexander.usyskin@intel.com&gt;
Signed-off-by: Tomas Winkler &lt;tomas.winkler@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mei: hbm: clean the feature flags on link reset</title>
<updated>2019-03-23T19:09:39Z</updated>
<author>
<name>Alexander Usyskin</name>
<email>alexander.usyskin@intel.com</email>
</author>
<published>2019-02-20T14:55:37Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=02c0c70fb36e60f4548072803734552e86447b18'/>
<id>urn:sha1:02c0c70fb36e60f4548072803734552e86447b18</id>
<content type='text'>
commit 37fd0b623023484ef6df79ed46f21f06ecc611ff upstream.

The list of supported functions can be altered upon link reset,
clean the flags to allow correct selections of supported
features.

Cc: &lt;stable@vger.kernel.org&gt; v4.19+
Signed-off-by: Alexander Usyskin &lt;alexander.usyskin@intel.com&gt;
Signed-off-by: Tomas Winkler &lt;tomas.winkler@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>eeprom: at24: add support for 24c2048</title>
<updated>2019-02-20T09:25:35Z</updated>
<author>
<name>Adrian Bunk</name>
<email>bunk@kernel.org</email>
</author>
<published>2018-11-29T19:58:58Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d4aaa45f2d983819a0d299193f21368841bf725f'/>
<id>urn:sha1:d4aaa45f2d983819a0d299193f21368841bf725f</id>
<content type='text'>
[ Upstream commit 37cf28d3b5bca1b532a0b6aac722e7f2788a9294 ]

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>
<entry>
<title>mic: vop: Fix use-after-free on remove</title>
<updated>2019-02-15T07:10:12Z</updated>
<author>
<name>Vincent Whitchurch</name>
<email>vincent.whitchurch@axis.com</email>
</author>
<published>2019-02-01T09:03:12Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=1ce0fcebff24f3f06ec0e42e472c0250384e6d41'/>
<id>urn:sha1:1ce0fcebff24f3f06ec0e42e472c0250384e6d41</id>
<content type='text'>
commit 70ed7148dadb812f2f7c9927e98ef3cf4869dfa9 upstream.

KASAN detects a use-after-free when vop devices are removed.

This problem was introduced by commit 0063e8bbd2b62d136 ("virtio_vop:
don't kfree device on register failure").  That patch moved the freeing
of the struct _vop_vdev to the release function, but failed to ensure
that vop holds a reference to the device when it doesn't want it to go
away.  A kfree() was replaced with a put_device() in the unregistration
path, but the last reference to the device is already dropped in
unregister_virtio_device() so the struct is freed before vop is done
with it.

Fix it by holding a reference until cleanup is done.  This is similar to
the fix in virtio_pci in commit 2989be09a8a9d6 ("virtio_pci: fix use
after free on release").

 ==================================================================
 BUG: KASAN: use-after-free in vop_scan_devices+0xc6c/0xe50 [vop]
 Read of size 8 at addr ffff88800da18580 by task kworker/0:1/12

 CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.0.0-rc4+ #53
 Workqueue: events vop_hotplug_devices [vop]
 Call Trace:
  dump_stack+0x74/0xbb
  print_address_description+0x5d/0x2b0
  ? vop_scan_devices+0xc6c/0xe50 [vop]
  kasan_report+0x152/0x1aa
  ? vop_scan_devices+0xc6c/0xe50 [vop]
  ? vop_scan_devices+0xc6c/0xe50 [vop]
  vop_scan_devices+0xc6c/0xe50 [vop]
  ? vop_loopback_free_irq+0x160/0x160 [vop_loopback]
  process_one_work+0x7c0/0x14b0
  ? pwq_dec_nr_in_flight+0x2d0/0x2d0
  ? do_raw_spin_lock+0x120/0x280
  worker_thread+0x8f/0xbf0
  ? __kthread_parkme+0x78/0xf0
  ? process_one_work+0x14b0/0x14b0
  kthread+0x2ae/0x3a0
  ? kthread_park+0x120/0x120
  ret_from_fork+0x3a/0x50

 Allocated by task 12:
  kmem_cache_alloc_trace+0x13a/0x2a0
  vop_scan_devices+0x473/0xe50 [vop]
  process_one_work+0x7c0/0x14b0
  worker_thread+0x8f/0xbf0
  kthread+0x2ae/0x3a0
  ret_from_fork+0x3a/0x50

 Freed by task 12:
  kfree+0x104/0x310
  device_release+0x73/0x1d0
  kobject_put+0x14f/0x420
  unregister_virtio_device+0x32/0x50
  vop_scan_devices+0x19d/0xe50 [vop]
  process_one_work+0x7c0/0x14b0
  worker_thread+0x8f/0xbf0
  kthread+0x2ae/0x3a0
  ret_from_fork+0x3a/0x50

 The buggy address belongs to the object at ffff88800da18008
  which belongs to the cache kmalloc-2k of size 2048
 The buggy address is located 1400 bytes inside of
  2048-byte region [ffff88800da18008, ffff88800da18808)
 The buggy address belongs to the page:
 page:ffffea0000368600 count:1 mapcount:0 mapping:ffff88801440dbc0 index:0x0 compound_mapcount: 0
 flags: 0x4000000000010200(slab|head)
 raw: 4000000000010200 ffffea0000378608 ffffea000037a008 ffff88801440dbc0
 raw: 0000000000000000 00000000000d000d 00000001ffffffff 0000000000000000
 page dumped because: kasan: bad access detected

 Memory state around the buggy address:
  ffff88800da18480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
  ffff88800da18500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 &gt;ffff88800da18580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                    ^
  ffff88800da18600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
  ffff88800da18680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ==================================================================

Fixes: 0063e8bbd2b62d136 ("virtio_vop: don't kfree device on register failure")
Signed-off-by: Vincent Whitchurch &lt;vincent.whitchurch@axis.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
