Re: Security ERRATA Important: kernel on SL6.x i386/x86_64

2019-11-14 Thread Steven C Timm 
is that right--2 different SL6 kernel updates in 2 days?

Steve


From: owner-scientific-linux-err...@listserv.fnal.gov 
 on behalf of Farhan Ahmed 

Sent: Thursday, November 14, 2019 12:16 PM
To: scientific-linux-errata 
Subject: Security ERRATA Important: kernel on SL6.x i386/x86_64

Synopsis:  Important: kernel security update
Advisory ID:   SLSA-2019:3878-1
Issue Date:2019-11-14
CVE Numbers:   CVE-2019-0155
--

Security Fix(es):

* hw: Intel GPU blitter manipulation can allow for arbitrary kernel memory
write (CVE-2019-0155)

For more details about the security issue(s), including the impact, a CVSS
score, acknowledgments, and other related information, refer to the CVE
page(s) listed in the References section.

--

SL6
  x86_64
kernel-2.6.32-754.24.3.el6.x86_64.rpm
kernel-debug-2.6.32-754.24.3.el6.x86_64.rpm
kernel-debug-debuginfo-2.6.32-754.24.3.el6.i686.rpm
kernel-debug-debuginfo-2.6.32-754.24.3.el6.x86_64.rpm
kernel-debug-devel-2.6.32-754.24.3.el6.i686.rpm
kernel-debug-devel-2.6.32-754.24.3.el6.x86_64.rpm
kernel-debuginfo-2.6.32-754.24.3.el6.i686.rpm
kernel-debuginfo-2.6.32-754.24.3.el6.x86_64.rpm
kernel-debuginfo-common-i686-2.6.32-754.24.3.el6.i686.rpm
kernel-debuginfo-common-x86_64-2.6.32-754.24.3.el6.x86_64.rpm
kernel-devel-2.6.32-754.24.3.el6.x86_64.rpm
kernel-headers-2.6.32-754.24.3.el6.x86_64.rpm
perf-2.6.32-754.24.3.el6.x86_64.rpm
perf-debuginfo-2.6.32-754.24.3.el6.i686.rpm
perf-debuginfo-2.6.32-754.24.3.el6.x86_64.rpm
python-perf-debuginfo-2.6.32-754.24.3.el6.i686.rpm
python-perf-debuginfo-2.6.32-754.24.3.el6.x86_64.rpm
python-perf-2.6.32-754.24.3.el6.x86_64.rpm
  i386
kernel-2.6.32-754.24.3.el6.i686.rpm
kernel-debug-2.6.32-754.24.3.el6.i686.rpm
kernel-debug-debuginfo-2.6.32-754.24.3.el6.i686.rpm
kernel-debug-devel-2.6.32-754.24.3.el6.i686.rpm
kernel-debuginfo-2.6.32-754.24.3.el6.i686.rpm
kernel-debuginfo-common-i686-2.6.32-754.24.3.el6.i686.rpm
kernel-devel-2.6.32-754.24.3.el6.i686.rpm
kernel-headers-2.6.32-754.24.3.el6.i686.rpm
perf-2.6.32-754.24.3.el6.i686.rpm
perf-debuginfo-2.6.32-754.24.3.el6.i686.rpm
python-perf-debuginfo-2.6.32-754.24.3.el6.i686.rpm
python-perf-2.6.32-754.24.3.el6.i686.rpm
  noarch
kernel-abi-whitelists-2.6.32-754.24.3.el6.noarch.rpm
kernel-doc-2.6.32-754.24.3.el6.noarch.rpm
kernel-firmware-2.6.32-754.24.3.el6.noarch.rpm

- Scientific Linux Development Team

Re: Security ERRATA Important: kernel on SL6.x i386/x86_64

2018-07-03 Thread Stephan Wiesand 
Hi Valery,

> On 3. Jul 2018, at 19:21, Valery Mitsyn  wrote:
> 
> Hi Scott,
> 
> thanks!
> afs started and accessible now.
> {{{
> # modinfo openafs
> filename: /lib/modules/2.6.32-754.el6.x86_64/kernel/fs/openafs/openafs.ko
> license:http://www.openafs.org/dl/license10.html
> srcversion: 44B6D0833299E389AA97BF6
> depends:
> vermagic:   2.6.32-754.el6.x86_64 SMP mod_unload modversions
> }}}
> 
> But I'm still worried, now versions of kmod-openafs and other openafs
> packages are different

don't worry. The interface between the kernel module and the userland
part of the client is completely stable.

- Stephan

> {{{
> # rpm -qa \*openafs\* | sort
> kmod-openafs-1.6.22.3-1.SL610.el6.noarch
> kmod-openafs-696-1.6.20-257.sl6.696.x86_64
> kmod-openafs-754-1.6.22.3-286.sl6.754.x86_64
> openafs-1.6.20-257.sl6.x86_64
> openafs-client-1.6.20-257.sl6.x86_64
> openafs-krb5-1.6.20-257.sl6.x86_64
> openafs-module-tools-1.6.20-257.sl6.x86_64
> }}}
> 
> On Tue, 3 Jul 2018, Scott Reid wrote:
> 
>> 
>> HI Valery,
>> 
>> Thanks for the report!
>> 
>> kmod-openafs has been added to the security repo. Let us know if that 
>> doesn't solve your problem.
>> 
>> Thanks!
>> 
>> On 7/3/18, 10:29 AM, "owner-scientific-linux-us...@listserv.fnal.gov on 
>> behalf of Valery Mitsyn" > behalf of v...@mammoth.jinr.ru> wrote:
>> 
>>   Oh! There are no kmod-openafs for this kernel.
>>   AFS does not start after the update.
>> 
>>   On Mon, 2 Jul 2018, Scott Reid wrote:
>> 
>>   > Synopsis:  Important: kernel security and bug fix update
>>   > Advisory ID:   SLSA-2018:1854-1
>>   > Issue Date:2018-06-19
>>   > CVE Numbers:   CVE-2016-8650
>>   >   CVE-2017-7308
>>   >   CVE-2017-6001
>>   >   CVE-2017-2671
>>   >   CVE-2017-7616
>>   >   CVE-2017-7889
>>   >   CVE-2017-8890
>>   >   CVE-2017-9076
>>   >   CVE-2017-9075
>>   >   CVE-2017-9077
>>   >   CVE-2017-12190
>>   >   CVE-2017-15121
>>   >   CVE-2017-18203
>>   >   CVE-2018-3639
>>   >   CVE-2015-8830
>>   >   CVE-2012-6701
>>   >   CVE-2018-5803
>>   >   CVE-2018-1130
>>   > --
>>   >
>>   > Security Fix(es):
>>   >
>>   > * An industry-wide issue was found in the way many modern microprocessor
>>   > designs have implemented speculative execution of Load & Store
>>   > instructions (a commonly used performance optimization). It relies on the
>>   > presence of a precisely-defined instruction sequence in the privileged
>>   > code as well as the fact that memory read from address to which a recent
>>   > memory write has occurred may see an older value and subsequently cause 
>> an
>>   > update into the microprocessor's data cache even for speculatively
>>   > executed instructions that never actually commit (retire). As a result, 
>> an
>>   > unprivileged attacker could use this flaw to read privileged memory by
>>   > conducting targeted cache side-channel attacks. (CVE-2018-3639, PowerPC)
>>   >
>>   > * kernel: net/packet: overflow in check for priv area size 
>> (CVE-2017-7308)
>>   >
>>   > * kernel: AIO interface didn't use rw_verify_area() for checking 
>> mandatory
>>   > locking on files and size of access (CVE-2012-6701)
>>   >
>>   > * kernel: AIO write triggers integer overflow in some protocols
>>   > (CVE-2015-8830)
>>   >
>>   > * kernel: Null pointer dereference via keyctl (CVE-2016-8650)
>>   >
>>   > * kernel: ping socket / AF_LLC connect() sin_family race (CVE-2017-2671)
>>   >
>>   > * kernel: Race condition between multiple sys_perf_event_open() calls
>>   > (CVE-2017-6001)
>>   >
>>   > * kernel: Incorrect error handling in the set_mempolicy and mbind compat
>>   > syscalls in mm/mempolicy.c (CVE-2017-7616)
>>   >
>>   > * kernel: mm subsystem does not properly enforce the CONFIG_STRICT_DEVMEM
>>   > protection mechanism (CVE-2017-7889)
>>   >
>>   > * kernel: Double free in the inet_csk_clone_lock function in
>>   > net/ipv4/inet_connection_sock.c (CVE-2017-8890)
>>   >
>>   > * kernel: net: sctp_v6_create_accept_sk function mishandles inheritance
>>   > (CVE-2017-9075)
>>   >
>>   > * kernel: net: IPv6 DCCP implementation mishandles inheritance
>>   > (CVE-2017-9076)
>>   >
>>   > * kernel: net: tcp_v6_syn_recv_sock function mishandles inheritance
>>   > (CVE-2017-9077)
>>   >
>>   > * kernel: memory leak when merging buffers in SCSI IO vectors
>>   > (CVE-2017-12190)
>>   >
>>   > * kernel: vfs: BUG in truncate_inode_pages_range() and fuse client
>>   > (CVE-2017-15121)
>>   >
>>   > * kernel: Race condition in drivers/md/dm.c:dm_get_from_kobject() allows
>>   > local users to cause a denial of service (CVE-2017-18203)
>>   >
>>   > * kernel: a null pointer dereference in
>>   > net/dccp/output.c:dccp_write_xmit() leads to a system crash
>>   >

Re: Security ERRATA Important: kernel on SL6.x i386/x86_64

2018-07-03 Thread Valery Mitsyn 

Hi Scott,

thanks!
afs started and accessible now.
{{{
# modinfo openafs
filename: 
/lib/modules/2.6.32-754.el6.x86_64/kernel/fs/openafs/openafs.ko

license:http://www.openafs.org/dl/license10.html
srcversion: 44B6D0833299E389AA97BF6
depends:
vermagic:   2.6.32-754.el6.x86_64 SMP mod_unload modversions
}}}

But I'm still worried, now versions of kmod-openafs and other openafs
packages are different
{{{
# rpm -qa \*openafs\* | sort
kmod-openafs-1.6.22.3-1.SL610.el6.noarch
kmod-openafs-696-1.6.20-257.sl6.696.x86_64
kmod-openafs-754-1.6.22.3-286.sl6.754.x86_64
openafs-1.6.20-257.sl6.x86_64
openafs-client-1.6.20-257.sl6.x86_64
openafs-krb5-1.6.20-257.sl6.x86_64
openafs-module-tools-1.6.20-257.sl6.x86_64
}}}

On Tue, 3 Jul 2018, Scott Reid wrote:



HI Valery,

Thanks for the report!

kmod-openafs has been added to the security repo. Let us know if that doesn't 
solve your problem.

Thanks!

On 7/3/18, 10:29 AM, "owner-scientific-linux-us...@listserv.fnal.gov on behalf of Valery 
Mitsyn"  wrote:

   Oh! There are no kmod-openafs for this kernel.
   AFS does not start after the update.

   On Mon, 2 Jul 2018, Scott Reid wrote:

   > Synopsis:  Important: kernel security and bug fix update
   > Advisory ID:   SLSA-2018:1854-1
   > Issue Date:2018-06-19
   > CVE Numbers:   CVE-2016-8650
   >   CVE-2017-7308
   >   CVE-2017-6001
   >   CVE-2017-2671
   >   CVE-2017-7616
   >   CVE-2017-7889
   >   CVE-2017-8890
   >   CVE-2017-9076
   >   CVE-2017-9075
   >   CVE-2017-9077
   >   CVE-2017-12190
   >   CVE-2017-15121
   >   CVE-2017-18203
   >   CVE-2018-3639
   >   CVE-2015-8830
   >   CVE-2012-6701
   >   CVE-2018-5803
   >   CVE-2018-1130
   > --
   >
   > Security Fix(es):
   >
   > * An industry-wide issue was found in the way many modern microprocessor
   > designs have implemented speculative execution of Load & Store
   > instructions (a commonly used performance optimization). It relies on the
   > presence of a precisely-defined instruction sequence in the privileged
   > code as well as the fact that memory read from address to which a recent
   > memory write has occurred may see an older value and subsequently cause an
   > update into the microprocessor's data cache even for speculatively
   > executed instructions that never actually commit (retire). As a result, an
   > unprivileged attacker could use this flaw to read privileged memory by
   > conducting targeted cache side-channel attacks. (CVE-2018-3639, PowerPC)
   >
   > * kernel: net/packet: overflow in check for priv area size (CVE-2017-7308)
   >
   > * kernel: AIO interface didn't use rw_verify_area() for checking mandatory
   > locking on files and size of access (CVE-2012-6701)
   >
   > * kernel: AIO write triggers integer overflow in some protocols
   > (CVE-2015-8830)
   >
   > * kernel: Null pointer dereference via keyctl (CVE-2016-8650)
   >
   > * kernel: ping socket / AF_LLC connect() sin_family race (CVE-2017-2671)
   >
   > * kernel: Race condition between multiple sys_perf_event_open() calls
   > (CVE-2017-6001)
   >
   > * kernel: Incorrect error handling in the set_mempolicy and mbind compat
   > syscalls in mm/mempolicy.c (CVE-2017-7616)
   >
   > * kernel: mm subsystem does not properly enforce the CONFIG_STRICT_DEVMEM
   > protection mechanism (CVE-2017-7889)
   >
   > * kernel: Double free in the inet_csk_clone_lock function in
   > net/ipv4/inet_connection_sock.c (CVE-2017-8890)
   >
   > * kernel: net: sctp_v6_create_accept_sk function mishandles inheritance
   > (CVE-2017-9075)
   >
   > * kernel: net: IPv6 DCCP implementation mishandles inheritance
   > (CVE-2017-9076)
   >
   > * kernel: net: tcp_v6_syn_recv_sock function mishandles inheritance
   > (CVE-2017-9077)
   >
   > * kernel: memory leak when merging buffers in SCSI IO vectors
   > (CVE-2017-12190)
   >
   > * kernel: vfs: BUG in truncate_inode_pages_range() and fuse client
   > (CVE-2017-15121)
   >
   > * kernel: Race condition in drivers/md/dm.c:dm_get_from_kobject() allows
   > local users to cause a denial of service (CVE-2017-18203)
   >
   > * kernel: a null pointer dereference in
   > net/dccp/output.c:dccp_write_xmit() leads to a system crash
   > (CVE-2018-1130)
   >
   > * kernel: Missing length check of payload in
   > net/sctp/sm_make_chunk.c:_sctp_make_chunk() function allows denial of
   > service (CVE-2018-5803)
   > --
   >
   > SL6
   >  x86_64
   >kernel-2.6.32-754.el6.x86_64.rpm
   >kernel-debug-2.6.32-754.el6.x86_64.rpm
   >kernel-debug-debuginfo-2.6.32-754.el6.i686.rpm
   >kernel-debug-debuginfo-2.6.32-754.el6.x86_64.rpm
   >kernel-debug-devel-2.6.32-754.el6.i686.rpm
   >

Re: Security ERRATA Important: kernel on SL6.x i386/x86_64

2018-07-03 Thread Scott Reid 

HI Valery,

Thanks for the report!

kmod-openafs has been added to the security repo. Let us know if that doesn't 
solve your problem.

Thanks!

On 7/3/18, 10:29 AM, "owner-scientific-linux-us...@listserv.fnal.gov on behalf 
of Valery Mitsyn"  wrote:

Oh! There are no kmod-openafs for this kernel.
AFS does not start after the update.

On Mon, 2 Jul 2018, Scott Reid wrote:

> Synopsis:  Important: kernel security and bug fix update
> Advisory ID:   SLSA-2018:1854-1
> Issue Date:2018-06-19
> CVE Numbers:   CVE-2016-8650
>   CVE-2017-7308
>   CVE-2017-6001
>   CVE-2017-2671
>   CVE-2017-7616
>   CVE-2017-7889
>   CVE-2017-8890
>   CVE-2017-9076
>   CVE-2017-9075
>   CVE-2017-9077
>   CVE-2017-12190
>   CVE-2017-15121
>   CVE-2017-18203
>   CVE-2018-3639
>   CVE-2015-8830
>   CVE-2012-6701
>   CVE-2018-5803
>   CVE-2018-1130
> --
>
> Security Fix(es):
>
> * An industry-wide issue was found in the way many modern microprocessor
> designs have implemented speculative execution of Load & Store
> instructions (a commonly used performance optimization). It relies on the
> presence of a precisely-defined instruction sequence in the privileged
> code as well as the fact that memory read from address to which a recent
> memory write has occurred may see an older value and subsequently cause an
> update into the microprocessor's data cache even for speculatively
> executed instructions that never actually commit (retire). As a result, an
> unprivileged attacker could use this flaw to read privileged memory by
> conducting targeted cache side-channel attacks. (CVE-2018-3639, PowerPC)
>
> * kernel: net/packet: overflow in check for priv area size (CVE-2017-7308)
>
> * kernel: AIO interface didn't use rw_verify_area() for checking mandatory
> locking on files and size of access (CVE-2012-6701)
>
> * kernel: AIO write triggers integer overflow in some protocols
> (CVE-2015-8830)
>
> * kernel: Null pointer dereference via keyctl (CVE-2016-8650)
>
> * kernel: ping socket / AF_LLC connect() sin_family race (CVE-2017-2671)
>
> * kernel: Race condition between multiple sys_perf_event_open() calls
> (CVE-2017-6001)
>
> * kernel: Incorrect error handling in the set_mempolicy and mbind compat
> syscalls in mm/mempolicy.c (CVE-2017-7616)
>
> * kernel: mm subsystem does not properly enforce the CONFIG_STRICT_DEVMEM
> protection mechanism (CVE-2017-7889)
>
> * kernel: Double free in the inet_csk_clone_lock function in
> net/ipv4/inet_connection_sock.c (CVE-2017-8890)
>
> * kernel: net: sctp_v6_create_accept_sk function mishandles inheritance
> (CVE-2017-9075)
>
> * kernel: net: IPv6 DCCP implementation mishandles inheritance
> (CVE-2017-9076)
>
> * kernel: net: tcp_v6_syn_recv_sock function mishandles inheritance
> (CVE-2017-9077)
>
> * kernel: memory leak when merging buffers in SCSI IO vectors
> (CVE-2017-12190)
>
> * kernel: vfs: BUG in truncate_inode_pages_range() and fuse client
> (CVE-2017-15121)
>
> * kernel: Race condition in drivers/md/dm.c:dm_get_from_kobject() allows
> local users to cause a denial of service (CVE-2017-18203)
>
> * kernel: a null pointer dereference in
> net/dccp/output.c:dccp_write_xmit() leads to a system crash
> (CVE-2018-1130)
>
> * kernel: Missing length check of payload in
> net/sctp/sm_make_chunk.c:_sctp_make_chunk() function allows denial of
> service (CVE-2018-5803)
> --
>
> SL6
>  x86_64
>kernel-2.6.32-754.el6.x86_64.rpm
>kernel-debug-2.6.32-754.el6.x86_64.rpm
>kernel-debug-debuginfo-2.6.32-754.el6.i686.rpm
>kernel-debug-debuginfo-2.6.32-754.el6.x86_64.rpm
>kernel-debug-devel-2.6.32-754.el6.i686.rpm
>kernel-debug-devel-2.6.32-754.el6.x86_64.rpm
>kernel-debuginfo-2.6.32-754.el6.i686.rpm
>kernel-debuginfo-2.6.32-754.el6.x86_64.rpm
>kernel-debuginfo-common-i686-2.6.32-754.el6.i686.rpm
>kernel-debuginfo-common-x86_64-2.6.32-754.el6.x86_64.rpm
>kernel-devel-2.6.32-754.el6.x86_64.rpm
>kernel-headers-2.6.32-754.el6.x86_64.rpm
>perf-2.6.32-754.el6.x86_64.rpm
>perf-debuginfo-2.6.32-754.el6.i686.rpm
>perf-debuginfo-2.6.32-754.el6.x86_64.rpm
>python-perf-debuginfo-2.6.32-754.el6.i686.rpm
>python-perf-debuginfo-2.6.32-754.el6.x86_64.rpm
>python-perf-2.6.32-754.el6.x86_64.rpm
>  i386
>

Re: Security ERRATA Important: kernel on SL6.x i386/x86_64

2018-07-03 Thread Stephan Wiesand 
> On 3. Jul 2018, at 17:29, Valery Mitsyn  wrote:
> 
> Oh! There are no kmod-openafs for this kernel.
> AFS does not start after the update.
> 
> On Mon, 2 Jul 2018, Scott Reid wrote:
[...]
>> SL6
>> x86_64
>>   kernel-2.6.32-754.el6.x86_64.rpm

It's the 6.10 kernel. You can find kmod-openafs packages in 6rolling. But yes, 
they should probably be added to the updates/security repo.

Best regards,
Stephan

-- 
Stephan Wiesand
DESY -DV-
Platanenallee 6
15738 Zeuthen, Germany

Re: Security ERRATA Important: kernel on SL6.x i386/x86_64

2018-07-03 Thread Valery Mitsyn 

Oh! There are no kmod-openafs for this kernel.
AFS does not start after the update.

On Mon, 2 Jul 2018, Scott Reid wrote:


Synopsis:  Important: kernel security and bug fix update
Advisory ID:   SLSA-2018:1854-1
Issue Date:2018-06-19
CVE Numbers:   CVE-2016-8650
  CVE-2017-7308
  CVE-2017-6001
  CVE-2017-2671
  CVE-2017-7616
  CVE-2017-7889
  CVE-2017-8890
  CVE-2017-9076
  CVE-2017-9075
  CVE-2017-9077
  CVE-2017-12190
  CVE-2017-15121
  CVE-2017-18203
  CVE-2018-3639
  CVE-2015-8830
  CVE-2012-6701
  CVE-2018-5803
  CVE-2018-1130
--

Security Fix(es):

* An industry-wide issue was found in the way many modern microprocessor
designs have implemented speculative execution of Load & Store
instructions (a commonly used performance optimization). It relies on the
presence of a precisely-defined instruction sequence in the privileged
code as well as the fact that memory read from address to which a recent
memory write has occurred may see an older value and subsequently cause an
update into the microprocessor's data cache even for speculatively
executed instructions that never actually commit (retire). As a result, an
unprivileged attacker could use this flaw to read privileged memory by
conducting targeted cache side-channel attacks. (CVE-2018-3639, PowerPC)

* kernel: net/packet: overflow in check for priv area size (CVE-2017-7308)

* kernel: AIO interface didn't use rw_verify_area() for checking mandatory
locking on files and size of access (CVE-2012-6701)

* kernel: AIO write triggers integer overflow in some protocols
(CVE-2015-8830)

* kernel: Null pointer dereference via keyctl (CVE-2016-8650)

* kernel: ping socket / AF_LLC connect() sin_family race (CVE-2017-2671)

* kernel: Race condition between multiple sys_perf_event_open() calls
(CVE-2017-6001)

* kernel: Incorrect error handling in the set_mempolicy and mbind compat
syscalls in mm/mempolicy.c (CVE-2017-7616)

* kernel: mm subsystem does not properly enforce the CONFIG_STRICT_DEVMEM
protection mechanism (CVE-2017-7889)

* kernel: Double free in the inet_csk_clone_lock function in
net/ipv4/inet_connection_sock.c (CVE-2017-8890)

* kernel: net: sctp_v6_create_accept_sk function mishandles inheritance
(CVE-2017-9075)

* kernel: net: IPv6 DCCP implementation mishandles inheritance
(CVE-2017-9076)

* kernel: net: tcp_v6_syn_recv_sock function mishandles inheritance
(CVE-2017-9077)

* kernel: memory leak when merging buffers in SCSI IO vectors
(CVE-2017-12190)

* kernel: vfs: BUG in truncate_inode_pages_range() and fuse client
(CVE-2017-15121)

* kernel: Race condition in drivers/md/dm.c:dm_get_from_kobject() allows
local users to cause a denial of service (CVE-2017-18203)

* kernel: a null pointer dereference in
net/dccp/output.c:dccp_write_xmit() leads to a system crash
(CVE-2018-1130)

* kernel: Missing length check of payload in
net/sctp/sm_make_chunk.c:_sctp_make_chunk() function allows denial of
service (CVE-2018-5803)
--

SL6
 x86_64
   kernel-2.6.32-754.el6.x86_64.rpm
   kernel-debug-2.6.32-754.el6.x86_64.rpm
   kernel-debug-debuginfo-2.6.32-754.el6.i686.rpm
   kernel-debug-debuginfo-2.6.32-754.el6.x86_64.rpm
   kernel-debug-devel-2.6.32-754.el6.i686.rpm
   kernel-debug-devel-2.6.32-754.el6.x86_64.rpm
   kernel-debuginfo-2.6.32-754.el6.i686.rpm
   kernel-debuginfo-2.6.32-754.el6.x86_64.rpm
   kernel-debuginfo-common-i686-2.6.32-754.el6.i686.rpm
   kernel-debuginfo-common-x86_64-2.6.32-754.el6.x86_64.rpm
   kernel-devel-2.6.32-754.el6.x86_64.rpm
   kernel-headers-2.6.32-754.el6.x86_64.rpm
   perf-2.6.32-754.el6.x86_64.rpm
   perf-debuginfo-2.6.32-754.el6.i686.rpm
   perf-debuginfo-2.6.32-754.el6.x86_64.rpm
   python-perf-debuginfo-2.6.32-754.el6.i686.rpm
   python-perf-debuginfo-2.6.32-754.el6.x86_64.rpm
   python-perf-2.6.32-754.el6.x86_64.rpm
 i386
   kernel-2.6.32-754.el6.i686.rpm
   kernel-debug-2.6.32-754.el6.i686.rpm
   kernel-debug-debuginfo-2.6.32-754.el6.i686.rpm
   kernel-debug-devel-2.6.32-754.el6.i686.rpm
   kernel-debuginfo-2.6.32-754.el6.i686.rpm
   kernel-debuginfo-common-i686-2.6.32-754.el6.i686.rpm
   kernel-devel-2.6.32-754.el6.i686.rpm
   kernel-headers-2.6.32-754.el6.i686.rpm
   perf-2.6.32-754.el6.i686.rpm
   perf-debuginfo-2.6.32-754.el6.i686.rpm
   python-perf-debuginfo-2.6.32-754.el6.i686.rpm
   python-perf-2.6.32-754.el6.i686.rpm
 noarch
   kernel-abi-whitelists-2.6.32-754.el6.noarch.rpm
   kernel-doc-2.6.32-754.el6.noarch.rpm
   kernel-firmware-2.6.32-754.el6.noarch.rpm

- Scientific Linux Development Team



---
Best regards,
 Valery Mitsyn

RE: Security ERRATA Important: kernel on SL6.x i386/x86_64

2018-06-11 Thread Bill Maidment 
Thanks Akemi (and Johnny)
Changing the SL6 CPU to Opteron-G3 worked like a charm.
Cheers
Bill
 
-Original message-
> From:Akemi Yagi 
> Sent: Tuesday 12th June 2018 8:43
> To: Bill Maidment 
> Cc: scientific-linux-us...@listserv.fnal.gov 
> ; 
> scientific-linux-err...@listserv.fnal.gov 
> 
> Subject: Re: Security ERRATA Important: kernel on SL6.x i386/x86_64
> 
> On Tue, May 22, 2018 at 7:20 PM, Bill Maidment  wrote:
> > Hi
> > The new kernel caused
> > PANIC early exception 0d 10 . error 0 rc2
> > on a KVM SL 6.9 x86_64 guest
> > AMD server and all other guests running SL7.5 are all runn ing OK on their 
> > new kernel
> >
> > Reverting to the previous SL 6.9 kernel gave me back my guest machine
> > Cheers
> > Bill
> 
> This is a known bug. There is a workaround. For more details, see this
> post from Johnny Hughes:
> 
> https://lists.centos.org/pipermail/centos/2018-June/169058.html
> 
> Akemi
> 
>

Re: Security ERRATA Important: kernel on SL6.x i386/x86_64

2018-06-11 Thread Akemi Yagi 
On Tue, May 22, 2018 at 7:20 PM, Bill Maidment  wrote:
> Hi
> The new kernel caused
> PANIC early exception 0d 10 . error 0 rc2
> on a KVM SL 6.9 x86_64 guest
> AMD server and all other guests running SL7.5 are all runn ing OK on their 
> new kernel
>
> Reverting to the previous SL 6.9 kernel gave me back my guest machine
> Cheers
> Bill

This is a known bug. There is a workaround. For more details, see this
post from Johnny Hughes:

https://lists.centos.org/pipermail/centos/2018-June/169058.html

Akemi

RE: Security ERRATA Important: kernel on SL6.x i386/x86_64

2018-05-22 Thread Bill Maidment 
Hi
The new kernel caused
PANIC early exception 0d 10 . error 0 rc2
on a KVM SL 6.9 x86_64 guest
AMD server and all other guests running SL7.5 are all runn ing OK on their new 
kernel

Reverting to the previous SL 6.9 kernel gave me back my guest machine
Cheers
Bill
 
 
-Original message-
> From:Scott Reid 
> Sent: Wednesday 23rd May 2018 4:33
> To: scientific-linux-err...@listserv.fnal.gov
> Subject: Security ERRATA Important: kernel on SL6.x i386/x86_64
> 
> Synopsis:  Important: kernel security and bug fix update
> Advisory ID:   SLSA-2018:1651-1
> Issue Date:    2018-05-22
> CVE Numbers:   CVE-2018-3639
> --
> 
> Security Fix(es):
> 
> * An industry-wide issue was found in the way many modern microprocessor
> designs have implemented speculative execution of Load & Store
> instructions (a commonly used performance optimization). It relies on the
> presence of a precisely-defined instruction sequence in the privileged
> code as well as the fact that memory read from address to which a recent
> memory write has occurred may see an older value and subsequently cause an
> update into the microprocessor's data cache even for speculatively
> executed instructions that never actually commit (retire). As a result, an
> unprivileged attacker could use this flaw to read privileged memory by
> conducting targeted cache side-channel attacks. (CVE-2018-3639)
> 
> Note: This issue is present in hardware and cannot be fully fixed via
> software update. The updated kernel packages provide software side of the
> mitigation for this hardware issue. To be fully functional, up-to-date CPU
> microcode applied on the system is required.
> 
> In this update mitigations for x86 (both 32 and 64 bit) architecture are
> provided.
> 
> Bug Fix(es):
> 
> * Previously, an erroneous code in the x86 kexec system call path caused a
> memory corruption. As a consequence, the system became unresponsive with
> the following kernel stack trace:
> 
> 'WARNING: CPU: 13 PID: 36409 at lib/list_debug.c:59
> __list_del_entry+0xa1/0xd0 list_del corruption. prev->next should be
> dd03fddeeca0, but was (null)'
> 
> This update ensures that the code does not corrupt memory. As a result,
> the operating system no longer hangs.
> --
> 
> SL6
>   x86_64
>     kernel-2.6.32-696.30.1.el6.x86_64.rpm
>     kernel-debug-2.6.32-696.30.1.el6.x86_64.rpm
>     kernel-debug-debuginfo-2.6.32-696.30.1.el6.i686.rpm
>     kernel-debug-debuginfo-2.6.32-696.30.1.el6.x86_64.rpm
>     kernel-debug-devel-2.6.32-696.30.1.el6.i686.rpm
>     kernel-debug-devel-2.6.32-696.30.1.el6.x86_64.rpm
>     kernel-debuginfo-2.6.32-696.30.1.el6.i686.rpm
>     kernel-debuginfo-2.6.32-696.30.1.el6.x86_64.rpm
>     kernel-debuginfo-common-i686-2.6.32-696.30.1.el6.i686.rpm
>     kernel-debuginfo-common-x86_64-2.6.32-696.30.1.el6.x86_64.rpm
>     kernel-devel-2.6.32-696.30.1.el6.x86_64.rpm
>     kernel-headers-2.6.32-696.30.1.el6.x86_64.rpm
>     perf-2.6.32-696.30.1.el6.x86_64.rpm
>     perf-debuginfo-2.6.32-696.30.1.el6.i686.rpm
>     perf-debuginfo-2.6.32-696.30.1.el6.x86_64.rpm
>     python-perf-debuginfo-2.6.32-696.30.1.el6.i686.rpm
>     python-perf-debuginfo-2.6.32-696.30.1.el6.x86_64.rpm
>     python-perf-2.6.32-696.30.1.el6.x86_64.rpm
>   i386
>     kernel-2.6.32-696.30.1.el6.i686.rpm
>     kernel-debug-2.6.32-696.30.1.el6.i686.rpm
>     kernel-debug-debuginfo-2.6.32-696.30.1.el6.i686.rpm
>     kernel-debug-devel-2.6.32-696.30.1.el6.i686.rpm
>     kernel-debuginfo-2.6.32-696.30.1.el6.i686.rpm
>     kernel-debuginfo-common-i686-2.6.32-696.30.1.el6.i686.rpm
>     kernel-devel-2.6.32-696.30.1.el6.i686.rpm
>     kernel-headers-2.6.32-696.30.1.el6.i686.rpm
>     perf-2.6.32-696.30.1.el6.i686.rpm
>     perf-debuginfo-2.6.32-696.30.1.el6.i686.rpm
>     python-perf-debuginfo-2.6.32-696.30.1.el6.i686.rpm
>     python-perf-2.6.32-696.30.1.el6.i686.rpm
>   noarch
>     kernel-abi-whitelists-2.6.32-696.30.1.el6.noarch.rpm
>     kernel-doc-2.6.32-696.30.1.el6.noarch.rpm
>     kernel-firmware-2.6.32-696.30.1.el6.noarch.rpm
> 
> - Scientific Linux Development Team
> 
>

Re: Security ERRATA Important: kernel on SL6.x i386/x86_64

2017-06-21 Thread Mark Stodola 
This particular email was sent to the errata list, but the reply-to 
header is set to the users lists...


On 06/21/2017 02:47 AM, Bill Maidment wrote:

Aha.
Thanks for that. How many mailing lists do we need???
I got confused (not difficult at my age) as the response came on the User list.

Anyway, I echo the response. The team always seems to be on top of security 
issues.
Thank you (and the community) for being so friendly and helpful.

Cheers
Bill

-Original message-

From:Hans Kristian Rosbach <ha...@raskesider.no>
Sent: Wednesday 21st June 2017 17:30
To: Bill Maidment <b...@maidment.me>; scientific-linux-us...@listserv.fnal.gov
Subject: Re: Security ERRATA Important: kernel on SL6.x i386/x86_64

I think that mail came from the
scientific-linux-err...@listserv.fnal.gov list, so you might
have been removed from that list for some reason, but not from the users
list for example.

--
  Hans Kristian Rosbach
  Servebolt.com / Raske Sider

On 06/21/2017 12:41 AM, Bill Maidment wrote:

Hi. Is there something wrong with this mailing list? I received this response, 
but I never received the original message. This is not the first time I have 
noticed this.
Cheers
Bill


-Original message-

From:Stephan Wiesand <stephan.wies...@desy.de>
Sent: Wednesday 21st June 2017 2:58
To: scientific-linux-us...@listserv.fnal.gov
Subject: Re: Security ERRATA Important: kernel on SL6.x i386/x86_64

Kudos to the SL team at FNAL for once again getting the updates for a really 
nasty issue out incredibly quickly. Impressive.

--
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany

RE: Security ERRATA Important: kernel on SL6.x i386/x86_64

2017-06-21 Thread Bill Maidment 
Aha.
Thanks for that. How many mailing lists do we need???
I got confused (not difficult at my age) as the response came on the User list.

Anyway, I echo the response. The team always seems to be on top of security 
issues.
Thank you (and the community) for being so friendly and helpful.

Cheers
Bill 
 
-Original message-
> From:Hans Kristian Rosbach <ha...@raskesider.no>
> Sent: Wednesday 21st June 2017 17:30
> To: Bill Maidment <b...@maidment.me>; scientific-linux-us...@listserv.fnal.gov
> Subject: Re: Security ERRATA Important: kernel on SL6.x i386/x86_64
> 
> I think that mail came from the 
> scientific-linux-err...@listserv.fnal.gov list, so you might
> have been removed from that list for some reason, but not from the users 
> list for example.
> 
> -- 
>   Hans Kristian Rosbach
>   Servebolt.com / Raske Sider
> 
> On 06/21/2017 12:41 AM, Bill Maidment wrote:
> > Hi. Is there something wrong with this mailing list? I received this 
> > response, but I never received the original message. This is not the first 
> > time I have noticed this.
> > Cheers
> > Bill
> >   
> >   
> > -Original message-
> >> From:Stephan Wiesand <stephan.wies...@desy.de>
> >> Sent: Wednesday 21st June 2017 2:58
> >> To: scientific-linux-us...@listserv.fnal.gov
> >> Subject: Re: Security ERRATA Important: kernel on SL6.x i386/x86_64
> >>
> >> Kudos to the SL team at FNAL for once again getting the updates for a 
> >> really nasty issue out incredibly quickly. Impressive.
> >>
> >> -- 
> >> Stephan Wiesand
> >> DESY -DV-
> >> Platanenenallee 6
> >> 15738 Zeuthen, Germany
> >>
> >>
> 
>

Re: Security ERRATA Important: kernel on SL6.x i386/x86_64

2017-06-21 Thread Hans Kristian Rosbach 
I think that mail came from the 
scientific-linux-err...@listserv.fnal.gov list, so you might
have been removed from that list for some reason, but not from the users 
list for example.


--
 Hans Kristian Rosbach
 Servebolt.com / Raske Sider

On 06/21/2017 12:41 AM, Bill Maidment wrote:

Hi. Is there something wrong with this mailing list? I received this response, 
but I never received the original message. This is not the first time I have 
noticed this.
Cheers
Bill
  
  
-Original message-

From:Stephan Wiesand <stephan.wies...@desy.de>
Sent: Wednesday 21st June 2017 2:58
To: scientific-linux-us...@listserv.fnal.gov
Subject: Re: Security ERRATA Important: kernel on SL6.x i386/x86_64

Kudos to the SL team at FNAL for once again getting the updates for a really 
nasty issue out incredibly quickly. Impressive.

--
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany

RE: Security ERRATA Important: kernel on SL6.x i386/x86_64

2017-06-20 Thread Bill Maidment 
Yeah I got that message on 17th, so I guess it may depend on who is sending the 
messages from SL
Cheers
Bill
 
 
-Original message-
> From:O'Neal, Miles <miles.on...@cirrus.com>
> Sent: Wednesday 21st June 2017 9:13
> To: Steven J. Yellin <yel...@slac.stanford.edu>; Bill Maidment 
> <b...@maidment.me>
> Cc: scientific-linux-us...@listserv.fnal.gov
> Subject: Re: Security ERRATA Important: kernel on SL6.x i386/x86_64
> 
> The SL email system was also broken for
 
>   a while. A message came through about that within the last couple
 
>   of days.
 
>   
 
>   On 06/20/2017 06:04 PM, Steven J. Yellin wrote:
 
>     Last November I was "automatically removed from
 
>   the SCIENTIFIC-LINUX-USERS list (Mailing list for Scientific Linux
 
>   users worldwide)  as a result of repeated delivery error reports
 
>   from your mail system."  So one possibility is that your mail
 
>   system is occasionally failing to deliver mail to you from this
 
>   list, but you haven't yet been removed.  In my case, the reason
 
>   was that the listserver sometimes sends email with a header longer
 
>   than 32768 bytes, which the SLAC mail system couldn't handle. 
 
>   FermiLab said such long headers are becoming necessary because
 
>   "cloud systems that everyone has and will be moving to, add
 
>   additional diagnostic info in the headers so if people report any
 
>   errors, they can more easily be diagnosed."  The solution was to
 
>   convince the managers of SLAC's mail system to increase their
 
>   incoming header size parameter.
 
>   
 
>   
 
>   Steven Yellin
 
>   
 
>   
 
>   On Wed, 21 Jun 2017, Bill Maidment wrote:
 
>   
 
>   
 
>   Hi. Is there something wrong with this
 
> mailing list? I received this response, but I never received the
 
> original message. This is not the first time I have noticed
 
> this.
 
> 
 
>   
 
>   Cheers
 
> 
 
> Bill
 
> 
 
> 
 
> 
 
> -Original message-
 
> 
 
> From:Stephan Wiesand
 
>   <stephan.wies...@desy.de> <mailto:stephan.wies...@desy.de>
 
>   
 
>       Sent: Wednesday 21st June 2017 2:58
 
>   
 
>   To: scientific-linux-us...@listserv.fnal.gov 
><mailto:scientific-linux-us...@listserv.fnal.gov>
 
>   
 
>   Subject: Re: Security ERRATA Important: kernel on SL6.x
 
>   i386/x86_64
 
>   
 
>   
 
>   Kudos to the SL team at FNAL for once again getting the
 
>   updates for a really nasty issue out incredibly quickly.
 
>   Impressive.
 
>   
 
>   
 
>   --
 
>   
 
>   Stephan Wiesand
 
>   
 
>   DESY -DV-
 
>   
 
>   Platanenenallee 6
 
>   
 
>   15738 Zeuthen, Germany
 
>   
 
>   
 
>   
 
> 
 
> 
 
> 
 
> -- 
 
>   Miles O'Neal
 
>   CAD Systems Engineer
 
>   Cirrus Logic | cirrus.com | 1.512.851.4659

RE: Security ERRATA Important: kernel on SL6.x i386/x86_64

2017-06-20 Thread Bill Maidment 
Well, I'm running postfix with the default header_size_limit of 102,400, so I 
don't think that's the issue and there are no reject messages in the mail logs 
to indicate any problem. It seems that the mailing list is not always sending 
me the emails.
Another mystery from the bowels of technology!
Cheers
Bill 
 
-Original message-
> From:Steven J. Yellin <yel...@slac.stanford.edu>
> Sent: Wednesday 21st June 2017 9:04
> To: Bill Maidment <b...@maidment.me>
> Cc: scientific-linux-us...@listserv.fnal.gov
> Subject: RE: Security ERRATA Important: kernel on SL6.x i386/x86_64
> 
>  Last November I was "automatically removed from the 
> SCIENTIFIC-LINUX-USERS list (Mailing list for Scientific Linux users 
> worldwide)  as a result of repeated delivery error reports from your mail 
> system."  So one possibility is that your mail system is occasionally 
> failing to deliver mail to you from this list, but you haven't yet been 
> removed.  In my case, the reason was that the listserver sometimes sends 
> email with a header longer than 32768 bytes, which the SLAC mail system 
> couldn't handle.  FermiLab said such long headers are becoming necessary 
> because "cloud systems that everyone has and will be moving to, add 
> additional diagnostic info in the headers so if people report any errors, 
> they can more easily be diagnosed."  The solution was to convince the 
> managers of SLAC's mail system to increase their incoming header size 
> parameter.
> 
> Steven Yellin
> 
> On Wed, 21 Jun 2017, Bill Maidment wrote:
> 
> > Hi. Is there something wrong with this mailing list? I received this 
> > response, but I never received the original message. This is not the 
> > first time I have noticed this.
> 
> > Cheers
> > Bill
> >
> >
> > -Original message-
> >> From:Stephan Wiesand <stephan.wies...@desy.de>
> >> Sent: Wednesday 21st June 2017 2:58
> >> To: scientific-linux-us...@listserv.fnal.gov
> >> Subject: Re: Security ERRATA Important: kernel on SL6.x i386/x86_64
> >>
> >> Kudos to the SL team at FNAL for once again getting the updates for a 
> >> really nasty issue out incredibly quickly. Impressive.
> >>
> >> --
> >> Stephan Wiesand
> >> DESY -DV-
> >> Platanenenallee 6
> >> 15738 Zeuthen, Germany
> >>
> >>
> >
> 
>

Re: Security ERRATA Important: kernel on SL6.x i386/x86_64

2017-06-20 Thread O'Neal, Miles 
The SL email system was also broken for a while. A message came through 
about that within the last couple of days.


On 06/20/2017 06:04 PM, Steven J. Yellin wrote:
Last November I was "automatically removed from the 
SCIENTIFIC-LINUX-USERS list (Mailing list for Scientific Linux users 
worldwide)  as a result of repeated delivery error reports from your 
mail system."  So one possibility is that your mail system is 
occasionally failing to deliver mail to you from this list, but you 
haven't yet been removed.  In my case, the reason was that the 
listserver sometimes sends email with a header longer than 32768 
bytes, which the SLAC mail system couldn't handle. FermiLab said such 
long headers are becoming necessary because "cloud systems that 
everyone has and will be moving to, add additional diagnostic info in 
the headers so if people report any errors, they can more easily be 
diagnosed."  The solution was to convince the managers of SLAC's mail 
system to increase their incoming header size parameter.


Steven Yellin

On Wed, 21 Jun 2017, Bill Maidment wrote:

Hi. Is there something wrong with this mailing list? I received this 
response, but I never received the original message. This is not the 
first time I have noticed this.



Cheers
Bill


-Original message-

From:Stephan Wiesand <stephan.wies...@desy.de>
Sent: Wednesday 21st June 2017 2:58
To: scientific-linux-us...@listserv.fnal.gov
Subject: Re: Security ERRATA Important: kernel on SL6.x i386/x86_64

Kudos to the SL team at FNAL for once again getting the updates for 
a really nasty issue out incredibly quickly. Impressive.


--
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany







--
Miles O'Neal
CAD Systems Engineer
Cirrus Logic | cirrus.com | 1.512.851.4659

RE: Security ERRATA Important: kernel on SL6.x i386/x86_64

2017-06-20 Thread Steven J. Yellin 
Last November I was "automatically removed from the 
SCIENTIFIC-LINUX-USERS list (Mailing list for Scientific Linux users 
worldwide)  as a result of repeated delivery error reports from your mail 
system."  So one possibility is that your mail system is occasionally 
failing to deliver mail to you from this list, but you haven't yet been 
removed.  In my case, the reason was that the listserver sometimes sends 
email with a header longer than 32768 bytes, which the SLAC mail system 
couldn't handle.  FermiLab said such long headers are becoming necessary 
because "cloud systems that everyone has and will be moving to, add 
additional diagnostic info in the headers so if people report any errors, 
they can more easily be diagnosed."  The solution was to convince the 
managers of SLAC's mail system to increase their incoming header size 
parameter.


Steven Yellin

On Wed, 21 Jun 2017, Bill Maidment wrote:

Hi. Is there something wrong with this mailing list? I received this 
response, but I never received the original message. This is not the 
first time I have noticed this.



Cheers
Bill


-Original message-

From:Stephan Wiesand <stephan.wies...@desy.de>
Sent: Wednesday 21st June 2017 2:58
To: scientific-linux-us...@listserv.fnal.gov
Subject: Re: Security ERRATA Important: kernel on SL6.x i386/x86_64

Kudos to the SL team at FNAL for once again getting the updates for a really 
nasty issue out incredibly quickly. Impressive.

--
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany

RE: Security ERRATA Important: kernel on SL6.x i386/x86_64

2017-06-20 Thread Bill Maidment 
Hi. Is there something wrong with this mailing list? I received this response, 
but I never received the original message. This is not the first time I have 
noticed this.
Cheers
Bill
 
 
-Original message-
> From:Stephan Wiesand <stephan.wies...@desy.de>
> Sent: Wednesday 21st June 2017 2:58
> To: scientific-linux-us...@listserv.fnal.gov
> Subject: Re: Security ERRATA Important: kernel on SL6.x i386/x86_64
> 
> Kudos to the SL team at FNAL for once again getting the updates for a really 
> nasty issue out incredibly quickly. Impressive.
> 
> -- 
> Stephan Wiesand
> DESY -DV-
> Platanenenallee 6
> 15738 Zeuthen, Germany
> 
>