Bug#854652: marked as done (linux kernel 4.9 causes xserver to crash)

2017-02-08 Thread Debian Bug Tracking System 
Your message dated Wed, 8 Feb 2017 22:10:34 -0600
with message-id 

and subject line Never mind, user error.
has caused the Debian Bug report #854652,
regarding linux kernel 4.9 causes xserver to crash
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
854652: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854652
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: linux-image-4.9.0-1-amd64
Version: 4.9.2-2

Xserver, entire desktop works great for kernel 4.8 but crashes hard on
kernel 4.9 Thus I am reporting this as a kernel bug, instead of an
xserver-xorg bug.

Full contents of /var/log/Xorg.0.log at bottom. But first, a manual diff:

the failed version says this (starting at line 221 of the log file):

MULLINS, KAVERI, HAWAII
[29.553] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[29.553] (II) FBDEV: driver for framebuffer: fbdev
[29.553] (II) VESA: driver for VESA chipsets: vesa
[29.665] (II) modeset(G0): using drv /dev/dri/card0
[29.665] (II) Loading sub module "fbdevhw"
[29.665] (II) LoadModule: "fbdevhw"
[29.665] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[29.665] (II) Module fbdevhw: vendor="X.Org Foundation"
[29.665]compiled for 1.19.1, module version = 0.0.2
[29.665]ABI class: X.Org Video Driver, version 23.0
[29.665] (**) FBDEV(0): claimed PCI slot 4@0:0:0
[29.665] (II) FBDEV(0): using default device
[29.665] (WW) Falling back to old probe method for vesa
[29.666] (II) FBDEV(0): Creating default Display subsection in
Screen section
"Default Screen Section" for depth/fbbpp 24/32
[29.666] (==) FBDEV(0): Depth 24, (==) framebuffer bpp 32
[29.666] (==) FBDEV(0): RGB weight 888


The working version says this:

   MULLINS, KAVERI, HAWAII
[  6169.154] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[  6169.154] (II) FBDEV: driver for framebuffer: fbdev
[  6169.154] (II) VESA: driver for VESA chipsets: vesa
[  6169.154] (II) [KMS] Kernel modesetting enabled.
[  6169.164] (II) modeset(G0): using drv /dev/dri/card1
[  6169.164] (WW) Falling back to old probe method for fbdev
[  6169.164] (II) Loading sub module "fbdevhw"
[  6169.164] (II) LoadModule: "fbdevhw"
[  6169.164] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[  6169.164] (II) Module fbdevhw: vendor="X.Org Foundation"
[  6169.164]   compiled for 1.19.1, module version = 0.0.2
[  6169.164]   ABI class: X.Org Video Driver, version 23.0
[  6169.165] (WW) Falling back to old probe method for vesa
[  6169.165] (II) AMDGPU(0): Creating default Display subsection in
Screen section
   "Default Screen Section" for depth/fbbpp 24/32
[  6169.165] (==) AMDGPU(0): Depth 24, (--) framebuffer bpp 32
[  6169.165] (II) AMDGPU(0): Pixel depth = 24 bits stored in 4 bytes
(32 bpp pixmaps)
[  6169.165] (==) AMDGPU(0): Default visual is TrueColor
[  6169.165] (==) AMDGPU(0): RGB weight 888

The failing version explores FBDEV for some reason.  The machine hs
*two* graphics cards: some kind of cheap vga welded onto the
motherboard, and a radeon graphics card. These are the nice one:

04:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Tonga PRO [Radeon R9 285/380] (rev f1)

and cheapo welded-on:

01:01.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED
Graphics Family (rev 10)

so here's what is weird:  the failing log states:

[29.665] (**) FBDEV(0): claimed PCI slot 4@0:0:0
[29.666] (II) FBDEV(0): hardware: astdrmfb (video memory: 4076kB)

so pci slot 4 is the radeon card -- good.
so why is trying to use the ast (aspeed technologies) driver on it?
especially when it earlier tried and failed to find the ast driver:

[29.547] (==) Matched ast as autoconfigured driver 0
[29.547] (==) Matched ati as autoconfigured driver 1
[29.547] (==) Matched modesetting as autoconfigured driver 2
[29.547] (==) Matched fbdev as autoconfigured driver 3
[29.547] (==) Matched vesa as autoconfigured driver 4
[29.547] (==) Assigned the driver to the xf86ConfigLayout
[29.547] (II) LoadModule: "ast"
[29.547] (WW) Warning, couldn't open module ast
[29.547] (II) UnloadModule: "ast"
[29.547] (II) Unloading ast
[29.547] (EE) Failed to load module "ast" (module does not exist, 0)

Well, but this failure is "normal", because even on the good boot, the
ast module is not found, and that's just fine.  The difference is that
on the bad boot, the radeon graphics card is never seen by the
x-server. whereas on

Bug#854652: Never mind, user error

2017-02-08 Thread Linas Vepstas 
Foo. As the above messages carefully document, I was missing
amdgpu/tonga_k_smc.bin
Doing an
```
apt-get install firmware-amd-graphics
```
fixes the issue, and everything works fine in kernel 4.9.

Close this bug, its bogus.

--linas

Bug#854652: kernel logs for failing and good boot

2017-02-08 Thread Linas Vepstas 
Here are the kernel logs, foist for the failing boot, then a good boot.
The failing 4.9 boot concludes with this:

[8.928400] amdgpu :04:00.0: firmware: failed to load
amdgpu/tonga_k_smc.bin (-2)
[8.928982] amdgpu :04:00.0: Direct firmware load for
amdgpu/tonga_k_smc.bin failed with error -2
[8.929047] [drm:amdgpu_cgs_get_firmware_info [amdgpu]] *ERROR*
Failed to request firmware
[8.931250] [drm:amdgpu_device_init [amdgpu]] *ERROR* hw_init of IP
block  failed -22
[8.931924] amdgpu :04:00.0: amdgpu_init failed
[9.070724] [drm] amdgpu: ttm finalized
[9.070729] amdgpu :04:00.0: Fatal error during GPU init
[9.071176] [drm] amdgpu: finishing device.
[9.072293] amdgpu: probe of :04:00.0 failed with error -22

The full failing log (cat /var/log/kern.log |grep amdgpu)

[7.796676] [drm] amdgpu kernel modesetting enabled.
[7.796676] [drm] amdgpu kernel modesetting enabled.
[8.088460] amdgpu :04:00.0: firmware: direct-loading firmware
amdgpu/tonga_mc.bin
[8.088479] amdgpu :04:00.0: VRAM: 4096M 0x -
0x (4096M used)
[8.088482] amdgpu :04:00.0: GTT: 64455M 0x0001 -
0x0010BC7B
[8.088514] [drm] amdgpu: 4096M of VRAM memory ready
[8.088515] [drm] amdgpu: 64455M of GTT memory ready.
[8.090690] amdgpu :04:00.0: amdgpu: using MSI.
[8.090733] [drm] amdgpu: irq initialized.
[8.103523] amdgpu: powerplay initialized
[8.088460] amdgpu :04:00.0: firmware: direct-loading firmware
amdgpu/tonga_mc.bin
[8.088479] amdgpu :04:00.0: VRAM: 4096M 0x -
0x (4096M used)
[8.088482] amdgpu :04:00.0: GTT: 64455M 0x0001 -
0x0010BC7B
[8.088514] [drm] amdgpu: 4096M of VRAM memory ready
[8.088515] [drm] amdgpu: 64455M of GTT memory ready.
[8.090690] amdgpu :04:00.0: amdgpu: using MSI.
[8.090733] [drm] amdgpu: irq initialized.
[8.103523] amdgpu: powerplay initialized
[8.227899] amdgpu :04:00.0: firmware: direct-loading firmware
amdgpu/tonga_pfp.bin
[8.232122] amdgpu :04:00.0: firmware: direct-loading firmware
amdgpu/tonga_me.bin
[8.233481] amdgpu :04:00.0: firmware: direct-loading firmware
amdgpu/tonga_ce.bin
[8.236718] amdgpu :04:00.0: firmware: direct-loading firmware
amdgpu/tonga_rlc.bin
[8.243021] amdgpu :04:00.0: firmware: direct-loading firmware
amdgpu/tonga_mec.bin
[8.253097] amdgpu :04:00.0: firmware: direct-loading firmware
amdgpu/tonga_mec2.bin
[8.255167] amdgpu :04:00.0: fence driver on ring 0 use gpu
addr 0x00010008, cpu addr 0x9996e2693008
[8.255733] amdgpu :04:00.0: fence driver on ring 1 use gpu
addr 0x00010018, cpu addr 0x9996e2693018
[8.256248] amdgpu :04:00.0: fence driver on ring 2 use gpu
addr 0x00010028, cpu addr 0x9996e2693028
[8.256511] amdgpu :04:00.0: fence driver on ring 3 use gpu
addr 0x00010038, cpu addr 0x9996e2693038
[8.256772] amdgpu :04:00.0: fence driver on ring 4 use gpu
addr 0x00010048, cpu addr 0x9996e2693048
[8.257009] amdgpu :04:00.0: fence driver on ring 5 use gpu
addr 0x00010058, cpu addr 0x9996e2693058
[8.257272] amdgpu :04:00.0: fence driver on ring 6 use gpu
addr 0x00010068, cpu addr 0x9996e2693068
[8.257537] amdgpu :04:00.0: fence driver on ring 7 use gpu
addr 0x00010078, cpu addr 0x9996e2693078
[8.258034] amdgpu :04:00.0: fence driver on ring 8 use gpu
addr 0x00010088, cpu addr 0x9996e2693088
[8.261506] amdgpu :04:00.0: firmware: direct-loading firmware
amdgpu/tonga_sdma.bin
[8.282969] amdgpu :04:00.0: firmware: direct-loading firmware
amdgpu/tonga_sdma1.bin
[8.283235] amdgpu :04:00.0: fence driver on ring 9 use gpu
addr 0x00010098, cpu addr 0x9996e2693098
[8.283884] amdgpu :04:00.0: fence driver on ring 10 use gpu
addr 0x000100a8, cpu addr 0x9996e26930a8
[8.294951] amdgpu :04:00.0: firmware: direct-loading firmware
amdgpu/tonga_uvd.bin
[8.297786] amdgpu :04:00.0: fence driver on ring 11 use gpu
addr 0x07e747b0, cpu addr 0xb6c4ce24e7b0
[8.298894] amdgpu :04:00.0: firmware: direct-loading firmware
amdgpu/tonga_vce.bin
[8.299152] amdgpu :04:00.0: fence driver on ring 12 use gpu
addr 0x000100c8, cpu addr 0x9996e26930c8
[8.299287] amdgpu :04:00.0: fence driver on ring 13 use gpu
addr 0x000100d8, cpu addr 0x9996e26930d8
[8.928400] amdgpu :04:00.0: firmware: failed to load
amdgpu/tonga_k_smc.bin (-2)
[8.928982] amdgpu :04:00.0: Direct firmware load for
amdgpu/tonga_k_smc.bin failed with error -2
[8.929047] [drm:amdgpu_cgs_get_firmware_info [amdgpu]] *ERROR*
Failed to request firmware
[8.931250] [drm:amdgpu_device_init [amdgpu]] *ERROR* hw_init of IP
block  failed -22
[

Bug#854652: linux kernel 4.9 causes xserver to crash

2017-02-08 Thread Linas Vepstas 
Package: linux-image-4.9.0-1-amd64
Version: 4.9.2-2

Xserver, entire desktop works great for kernel 4.8 but crashes hard on
kernel 4.9 Thus I am reporting this as a kernel bug, instead of an
xserver-xorg bug.

Full contents of /var/log/Xorg.0.log at bottom. But first, a manual diff:

the failed version says this (starting at line 221 of the log file):

MULLINS, KAVERI, HAWAII
[29.553] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[29.553] (II) FBDEV: driver for framebuffer: fbdev
[29.553] (II) VESA: driver for VESA chipsets: vesa
[29.665] (II) modeset(G0): using drv /dev/dri/card0
[29.665] (II) Loading sub module "fbdevhw"
[29.665] (II) LoadModule: "fbdevhw"
[29.665] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[29.665] (II) Module fbdevhw: vendor="X.Org Foundation"
[29.665]compiled for 1.19.1, module version = 0.0.2
[29.665]ABI class: X.Org Video Driver, version 23.0
[29.665] (**) FBDEV(0): claimed PCI slot 4@0:0:0
[29.665] (II) FBDEV(0): using default device
[29.665] (WW) Falling back to old probe method for vesa
[29.666] (II) FBDEV(0): Creating default Display subsection in
Screen section
"Default Screen Section" for depth/fbbpp 24/32
[29.666] (==) FBDEV(0): Depth 24, (==) framebuffer bpp 32
[29.666] (==) FBDEV(0): RGB weight 888


The working version says this:

   MULLINS, KAVERI, HAWAII
[  6169.154] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[  6169.154] (II) FBDEV: driver for framebuffer: fbdev
[  6169.154] (II) VESA: driver for VESA chipsets: vesa
[  6169.154] (II) [KMS] Kernel modesetting enabled.
[  6169.164] (II) modeset(G0): using drv /dev/dri/card1
[  6169.164] (WW) Falling back to old probe method for fbdev
[  6169.164] (II) Loading sub module "fbdevhw"
[  6169.164] (II) LoadModule: "fbdevhw"
[  6169.164] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[  6169.164] (II) Module fbdevhw: vendor="X.Org Foundation"
[  6169.164]   compiled for 1.19.1, module version = 0.0.2
[  6169.164]   ABI class: X.Org Video Driver, version 23.0
[  6169.165] (WW) Falling back to old probe method for vesa
[  6169.165] (II) AMDGPU(0): Creating default Display subsection in
Screen section
   "Default Screen Section" for depth/fbbpp 24/32
[  6169.165] (==) AMDGPU(0): Depth 24, (--) framebuffer bpp 32
[  6169.165] (II) AMDGPU(0): Pixel depth = 24 bits stored in 4 bytes
(32 bpp pixmaps)
[  6169.165] (==) AMDGPU(0): Default visual is TrueColor
[  6169.165] (==) AMDGPU(0): RGB weight 888

The failing version explores FBDEV for some reason.  The machine hs
*two* graphics cards: some kind of cheap vga welded onto the
motherboard, and a radeon graphics card. These are the nice one:

04:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Tonga PRO [Radeon R9 285/380] (rev f1)

and cheapo welded-on:

01:01.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED
Graphics Family (rev 10)

so here's what is weird:  the failing log states:

[29.665] (**) FBDEV(0): claimed PCI slot 4@0:0:0
[29.666] (II) FBDEV(0): hardware: astdrmfb (video memory: 4076kB)

so pci slot 4 is the radeon card -- good.
so why is trying to use the ast (aspeed technologies) driver on it?
especially when it earlier tried and failed to find the ast driver:

[29.547] (==) Matched ast as autoconfigured driver 0
[29.547] (==) Matched ati as autoconfigured driver 1
[29.547] (==) Matched modesetting as autoconfigured driver 2
[29.547] (==) Matched fbdev as autoconfigured driver 3
[29.547] (==) Matched vesa as autoconfigured driver 4
[29.547] (==) Assigned the driver to the xf86ConfigLayout
[29.547] (II) LoadModule: "ast"
[29.547] (WW) Warning, couldn't open module ast
[29.547] (II) UnloadModule: "ast"
[29.547] (II) Unloading ast
[29.547] (EE) Failed to load module "ast" (module does not exist, 0)

Well, but this failure is "normal", because even on the good boot, the
ast module is not found, and that's just fine.  The difference is that
on the bad boot, the radeon graphics card is never seen by the
x-server. whereas on the good one, it is. For comparison, a working
boot looks like this:

[  6169.149] (II) Applying OutputClass "AMDgpu" to /dev/dri/card0
[  6169.149]   loading driver: amdgpu
[  6169.149] (==) Matched amdgpu as autoconfigured driver 0
[  6169.149] (==) Matched ati as autoconfigured driver 1
[  6169.149] (==) Matched ast as autoconfigured driver 2
[  6169.149] (==) Matched ati as autoconfigured driver 3
[  6169.149] (==) Matched modesetting as autoconfigured driver 4
[  6169.149] (==) Matched fbdev as autoconfigured driver 5
[  6169.149] (==) Matched vesa as autoconfigured driver 6
[  6169.150] (==) Assigned the driver to the xf86ConfigLayout
[  6169.150] (II) LoadModule: "amdgpu"
[  6169.150] (II) Loading /usr/lib/xorg/modules/drivers/amdgpu_drv.so

again, the working boot is with kernel 4.8; but the failing boot, with
kernel 4.9, the xserver never

Bug#854613: marked as done (linux-image-4.8.0-2-amd64: System hangs at "Loading initial ramdisk" after upgrading to 4.9)

2017-02-08 Thread Debian Bug Tracking System 
Your message dated Wed, 8 Feb 2017 14:55:08 -0800
with message-id

Bug#854613: linux-image-4.8.0-2-amd64: System hangs at "Loading initial ramdisk" after upgrading to 4.9

2017-02-08 Thread Jonathan Yu 
On Wed, Feb 8, 2017 at 1:19 PM, Ben Hutchings  wrote:

> Control: notfound -1 4.8.15-2
> Control: tag -1 moreinfo
>
> On Wed, 2017-02-08 at 09:17 -0800, Jonathan Yu wrote:
> > Package: src:linux
> > Version: 4.8.15-2
> [...]
>

Hey Ben,

Forgot to say: Thank you very much for your great work! I've never had any
trouble upgrading in the past, which is a testament to your hard work :)

>
> But this is the working version, not the broken versin.  Which 4.9.x
> version did you install?  If it is 4.9.2-2 (current in testing), please
> try 4.9.6-3 (current in unstable).
>

I'm using: ii  linux-image-4.9.0-1-amd644.9.2-2
 amd64Linux 4.9 for 64-bit PCs (signed)

I will upgrade to the version in unstable and try again, thanks for the
tip!

Here's my apt policy (I guess it might be helpful if this was included in
reportbug reports) - I use packages mostly from testing :)

$ apt policy
Package files:
 100 /var/lib/dpkg/status
 release a=now
 500 http://dl.google.com/linux/chrome/deb stable/main amd64 Packages
 release v=1.0,o=Google, Inc.,a=stable,n=stable,l=Google,c=main,b=amd64
 origin dl.google.com
 -10 http://ftp.us.debian.org/debian experimental/non-free i386 Packages
 release
o=Debian,a=experimental,n=experimental,l=Debian,c=non-free,b=i386
 origin ftp.us.debian.org
 -10 http://ftp.us.debian.org/debian experimental/non-free amd64 Packages
 release
o=Debian,a=experimental,n=experimental,l=Debian,c=non-free,b=amd64
 origin ftp.us.debian.org
 -10 http://ftp.us.debian.org/debian experimental/main i386 Packages
 release o=Debian,a=experimental,n=experimental,l=Debian,c=main,b=i386
 origin ftp.us.debian.org
 -10 http://ftp.us.debian.org/debian experimental/main amd64 Packages
 release o=Debian,a=experimental,n=experimental,l=Debian,c=main,b=amd64
 origin ftp.us.debian.org
 -10 http://ftp.us.debian.org/debian unstable/non-free i386 Packages
 release o=Debian,a=unstable,n=sid,l=Debian,c=non-free,b=i386
 origin ftp.us.debian.org
 -10 http://ftp.us.debian.org/debian unstable/non-free amd64 Packages
 release o=Debian,a=unstable,n=sid,l=Debian,c=non-free,b=amd64
 origin ftp.us.debian.org
 -10 http://ftp.us.debian.org/debian unstable/main i386 Packages
 release o=Debian,a=unstable,n=sid,l=Debian,c=main,b=i386
 origin ftp.us.debian.org
 -10 http://ftp.us.debian.org/debian unstable/main amd64 Packages
 release o=Debian,a=unstable,n=sid,l=Debian,c=main,b=amd64
 origin ftp.us.debian.org
 900 http://ftp.us.debian.org/debian testing/contrib i386 Packages
 release o=Debian,a=testing,n=stretch,l=Debian,c=contrib,b=i386
 origin ftp.us.debian.org
 900 http://ftp.us.debian.org/debian testing/contrib amd64 Packages
 release o=Debian,a=testing,n=stretch,l=Debian,c=contrib,b=amd64
 origin ftp.us.debian.org
 900 http://ftp.us.debian.org/debian testing/non-free i386 Packages
 release o=Debian,a=testing,n=stretch,l=Debian,c=non-free,b=i386
 origin ftp.us.debian.org
 900 http://ftp.us.debian.org/debian testing/non-free amd64 Packages
 release o=Debian,a=testing,n=stretch,l=Debian,c=non-free,b=amd64
 origin ftp.us.debian.org
 900 http://ftp.us.debian.org/debian testing/main i386 Packages
 release o=Debian,a=testing,n=stretch,l=Debian,c=main,b=i386
 origin ftp.us.debian.org
 900 http://ftp.us.debian.org/debian testing/main amd64 Packages
 release o=Debian,a=testing,n=stretch,l=Debian,c=main,b=amd64
 origin ftp.us.debian.org
Pinned packages:

Processed: Re: Bug#854613: linux-image-4.8.0-2-amd64: System hangs at "Loading initial ramdisk" after upgrading to 4.9

2017-02-08 Thread Debian Bug Tracking System 
Processing control commands:

> notfound -1 4.8.15-2
Bug #854613 [src:linux] linux-image-4.8.0-2-amd64: System hangs at "Loading 
initial ramdisk" after upgrading to 4.9
No longer marked as found in versions linux/4.8.15-2.
> tag -1 moreinfo
Bug #854613 [src:linux] linux-image-4.8.0-2-amd64: System hangs at "Loading 
initial ramdisk" after upgrading to 4.9
Added tag(s) moreinfo.

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

Bug#854613: linux-image-4.8.0-2-amd64: System hangs at "Loading initial ramdisk" after upgrading to 4.9

2017-02-08 Thread Ben Hutchings 
Control: notfound -1 4.8.15-2
Control: tag -1 moreinfo

On Wed, 2017-02-08 at 09:17 -0800, Jonathan Yu wrote:
> Package: src:linux
> Version: 4.8.15-2
[...]

But this is the working version, not the broken versin.  Which 4.9.x
version did you install?  If it is 4.9.2-2 (current in testing), please
try 4.9.6-3 (current in unstable).

Ben.

-- 
Ben Hutchings
Hoare's Law of Large Problems:
Inside every large problem is a small problem struggling to get
out.



signature.asc
Description: This is a digitally signed message part

Processed: Re: Bug#854421: systemd: "systemctl --user cat dirmngr.socket" produced garbage beyond # /dev/null

2017-02-08 Thread Debian Bug Tracking System 
Processing control commands:

> retitle 854421 [CVE-2017-5550] kernel dumps arbitrary memory when splice()ing 
> from /dev/null
Bug #854421 {Done: Ben Hutchings } [src:linux] kernel 
dumps arbitrary memory when splice()ing from /dev/null
Changed Bug title to '[CVE-2017-5550] kernel dumps arbitrary memory when 
splice()ing from /dev/null' from 'kernel dumps arbitrary memory when 
splice()ing from /dev/null'.

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

Bug#854421: systemd: "systemctl --user cat dirmngr.socket" produced garbage beyond # /dev/null

2017-02-08 Thread Daniel Kahn Gillmor 
Control: retitle 854421 [CVE-2017-5550] kernel dumps arbitrary memory when 
splice()ing from /dev/null

On Tue 2017-02-07 20:21:31 -0500, Ben Hutchings wrote:
> Control: reassign -1 src:linux 4.9.2-2
> Control: close -1 4.9.6-3
> Control: severity -1 serious
> Control: tag -1 security
>
> On Tue, 2017-02-07 at 11:14 -0500, Daniel Kahn Gillmor wrote:
>> On Tue 2017-02-07 10:49:39 -0500, Daniel Kahn Gillmor wrote:
>> > git clone https://0xacab.org/dkg/debian-bug-854421
>> > cd debian-bug-854421
>> > make
>> 
>> interestingly, on at least one machine i try this on, getting it to
>> reproduce is very infrequent with plain "make", even with the 20 tries
>> on kernel version 4.9.2-2.
>
> It's much less likely to happen if there's only one CPU.
>
>> however, "make strace" seems to tickle the bug further, and makes it
>> much more likely to reproduce on 4.9.2-2, even though it's only one
>> try.
>> 
>> with kernel 4.9.6-3 i haven't been able to reproduce it with either
>> "make" or "make strace".
>
> This is CVE-2017-5550, fixed by:
> https://git.kernel.org/linus/b9dc6f65bc5e232d1c05fe34b5daadc7e8bbf1fb

Thanks for tracking that down, Ben.  I can confirm that it's an infoleak
of the worst kind, unfortunately -- i filled the RAM of a root-owned
userspace process with an arbitrary string, and then triggered the dump
From a non-privileged process and managed to get copies of the arbitrary
string :(

   --dkg


signature.asc
Description: PGP signature

Bug#854613: linux-image-4.8.0-2-amd64: System hangs at "Loading initial ramdisk" after upgrading to 4.9

2017-02-08 Thread Jonathan Yu 
Package: src:linux
Version: 4.8.15-2
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

After upgrading my system (Debian testing) and rebooting, the system hangs at
"Loading initial ramdisk".

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I also tried editing the Grub boot parameters to remove "quiet splash", but
this did not produce any additional output. I'm happy to help troubleshoot
the problem and provide other diagnostics that you may need. I didn't see
anything useful in the systemd journal or dmesg for a successful boot. 

I'm currently booted with an older kernel that I had installed (4.8) and that
works fine.

   * What was the outcome of this action?

The system hangs.

   * What outcome did you expect instead?

I expected the system to boot normally.

Here are the contents of my /boot folder. I should be using Debian packages for
everything, except for Chrome Beta which I have installed via Google's 
repository.

$ ls -al /boot
total 72M
drwxr-xr-x.  5 root root 1.0K Jan 25 12:08 .
drwxr-xr-x. 22 root root 4.0K Jan 25 11:52 ..
-rw-r--r--   1 root root 180K Nov 12 20:38 config-4.8.0-1-amd64
-rw-r--r--   1 root root 180K Jan  4 11:39 config-4.8.0-2-amd64
-rw-r--r--   1 root root 182K Jan 12 07:52 config-4.9.0-1-amd64
drwx--   3 root root 4.0K Dec 31  1969 efi
drwxr-xr-x.  5 root root 1.0K Feb  8 08:56 grub
-rw---.  1 root root  13M Jun 12  2016 initramfs-4.6.0-1-amd64.img
-rw---   1 root root  13M Feb  8 08:56 initrd.img-4.8.0-1-amd64
-rw---   1 root root  13M Feb  8 08:56 initrd.img-4.8.0-2-amd64
-rw---   1 root root  13M Feb  8 08:56 initrd.img-4.9.0-1-amd64
drwx--.  2 root root  12K Feb 10  2016 lost+found
-rw-r--r--   1 root root 3.1M Nov 12 20:38 System.map-4.8.0-1-amd64
-rw-r--r--   1 root root 3.0M Jan  4 11:39 System.map-4.8.0-2-amd64
-rw-r--r--   1 root root 3.1M Jan 12 07:52 System.map-4.9.0-1-amd64
-rw-r--r--   1 root root 4.0M Nov 16 09:13 vmlinuz-4.8.0-1-amd64
-rw-r--r--   1 root root 4.0M Jan  5 20:14 vmlinuz-4.8.0-2-amd64
-rw-r--r--   1 root root 4.0M Jan 13 06:51 vmlinuz-4.9.0-1-amd64

*** End of the template - remove these template lines ***


-- Package-specific info:
** Version:
Linux version 4.8.0-2-amd64 (debian-kernel@lists.debian.org) (gcc version 5.4.1 
20161202 (Debian 5.4.1-4) ) #1 SMP Debian 4.8.15-2 (2017-01-04)

** Command line:
BOOT_IMAGE=/vmlinuz-4.8.0-2-amd64 root=/dev/mapper/theory--vg-theory--root ro 
quiet splash

** Not tainted

** Kernel log:
[   10.089155] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
[   10.089690] ip6_tables: (C) 2000-2006 Netfilter Core Team
[   10.090060] iwlwifi :03:00.0 wlp3s0: renamed from wlan0
[   10.226610] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   10.226611] Bluetooth: BNEP filters: protocol multicast
[   10.226614] Bluetooth: BNEP socket layer initialized
[   10.550151] IPv6: ADDRCONF(NETDEV_UP): enp0s25: link is not ready
[   10.566160] psmouse serio1: synaptics: queried max coordinates: x [..5676], 
y [..4758]
[   10.595881] psmouse serio1: synaptics: queried min coordinates: x [1266..], 
y [1096..]
[   10.653481] psmouse serio1: synaptics: Touchpad model: 1, fw: 8.1, id: 
0x1e2b1, caps: 0xf003a3/0x943300/0x12e800/0x1, board id: 3053, fw id: 2560
[   10.653488] psmouse serio1: synaptics: serio: Synaptics pass-through port at 
isa0060/serio1/input0
[   10.690881] input: SynPS/2 Synaptics TouchPad as 
/devices/platform/i8042/serio1/input/input8
[   10.793849] IPv6: ADDRCONF(NETDEV_UP): enp0s25: link is not ready
[   10.797434] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[   10.799530] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[   10.799784] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[   11.013734] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[   11.013995] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[   11.035325] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[   11.045690] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[   11.045976] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[   11.257971] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[   11.258233] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[   11.273130] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[   11.281949] bridge: automatic filtering via arp/ip/ip6tables has been 
deprecated. Update your scripts to load br_netfilter if you need this.
[   11.299334] IPv6: ADDRCONF(NETDEV_UP): vmnat: link is not ready
[   11.355302] Ebtables v2.0 registered
[   11.436688] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[   12.817758] thinkpad_acpi: docked into hotplug port replicator
[   13.693745] usb 4-5: new SuperSpeed USB device number 2 using xhci_hcd
[   13.719705] usb 4-5: New USB device found, idVendor=17ef, idProduct=1010
[   13.719710] usb 4-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   13.719713] usb 4-5: Product:

Bug#773976: marked as done (ALPM between Intel 8 AHCI and Micron M550 causes errors)

2017-02-08 Thread Debian Bug Tracking System 
Your message dated Wed, 08 Feb 2017 12:30:01 +0100
with message-id <871sv8rkcm@wavexx.thregr.org>
and subject line Re: Bug#773976: Aggressive link power management breaks 
devices without sleep support
has caused the Debian Bug report #773976,
regarding ALPM between Intel 8 AHCI and Micron M550 causes errors
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
773976: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773976
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:linux
Version: 3.16.7-ckt2-1
Severity: important

I've recently switched to a laptop with an Intel 8 SATA controller (AHCI).

I was experiencing significant latency delays, which I tracked down to the
aggressive link power management. It looks like that the SSD that came with the
laptop (A Micron M550 by looking at the device model) doesn't support full
device sleep:

ahci :00:1f.2: port does not support device sleep

When setting the host controller to min_power (as done by laptop-mode-tools),
the following often happens as the link is transitions back from the SLUMBER
state:

ata1.00: exception Emask 0x0 SAct 0x400 SErr 0x5 action 0x6 frozen
ata1: SError: { PHYRdyChg CommWake }
ata1.00: failed command: WRITE FPDMA QUEUED
ata1.00: cmd 61/08:d0:48:7f:96/00:00:08:00:00/40 tag 26 ncq 4096 out res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: hard resetting link

It might take as long as 7 seconds for the device to become responsive again.
This behavior eventually resulted in a corrupted EXT4 filesystem, thus I'm
flagging this as important.

Shouldn't the driver avoid entering the lower power levels if it knows that
there's a connected device doesn't support it?

-- Package-specific info:
** Version:
Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 
4.8.3 (Debian 4.8.3-16) ) #1 SMP Debian 3.16.7-ckt2-1 (2014-12-08)

** Command line:
BOOT_IMAGE=/vmlinuz-3.16.0-4-amd64 root=/dev/mapper/root-root ro 
acpi_backlight=vendor quiet

** Not tainted

** Kernel log:
[   11.866422] e1000e :00:19.0: irq 63 for MSI/MSI-X
[   11.866518] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   11.887862] input: PS/2 Generic Mouse as 
/devices/platform/i8042/serio2/input/input9
[   11.894431] usb 2-7: new high-speed USB device number 4 using xhci_hcd
[   12.161676] usb 2-7: New USB device found, idVendor=05c8, idProduct=0369
[   12.161678] usb 2-7: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   12.161679] usb 2-7: Product: HP HD Webcam
[   12.161680] usb 2-7: Manufacturer: SunplusIT INC.
[   12.170758] Console: switching to colour frame buffer device 200x56
[   12.173985] i915 :00:02.0: fb0: inteldrmfb frame buffer device
[   12.173988] i915 :00:02.0: registered panic notifier
[   12.243546] media: Linux media interface: v0.10
[   12.246713] Linux video capture interface: v2.00
[   12.254935] uvcvideo: Found UVC 1.00 device HP HD Webcam (05c8:0369)
[   12.263572] input: HP HD Webcam as 
/devices/pci:00/:00:14.0/usb2/2-7/2-7:1.0/input/input19
[   12.263643] usbcore: registered new interface driver uvcvideo
[   12.263645] USB Video Class driver (1.1.1)
[   12.342965] usb 3-3: new SuperSpeed USB device number 2 using xhci_hcd
[   12.359268] usb 3-3: New USB device found, idVendor=0424, idProduct=5534
[   12.359272] usb 3-3: New USB device strings: Mfr=2, Product=3, SerialNumber=0
[   12.359275] usb 3-3: Product: USB5534B
[   12.359276] usb 3-3: Manufacturer: SMSC
[   12.360325] hub 3-3:1.0: USB hub found
[   12.360364] hub 3-3:1.0: 4 ports detected
[   12.360527] usb: failed to peer 3-3-port1 and usb2-port1 by location 
(3-3-port1:none) (usb2-port1:usb3-port1)
[   12.360528] usb 3-3-port1: failed to peer to usb2-port1 (-16)
[   12.360587] usb: failed to peer 3-3-port2 and usb2-port1 by location 
(3-3-port2:none) (usb2-port1:usb3-port1)
[   12.360588] usb 3-3-port2: failed to peer to usb2-port1 (-16)
[   12.471044] usb 1-1: new high-speed USB device number 2 using ehci-pci
[   12.595218] input: ST LIS3LV02DL Accelerometer as 
/devices/platform/lis3lv02d/input/input20
[   12.603521] usb 1-1: New USB device found, idVendor=8087, idProduct=8000
[   12.603526] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[   12.603814] hub 1-1:1.0: USB hub found
[   12.603901] hub 1-1:1.0: 8 ports detected
[   12.615136] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
[   12.615323] input: Video Bus as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input21
[   12.615397] [drm] Initialized