Re: Bug#889098: enforce fs.protected_hardlinks in sysctl.d by default

[Craig Small]

Hi Antoine (and kernel and security teams),
  Thanks for giving me the background as it's a kernel vulnerability not a
Procps one I wasn't aware of it.

The change to Procps is pretty simple but given that you need to be running
a non Debian kernel without this parameter what's groups' opinion of the
urgency?

I can throw in the sysctl configuration file and upload a release this
weekend if the consensus is it's needed or wait for the next upstream
Procps release which would be a month or so away.

 - Craig

>
>
>

-- 
Craig Small https://dropbear.xyz/ csmall at : dropbear.xyz
Debian GNU/Linuxhttps://www.debian.org/   csmall at : debian.org
Mastodon: @smalls...@social.dropbear.xyz Twitter: @smallsees
GPG fingerprint:  5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5

Re: enforce fs.protected_hardlinks in sysctl.d by default

[Antoine Beaupré]

On 2018-02-02 21:25:31, Moritz Mühlenhoff wrote:
> Antoine Beaupré wrote:
>> There are, however, people *not* running Debian-built kernels, and
>> sometimes for good reasons. This is a configuration that we should
>> still support.
>
> Is it supported, but it's also clearly documented that people need to
> enable this sysctl for custom kernels:
> https://www.debian.org/releases/jessie/amd64/release-notes/ch-whats-new.en.html#security

True. I guess what I'm arguing for is to do this explicitly from here
on.

>> Incidentally, I wonder if we should remove the patch we have on the
>> Debian kernels to change the defaults, and instead rely on the
>> sysctl. I have added the kernel team in CC to have their input.
>
> Why revert the kernel? That doesn't buy us anything. It would be
> better to ask upstream to revisit this decision (e.g. by contacting
> KSPP mailing list). I suppose that SuSE, Ubuntu and Red Hat have
> are shipping similar patches/defaults, so it's probably safe to say
> that those protections are now the status quo (as opposed to five
> years ago when that feature was freshly introduced).

It was just an idea: I'm fine with keeping the patch and I think it's a
good idea to enforce this in two places, to keep defense in depth.

I'm not sure I want to go through the emotional trauma of trying to
bring this upstream, unfortunately. ;)

Thanks for the response.

A.

-- 
All governments are run by liars and nothing they say should be
believed.
   - I. F. Stone

Re: enforce fs.protected_hardlinks in sysctl.d by default

[Moritz Mühlenhoff]

Antoine Beaupré wrote:
> There are, however, people *not* running Debian-built kernels, and
> sometimes for good reasons. This is a configuration that we should
> still support.

Is it supported, but it's also clearly documented that people need to
enable this sysctl for custom kernels:
https://www.debian.org/releases/jessie/amd64/release-notes/ch-whats-new.en.html#security

> Incidentally, I wonder if we should remove the patch we have on the
> Debian kernels to change the defaults, and instead rely on the
> sysctl. I have added the kernel team in CC to have their input.

Why revert the kernel? That doesn't buy us anything. It would be
better to ask upstream to revisit this decision (e.g. by contacting
KSPP mailing list). I suppose that SuSE, Ubuntu and Red Hat have
are shipping similar patches/defaults, so it's probably safe to say
that those protections are now the status quo (as opposed to five
years ago when that feature was freshly introduced).

Cheers,
Moritz

Bug#886556: linux-image-4.15.0-rc5-amd64: NULL pointer dereference in ecc_gen_privkey [ecdh_generic] at boot

[Salvatore Bonaccorso]

Control: tags -1 + confirmed pending fixed-upstream

Hi

On Sun, Jan 07, 2018 at 06:23:40PM +0200, Mihai Basa wrote:
> Package: src:linux
> Version: 4.15~rc5-1~exp1
> Severity: important
> Tags: patch
> 
> On boot, a NULL pointer dereference is encountered in ecc_gen_privkey in
> the ecdh_generic module, on a Lenovo T430.
> The system blocks for about 2 minutes with the attached error screens,
> after which boot continues, but with a few missing systems (ethernet and
> bluetooth, at least), and locks up completely when shutting down.
> 
> The problem is debugged and a patch provided (by someone other
> than me) at: *https://patchwork.kernel.org/patch/10054807/
> *
> 
> Their patch (attached) hasn't appeared in the mainline kernel yet,
> even though I it's been declared accepted since 2017-11-29.
> 
> All kernels from 4.13 up to the latest 4.15-rc5, manifest this bug on my
> laptop. Kernel version 4.12 is the latest that does not exhibit it.

The commit has landed in mainline now with
4c0e22c90510308433272d7ba281b1eb4eda8209.

Regards,
Salvatore

Processed: Re: Bug#886556: linux-image-4.15.0-rc5-amd64: NULL pointer dereference in ecc_gen_privkey [ecdh_generic] at boot

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + confirmed pending fixed-upstream
Bug #886556 [src:linux] linux-image-4.15.0-rc5-amd64: NULL pointer dereference 
in ecc_gen_privkey [ecdh_generic] at boot
Added tag(s) confirmed, pending, and fixed-upstream.

-- 
886556: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886556
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: reassign 889146 to src:linux

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 889146 src:linux 3.2.96-3
Bug #889146 [linux-image-3.2.0-5-amd64] smartctl - Read Device Identity failed
Warning: Unknown package 'linux-image-3.2.0-5-amd64'
Bug reassigned from package 'linux-image-3.2.0-5-amd64' to 'src:linux'.
No longer marked as found in versions 3.2.96-3.
Ignoring request to alter fixed versions of bug #889146 to the same values 
previously set
Bug #889146 [src:linux] smartctl - Read Device Identity failed
The source 'linux' and version '3.2.96-3' do not appear to match any binary 
packages
Marked as found in versions linux/3.2.96-3.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
889146: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889146
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#878221: linux-image-4.9.0-4-amd64: Screen flickers randomly with Radeon R9 270X since upgrade from 4.9.0-3 to 4.9.0-4

[besy]

As a side note: I still have some older kernel version from
stretch-backports on my PC. I tried it with the oldest one of these
kernels. The problem doesn't occur with the kernel "4.12.0-0.bpo.2-amd64
#1 SMP Debian 4.12.13-1~bpo9+1 (2017-09-28) x86_64 GNU/Linux".

Bug#878221: linux-image-4.9.0-4-amd64: Screen flickers randomly with Radeon R9 270X since upgrade from 4.9.0-3 to 4.9.0-4

[besy]

Am 29.01.2018 um 17:44 schrieb Yves-Alexis Perez:
> On Wed, 2017-10-11 at 11:05 +0200, Benjamin Sygnat wrote:
>> - The screen (Dell U2415, resolution 1920x1200) which is connected to my AMD
>> Radeon R9 270X (on DisplayPort-0) occasionally flickers every few seconds. 
>> The
>> flickering appears to be random.
> It seems that a lot of people experienced a similar experience with an Intel
> card using i915. For all those people, please see #884001 which should be
> fixed in stretch-pu soon.
>
> Please keep this bug for amd/radeon issue only.
>
> Benjamin, does this still happens on current version (4.9.65-3+deb9u2)?
>
> Regards,

Unfortunately, the problem persists with the current version
"4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) x86_64 GNU/Linux".

Bug#889129: .config:3186:warning: symbol value 'm' invalid for HW_RANDOM_TPM

[Mathieu Malaterre]

Source: linux
Version: 4.14.13-1
Severity: minor
User: debian-powe...@lists.debian.org
Usertags: powerpc

At least on my G4 Mac Mini, I can see:

$ cp /boot/config-4.14.0-3-powerpc .config
$ make savedefconfig
scripts/kconfig/conf  --savedefconfig=defconfig Kconfig
.config:3186:warning: symbol value 'm' invalid for HW_RANDOM_TPM

I have not check if this module value is valid for other system.

Reference:

commit 0c8eb822de35e14c404803bbd40bd48a81bedc1e
Author: Ben Hutchings 
Date:   Fri May 31 04:14:16 2013 +

Enable various new drivers and driver options

svn path=/dists/sid/linux/; revision=20152