<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git, branch v3.18.118</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.18.118</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.18.118'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2018-08-09T10:20:36Z</updated>
<entry>
<title>Linux 3.18.118</title>
<updated>2018-08-09T10:20:36Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2018-08-09T10:20:36Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=830f9674e76d08d04585e53fc200ae8af99966e7'/>
<id>urn:sha1:830f9674e76d08d04585e53fc200ae8af99966e7</id>
<content type='text'>
</content>
</entry>
<entry>
<title>jfs: Fix inconsistency between memory allocation and ea_buf-&gt;max_size</title>
<updated>2018-08-09T10:20:36Z</updated>
<author>
<name>Shankara Pailoor</name>
<email>shankarapailoor@gmail.com</email>
</author>
<published>2018-06-05T13:33:27Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=31430f2b98f6053933482e51d008124fc31bc3e0'/>
<id>urn:sha1:31430f2b98f6053933482e51d008124fc31bc3e0</id>
<content type='text'>
commit 92d34134193e5b129dc24f8d79cb9196626e8d7a upstream.

The code is assuming the buffer is max_size length, but we weren't
allocating enough space for it.

Signed-off-by: Shankara Pailoor &lt;shankarapailoor@gmail.com&gt;
Signed-off-by: Dave Kleikamp &lt;dave.kleikamp@oracle.com&gt;
Cc: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ring_buffer: tracing: Inherit the tracing setting to next ring buffer</title>
<updated>2018-08-09T10:20:36Z</updated>
<author>
<name>Masami Hiramatsu</name>
<email>mhiramat@kernel.org</email>
</author>
<published>2018-07-13T16:28:15Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=fed22131f5b2740acbf184910133179b558aecc0'/>
<id>urn:sha1:fed22131f5b2740acbf184910133179b558aecc0</id>
<content type='text'>
commit 73c8d8945505acdcbae137c2e00a1232e0be709f upstream.

Maintain the tracing on/off setting of the ring_buffer when switching
to the trace buffer snapshot.

Taking a snapshot is done by swapping the backup ring buffer
(max_tr_buffer). But since the tracing on/off setting is defined
by the ring buffer, when swapping it, the tracing on/off setting
can also be changed. This causes a strange result like below:

  /sys/kernel/debug/tracing # cat tracing_on
  1
  /sys/kernel/debug/tracing # echo 0 &gt; tracing_on
  /sys/kernel/debug/tracing # cat tracing_on
  0
  /sys/kernel/debug/tracing # echo 1 &gt; snapshot
  /sys/kernel/debug/tracing # cat tracing_on
  1
  /sys/kernel/debug/tracing # echo 1 &gt; snapshot
  /sys/kernel/debug/tracing # cat tracing_on
  0

We don't touch tracing_on, but snapshot changes tracing_on
setting each time. This is an anomaly, because user doesn't know
that each "ring_buffer" stores its own tracing-enable state and
the snapshot is done by swapping ring buffers.

Link: http://lkml.kernel.org/r/153149929558.11274.11730609978254724394.stgit@devbox

Cc: Ingo Molnar &lt;mingo@redhat.com&gt;
Cc: Shuah Khan &lt;shuah@kernel.org&gt;
Cc: Tom Zanussi &lt;tom.zanussi@linux.intel.com&gt;
Cc: Hiraku Toyooka &lt;hiraku.toyooka@cybertrust.co.jp&gt;
Cc: stable@vger.kernel.org
Fixes: debdd57f5145 ("tracing: Make a snapshot feature available from userspace")
Signed-off-by: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
[ Updated commit log and comment in the code ]
Signed-off-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;
Signed-off-by: Sudip Mukherjee &lt;sudipm.mukherjee@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>scsi: qla2xxx: Return error when TMF returns</title>
<updated>2018-08-09T10:20:35Z</updated>
<author>
<name>Anil Gurumurthy</name>
<email>anil.gurumurthy@cavium.com</email>
</author>
<published>2018-07-18T21:29:55Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=fa4bbed870c492b899cd779c05f8714c1b205e12'/>
<id>urn:sha1:fa4bbed870c492b899cd779c05f8714c1b205e12</id>
<content type='text'>
commit b4146c4929ef61d5afca011474d59d0918a0cd82 upstream.

Propagate the task management completion status properly to avoid
unnecessary waits for commands to complete.

Fixes: faef62d13463 ("[SCSI] qla2xxx: Fix Task Management command asynchronous handling")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Anil Gurumurthy &lt;anil.gurumurthy@cavium.com&gt;
Signed-off-by: Himanshu Madhani &lt;himanshu.madhani@cavium.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>scsi: qla2xxx: Fix ISP recovery on unload</title>
<updated>2018-08-09T10:20:35Z</updated>
<author>
<name>Quinn Tran</name>
<email>quinn.tran@cavium.com</email>
</author>
<published>2018-07-18T21:29:54Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2de35a8aac3f627a900cf4d259511860f83bb5a3'/>
<id>urn:sha1:2de35a8aac3f627a900cf4d259511860f83bb5a3</id>
<content type='text'>
commit b08abbd9f5996309f021684f9ca74da30dcca36a upstream.

During unload process, the chip can encounter problem where a FW dump would
be captured. For this case, the full reset sequence will be skip to bring
the chip back to full operational state.

Fixes: e315cd28b9ef ("[SCSI] qla2xxx: Code changes for qla data structure refactoring")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Quinn Tran &lt;quinn.tran@cavium.com&gt;
Signed-off-by: Himanshu Madhani &lt;himanshu.madhani@cavium.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>scsi: sg: fix minor memory leak in error path</title>
<updated>2018-08-09T10:20:35Z</updated>
<author>
<name>Tony Battersby</name>
<email>tonyb@cybernetics.com</email>
</author>
<published>2018-07-12T20:30:45Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f42178c0f2f09d6e87b0a35dff3c8484eeaaa197'/>
<id>urn:sha1:f42178c0f2f09d6e87b0a35dff3c8484eeaaa197</id>
<content type='text'>
commit c170e5a8d222537e98aa8d4fddb667ff7a2ee114 upstream.

Fix a minor memory leak when there is an error opening a /dev/sg device.

Fixes: cc833acbee9d ("sg: O_EXCL and other lock handling")
Cc: &lt;stable@vger.kernel.org&gt;
Reviewed-by: Ewan D. Milne &lt;emilne@redhat.com&gt;
Signed-off-by: Tony Battersby &lt;tonyb@cybernetics.com&gt;
Reviewed-by: Bart Van Assche &lt;bart.vanassche@wdc.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>crypto: padlock-aes - Fix Nano workaround data corruption</title>
<updated>2018-08-09T10:20:34Z</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2018-07-13T08:12:32Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=fc7ec0c4ef5c29fc0679e12a02e22869b3092370'/>
<id>urn:sha1:fc7ec0c4ef5c29fc0679e12a02e22869b3092370</id>
<content type='text'>
commit 46d8c4b28652d35dc6cfb5adf7f54e102fc04384 upstream.

This was detected by the self-test thanks to Ard's chunking patch.

I finally got around to testing this out on my ancient Via box.  It
turns out that the workaround got the assembly wrong and we end up
doing count + initial cycles of the loop instead of just count.

This obviously causes corruption, either by overwriting the source
that is yet to be processed, or writing over the end of the buffer.

On CPUs that don't require the workaround only ECB is affected.
On Nano CPUs both ECB and CBC are affected.

This patch fixes it by doing the subtraction prior to the assembly.

Fixes: a76c1c23d0c3 ("crypto: padlock-aes - work around Nano CPU...")
Cc: &lt;stable@vger.kernel.org&gt;
Reported-by: Jamie Heilman &lt;jamie@audible.transient.net&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>virtio_balloon: fix another race between migration and ballooning</title>
<updated>2018-08-09T10:20:34Z</updated>
<author>
<name>Jiang Biao</name>
<email>jiang.biao2@zte.com.cn</email>
</author>
<published>2018-07-18T02:29:28Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c4682ea443b921c88d6b6165619d6ab973fe41c1'/>
<id>urn:sha1:c4682ea443b921c88d6b6165619d6ab973fe41c1</id>
<content type='text'>
commit 89da619bc18d79bca5304724c11d4ba3b67ce2c6 upstream.

Kernel panic when with high memory pressure, calltrace looks like,

PID: 21439 TASK: ffff881be3afedd0 CPU: 16 COMMAND: "java"
 #0 [ffff881ec7ed7630] machine_kexec at ffffffff81059beb
 #1 [ffff881ec7ed7690] __crash_kexec at ffffffff81105942
 #2 [ffff881ec7ed7760] crash_kexec at ffffffff81105a30
 #3 [ffff881ec7ed7778] oops_end at ffffffff816902c8
 #4 [ffff881ec7ed77a0] no_context at ffffffff8167ff46
 #5 [ffff881ec7ed77f0] __bad_area_nosemaphore at ffffffff8167ffdc
 #6 [ffff881ec7ed7838] __node_set at ffffffff81680300
 #7 [ffff881ec7ed7860] __do_page_fault at ffffffff8169320f
 #8 [ffff881ec7ed78c0] do_page_fault at ffffffff816932b5
 #9 [ffff881ec7ed78f0] page_fault at ffffffff8168f4c8
    [exception RIP: _raw_spin_lock_irqsave+47]
    RIP: ffffffff8168edef RSP: ffff881ec7ed79a8 RFLAGS: 00010046
    RAX: 0000000000000246 RBX: ffffea0019740d00 RCX: ffff881ec7ed7fd8
    RDX: 0000000000020000 RSI: 0000000000000016 RDI: 0000000000000008
    RBP: ffff881ec7ed79a8 R8: 0000000000000246 R9: 000000000001a098
    R10: ffff88107ffda000 R11: 0000000000000000 R12: 0000000000000000
    R13: 0000000000000008 R14: ffff881ec7ed7a80 R15: ffff881be3afedd0
    ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018

It happens in the pagefault and results in double pagefault
during compacting pages when memory allocation fails.

Analysed the vmcore, the page leads to second pagefault is corrupted
with _mapcount=-256, but private=0.

It's caused by the race between migration and ballooning, and lock
missing in virtballoon_migratepage() of virtio_balloon driver.
This patch fix the bug.

Fixes: e22504296d4f64f ("virtio_balloon: introduce migration primitives to balloon pages")
Cc: stable@vger.kernel.org
Signed-off-by: Jiang Biao &lt;jiang.biao2@zte.com.cn&gt;
Signed-off-by: Huang Chong &lt;huang.chong@zte.com.cn&gt;
Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>can: ems_usb: Fix memory leak on ems_usb_disconnect()</title>
<updated>2018-08-09T10:20:34Z</updated>
<author>
<name>Anton Vasilyev</name>
<email>vasilyev@ispras.ru</email>
</author>
<published>2018-07-27T15:50:42Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a64e47ee1fa0d9fd506ad84fedba380381965ae5'/>
<id>urn:sha1:a64e47ee1fa0d9fd506ad84fedba380381965ae5</id>
<content type='text'>
commit 72c05f32f4a5055c9c8fe889bb6903ec959c0aad upstream.

ems_usb_probe() allocates memory for dev-&gt;tx_msg_buffer, but there
is no its deallocation in ems_usb_disconnect().

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Anton Vasilyev &lt;vasilyev@ispras.ru&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>squashfs: more metadata hardenings</title>
<updated>2018-08-09T10:20:33Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2018-08-02T15:43:35Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=4a60e5435410a27e7daea64d1ed550dd8238936b'/>
<id>urn:sha1:4a60e5435410a27e7daea64d1ed550dd8238936b</id>
<content type='text'>
commit 71755ee5350b63fb1f283de8561cdb61b47f4d1d upstream.

The squashfs fragment reading code doesn't actually verify that the
fragment is inside the fragment table.  The end result _is_ verified to
be inside the image when actually reading the fragment data, but before
that is done, we may end up taking a page fault because the fragment
table itself might not even exist.

Another report from Anatoly and his endless squashfs image fuzzing.

Reported-by: Анатолий Тросиненко &lt;anatoly.trosinenko@gmail.com&gt;
Acked-by:: Phillip Lougher &lt;phillip.lougher@gmail.com&gt;,
Cc: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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