SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
This commit zeroes out the unused memory region in the buffer_head
corresponding to the extent metablock after writing the extent header
and the corresponding extent node entries.
This is done to prevent random uninitialized data from getting into
the filesystem when the extent block is synced.
This fixes CVE-2019-11833.
This commit is already included in kernel 4.19.y in -current (was added in 4.19.45).
Last edited by mats_b_tegner; 06-11-2019 at 04:16 PM.
Fixed among others in Firefox 60.8esr and Firefox68: https://www.mozilla.org/en-US/securi...CVE-2019-11709
Maybe not "so" critical when you read "... we presume that with enough effort that some of these could be exploited to run arbitrary code." but it doesn't hurt to be safe. Anyway I have upgraded for Slint to 60.8esr.
PS now that 68.0 is also tagged esr, maybe Pat is weighing which one to provide for -current and -stable?
EDIT: looks like he decided to ship 68.0esr in both:
xap/mozilla-firefox-68.0esr-x86_64-1.txz: Upgraded.
patches/packages/mozilla-firefox-68.0esr-x86_64-1_slack14.2.txz: Upgraded.
And that needed to upgrade rust.
Last edited by Didier Spaier; 07-10-2019 at 07:41 PM.
Some applications set tiny SO_SNDBUF values and expect
TCP to just work. Recent patches to address CVE-2019-11478
broke them in case of losses, since retransmits might be prevented.
We should allow these flows to make progress.
This patch allows the first and last skb in retransmit queue
to be split even if memory limits are hit.
It also adds some room due to the fact that tcp_sendmsg()
and tcp_sendpage() might overshoot sk_wmem_queued by about one full
TSO skb (64KB size). Note this allowance was already present
in stable backports for kernels < 4.15
Note for < 4.15 backports :
tcp_rtx_queue_tail() will probably look like :
CVE-2019-12815: mod_copy Incorrect Access Control
Description: Issueing CPFR, CPTO commands to a ProFTPd server allows users without write permissions to copy any file on the FTP server.
According to news (http://www.bitdefender.com/news/bitd...sors-3722.html I've found, they've detected a new problem with Intel CPUs that doesn't have anything to do with Spectre and/or Meltdown, so isn't fixed by the current migations in the kernel.
According to news (http://www.bitdefender.com/news/bitd...sors-3722.html I've found, they've detected a new problem with Intel CPUs that doesn't have anything to do with Spectre and/or Meltdown, so isn't fixed by the current migations in the kernel.
This is the SWAPGS vulnerability (a Spectre V1 variant) as described in the previous mats_b_tegner detailed post.
It is fixed in kernel versions 4.19.65 (the last Slackware current kernel, updated today -- again a very timely update. Thanks Pat!) and 4.14.137.
The last 4.4 kernel (4.4.188) doesn't seem to have a fix for this (I don't know if it means that it is not vulnerable, or if the patch is to come later?) So for the moment Slackware 14.2 is out of luck regarding this vulnerability...
This is the SWAPGS vulnerability (a Spectre V1 variant) as described in the previous mats_b_tegner detailed post.
It is fixed in kernel versions 4.19.65 (the last Slackware current kernel, updated today -- again a very timely update. Thanks Pat!) and 4.14.137.
The last 4.4 kernels (4.4.188) doesn't seem to have a fix for this (I don't know if it means that it is not vulnerable, or if the patch is to come later?) So for the moment Slackware 14.2 is out of luck regarding this vulnerability...
Update 2019-08-14:
Kernel 4.4.189 packages are available now and it includes Spectre v1 SWAPGS mitigations (CVE 2019-1125)
Security Fixes
A race condition could trigger an assertion failure when a large number of incoming packets were being rejected. This flaw is disclosed in CVE-2019-6471. [GL #942]
There are multiple vulnerabilities about Cross-Site Scripting (XSS) in jQuery shipped with RDoc which bundled in Ruby. All Ruby users are recommended to update Ruby to the latest release which includes the fixed version of RDoc.
Details
The following vulnerabilities have been reported.
CVE-2012-6708
CVE-2015-9251
It is strongly recommended for all Ruby users to upgrade your Ruby installation or take one of the following workarounds as soon as possible. You also have to re-generate existing RDoc documentation to completely mitigate the vulnerabilities.
Affected Versions
Ruby 2.3 series: all
Ruby 2.4 series: 2.4.6 and earlier
Ruby 2.5 series: 2.5.5 and earlier
Ruby 2.6 series: 2.6.3 and earlier
Major changes between OpenSSL 1.0.2s and OpenSSL 1.0.2t [10 Sep 2019]
o Fixed a padding oracle in PKCS7_dataDecode and CMS_decrypt_set1_pkey
(CVE-2019-1563)
o For built-in EC curves, ensure an EC_GROUP built from the curve name is
used even when parsing explicit parameters
o Compute ECC cofactors if not provided during EC_GROUP construction
(CVE-2019-1547)
o Document issue with installation paths in diverse Windows builds
(CVE-2019-1552)
Didn't know where to throw this and hope it'll be helpful, even if Slackware & its kernel (nothing available yet) cannot help.
There's a freshly discovered vulnerability (side channel attack), dubbed NetCAT - CVE-2019-11184, affecting only Intel Xeon E5, E7 and SP families that support DDIO and RDMA.
One of the mitigations is to disable (BIOS?) the DDIO and RDMA extensions.
More about these extensions: https://www.intel.com/content/dam/ww...ct-i-o-faq.pdf https://www.intel.com/content/dam/ww...logy-brief.pdf
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
