Bug#998035: linux-image-5.10.0-9-amd64: Debian 11 in Xen PV DomU crashes intel_pmc_core on boot, DomU zombiefies.

2021-10-28 Thread Dr . Nagy Elemér Károly 
Package: linux-image-5.10.0-9-amd64
Version: linux-image-5.10.0-9-amd64 and linux-image-5.14.0-0.bpo.2-amd64
Severity: important

Dear All,

I am reporting this bug mostly to help others with the same problem, proposing
adding a warning to the Debian 11 release notes and hoping for an upstream
kernel bugfix.

Description: Debian 11 Xen PV DomU (RAM<4GB) does not correctly shuts down
because of a intel_pmc_core module problems on Intel Xeon E3-1230 (and possibly
other Intel CPUs).

https://github.com/QubesOS/qubes-issues/issues/6052 seems to be the same issue.

Workarounds:
* Use a Debian 10 kernel in the DomU, which works
* Allocate 4+ GB RAM to the DomU
* Use PVH instead of PV (needs Xen 4.9+, and is the preferred way since Xen
4.10)

Please note:
* Backports kernel (linux-image-5.14.0-0.bpo.2-amd64) suffers from the same
problem.
* Debian 10 Dom0 Xen 4.11.4+107-gef32c7afa2-1 beheaves the same way
* Debian 9 Dom0 Xen 4.8.5.final+shim4.10.4-1+deb9u12 used PVHv1, which differs
from PVHv2 used by Xen 4.09+

Test case:
* Install Debian 10 or Debian 11, install Xen, create a PV config as below and
upon startup "BUG: unable to handle page fault for address" is displayed and it
fails to stop with "poweroff" later.
kernel = "/usr/lib/grub-xen/grub-x86_64-xen.bin"
extra = '(hd1)/boot/grub/grub.cfg'
* Change PV to PVH and it works correctly:
kernel = "/root/xen/images/debian11/vmlinuz-5.10.0-9-amd64"
ramdisk = "/root/xen/images/debian11/initrd.img-5.10.0-9-amd64"
type = 'pvh'

The full bug in my case:
[3.088164] BUG: unable to handle page fault for address: c9004049b818
[3.088175] #PF: supervisor read access in kernel mode
[3.088179] #PF: error_code(0x) - not-present page
[3.088183] PGD 7fbd9067 P4D 7fbd9067 PUD 5186067 PMD 5303067 PTE 0
[3.088191] Oops:  [#1] SMP NOPTI
[3.088195] CPU: 0 PID: 201 Comm: systemd-udevd Not tainted 5.10.0-9-amd64
#1 Debian 5.10.70-1
[3.088204] RIP: e030:pmc_core_probe+0x136/0x410 [intel_pmc_core]
[3.088209] Code: c0 48 c7 c7 48 a6 3c c0 e8 c7 25 d2 c0 48 8b 05 b0 7a 00
00 48 c7 83 88 00 00 00 20 a6 3c c0 48 63 40 50 48 03 05 92 7a 00 00 <8b> 00 48
8b 15 91 7a 00 00 48 c7 c7 e0 54 3c c0 8b 4a 54 ba 01 00
[3.088222] RSP: e02b:c9004026fc30 EFLAGS: 00010286
[3.088226] RAX: c9004049b818 RBX: 88800b028400 RCX:
fe002000
[3.088232] RDX: c03ca600 RSI: c03c41f6 RDI:
c03ca648
[3.088238] RBP: 88800b028410 R08:  R09:
fe001fff
[3.088244] R10: 7ff0 R11: 888008e01740 R12:

[3.088249] R13:  R14: 0006 R15:

[3.088260] FS:  7f94ad4928c0() GS:88807d40()
knlGS:
[3.088267] CS:  e030 DS:  ES:  CR0: 80050033
[3.088271] CR2: c9004049b818 CR3: 075d4000 CR4:
00050660
[3.088281] Call Trace:
[3.088288]  platform_drv_probe+0x35/0x80
[3.088294]  really_probe+0x37b/0x480
[3.088299]  driver_probe_device+0xe1/0x150
[3.088303]  ? driver_allows_async_probing+0x50/0x50
[3.088308]  bus_for_each_drv+0x7e/0xc0
[3.088313]  __device_attach+0xd8/0x1d0
[3.088317]  bus_probe_device+0x8e/0xa0
[3.088321]  device_add+0x399/0x840
[3.088325]  platform_device_add+0x105/0x230
[3.088331]  ? 0xc0327000
[3.088351]  pmc_core_platform_init+0x78/0x1000 [intel_pmc_core_pltdrv]
[3.088358]  do_one_initcall+0x44/0x1d0
[3.088363]  ? do_init_module+0x23/0x260
[3.088381]  ? kmem_cache_alloc_trace+0xf5/0x200
[3.088386]  do_init_module+0x5c/0x260
[3.088391]  __do_sys_finit_module+0xb1/0x110
[3.088397]  do_syscall_64+0x33/0x80
[3.088402]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[3.088407] RIP: 0033:0x7f94ad94b9b9
[3.088411] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89
f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 8b 0d a7 54 0c 00 f7 d8 64 89 01 48
[3.088423] RSP: 002b:7ffde7aa3158 EFLAGS: 0246 ORIG_RAX:
0139
[3.088430] RAX: ffda RBX: 563dc68d1530 RCX:
7f94ad94b9b9
[3.088435] RDX:  RSI: 7f94adad6e2d RDI:
0018
[3.088441] RBP: 0002 R08:  R09:
563dc689c9d0
[3.088447] R10: 0018 R11: 0246 R12:
7f94adad6e2d
[3.088453] R13:  R14: 563dc68ce450 R15:
563dc68d1530
[3.088459] Modules linked in: intel_pmc_core_pltdrv(+) intel_pmc_core
ghash_clmulni_intel evdev aesni_intel libaes crypto_simd cryptd glue_helper
pcspkr drm fuse configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2
crc32c_generic crct10dif_pclmul crct10dif_common crc32_pclmul xen_netfront
xen_blkfront crc32c_intel
[3.088487] CR2: c9004049b818
[3.088491] ---[ end trace dd3aec620db68a1d ]---
[3.088496] RIP: e030:pmc_core_probe+0x136/0x410

[bts-link] source package src:linux

2021-10-28 Thread debian-bts-link 
#
# bts-link upstream status pull for source package src:linux
# see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
# https://bts-link-team.pages.debian.net/bts-link/
#

user debian-bts-l...@lists.debian.org

# remote status report for #995773 (http://bugs.debian.org/995773)
# Bug title: intel_iommu hangs some old HPE Server
#  * http://bugzilla.kernel.org/show_bug.cgi?id=214795
#  * remote status changed: (?) -> NEW
usertags 995773 + status-NEW

thanks

Bug#998005: marked as done (Regression: bad handling of permission in directory with sticky bit)

2021-10-28 Thread Debian Bug Tracking System 
Your message dated Thu, 28 Oct 2021 16:52:51 +0200
with message-id <40ee0df0-deb3-4765-e204-2ccef7818...@debian.org>
and subject line Re: Bug#998005: Regression: bad handling of permission in 
directory with sticky bit
has caused the Debian Bug report #998005,
regarding Regression: bad handling of permission in directory with sticky bit
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.)


-- 
998005: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998005
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:linux
Version: 5.14.12-1
Severity: normal

Hi,

One of my users reports me a strange file access problem:
In a directory with sticky bit such as /tmp, the write
permission he can set on one of his (plain) file is ignored.
He cannot allow another user to write in its file (no ACL
are involved).

I dig into this issue and, indeed, I observe this stange
behavior. The sticky bit in directory change file rename
and deletion, ok. But it should not change write access.

I wrote the attached script. I run it on ubuntu live 14,
ubuntu live 20 and on my laptop (sid). The script has been
run in /tmp (sticky bit) and /home/$USER (no sticky bit).
[users and groups have been changed for the runs on the sid
machine]
  Access problems occur in /tmp on ubuntu live 20 and sid,
but not on /home (all systems) nor on ubuntu live 14 in
/tmp (old kernel)

The results are in the attachments.

Here is an extract with one problematic result:
vdanjean@eyak:/tmp$ id -un
vdanjean
vdanjean@eyak:/tmp$ ls -ld .
drwxrwxrwt 368 root root 196608 28 oct.  14:39 .
vdanjean@eyak:/tmp$ ls -l essai 
-rw-rw-rw- 1 cbardel cbardel 4 28 oct.  13:33 essai
vdanjean@eyak:/tmp$ echo ok >> essai
bash: essai: Permission non accordée

With 0666 permission, anybody should be able to write
in the file (even if the containing directory has a
sticky bit)

Do you confirm this is a bug? Do you want I look
for the first kernel in Debian with this regression?

  Regards
Vincent
#!/bin/bash

LC_ALL=C

FILE=essai
OTHER_USER=toto
SHARED_GROUP=ubuntu
PRIVATE_GROUP=toto

display() {
echo "+ $*"
"$@"
}

check() {
display ls -l $FILE
cat $FILE > /dev/null || echo "READ FORBIDEN $1"
echo ok >> $FILE || echo "WRITE FORBIDEN $2"
}

display uname -a
display id
display id $OTHER_USER
display ls -ld $(pwd)
echo "foo" > $FILE

sudo chown $OTHER_USER $FILE
sudo chgrp $SHARED_GROUP $FILE

sudo chmod 660 $FILE
check "" "WHY?"

sudo chmod 666 $FILE
check "" "WHY?"

sudo chmod 606 $FILE
check "OK" "OK"


sudo chgrp $PRIVATE_GROUP $FILE

sudo chmod 660 $FILE
check "OK" "OK"

sudo chmod 666 $FILE
check "" "WHY?"

sudo chmod 606 $FILE
check "" "WHY?"
+ uname -a
Linux ubuntu 4.4.0-142-generic #168~14.04.1-Ubuntu SMP Sat Jan 19 11:26:28 UTC 
2019 x86_64 x86_64 x86_64 GNU/Linux
+ id
uid=999(ubuntu) gid=999(ubuntu) 
groups=999(ubuntu),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),108(lpadmin),124(sambashare)
+ id toto
uid=1000(toto) gid=1000(toto) groups=1000(toto),999(ubuntu)
+ ls -ld /home/ubuntu
drwxr-xr-x 15 ubuntu ubuntu 480 oct.  28 12:01 /home/ubuntu
+ ls -l essai
-rw-rw 1 toto ubuntu 4 oct.  28 12:01 essai
+ ls -l essai
-rw-rw-rw- 1 toto ubuntu 7 oct.  28 12:01 essai
+ ls -l essai
-rwrw- 1 toto ubuntu 10 oct.  28 12:01 essai
cat: essai: Permission denied
READ FORBIDEN OK
/home/ubuntu/test-perms: line 18: essai: Permission denied
WRITE FORBIDEN OK
+ ls -l essai
-rw-rw 1 toto toto 10 oct.  28 12:01 essai
cat: essai: Permission denied
READ FORBIDEN OK
/home/ubuntu/test-perms: line 18: essai: Permission denied
WRITE FORBIDEN OK
+ ls -l essai
-rw-rw-rw- 1 toto toto 10 oct.  28 12:01 essai
+ ls -l essai
-rwrw- 1 toto toto 13 oct.  28 12:01 essai
+ uname -a
Linux ubuntu 4.4.0-142-generic #168~14.04.1-Ubuntu SMP Sat Jan 19 11:26:28 UTC 
2019 x86_64 x86_64 x86_64 GNU/Linux
+ id
uid=999(ubuntu) gid=999(ubuntu) 
groups=999(ubuntu),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),108(lpadmin),124(sambashare)
+ id toto
uid=1000(toto) gid=1000(toto) groups=1000(toto),999(ubuntu)
+ ls -ld /tmp
drwxrwxrwt 4 root root 200 oct.  28 12:01 /tmp
+ ls -l essai
-rw-rw 1 toto ubuntu 4 oct.  28 12:01 essai
+ ls -l essai
-rw-rw-rw- 1 toto ubuntu 7 oct.  28 12:01 essai
+ ls -l essai
-rwrw- 1 toto ubuntu 10 oct.  28 12:01 essai
cat: essai: Permission denied
READ FORBIDEN OK
/home/ubuntu/test-perms: line 18: essai: Permission denied
WRITE FORBIDEN OK
+ ls -l essai
-rw-rw 1 toto toto 10 oct.  28 12:01 essai
cat: essai: Permission denied
READ FORBIDEN OK
/home/ubuntu/test-perms: line 18: essai: Permission denied
WRITE FORBIDEN OK
+ ls

Bug#998005: Regression: bad handling of permission in directory with sticky bit

2021-10-28 Thread Bastian Blank 
On Thu, Oct 28, 2021 at 02:51:48PM +0200, Vincent Danjean wrote:
> Do you confirm this is a bug? Do you want I look
> for the first kernel in Debian with this regression?

It is not a bug, this are hardening settings.  See documentation about
the protected_regular setting in
https://www.kernel.org/doc/Documentation/sysctl/fs.txt

Those are enabled by default and apply to all sticky directories, so
mostly /tmp and /var/tmp.

Bastian

-- 
Yes, it is written.  Good shall always destroy evil.
-- Sirah the Yang, "The Omega Glory", stardate unknown

Bug#998009: ethtool: Import new upstream version

2021-10-28 Thread Bastian Germann 

Source: ethtool
Version: 1:5.9-1

ethtool version is lacking behind the latest upstream release 5.14 by several 
versions.
Please import the latest upstream release.

Bug#998005: Regression: bad handling of permission in directory with sticky bit

2021-10-28 Thread Vincent Danjean 
Package: src:linux
Version: 5.14.12-1
Severity: normal

Hi,

One of my users reports me a strange file access problem:
In a directory with sticky bit such as /tmp, the write
permission he can set on one of his (plain) file is ignored.
He cannot allow another user to write in its file (no ACL
are involved).

I dig into this issue and, indeed, I observe this stange
behavior. The sticky bit in directory change file rename
and deletion, ok. But it should not change write access.

I wrote the attached script. I run it on ubuntu live 14,
ubuntu live 20 and on my laptop (sid). The script has been
run in /tmp (sticky bit) and /home/$USER (no sticky bit).
[users and groups have been changed for the runs on the sid
machine]
  Access problems occur in /tmp on ubuntu live 20 and sid,
but not on /home (all systems) nor on ubuntu live 14 in
/tmp (old kernel)

The results are in the attachments.

Here is an extract with one problematic result:
vdanjean@eyak:/tmp$ id -un
vdanjean
vdanjean@eyak:/tmp$ ls -ld .
drwxrwxrwt 368 root root 196608 28 oct.  14:39 .
vdanjean@eyak:/tmp$ ls -l essai 
-rw-rw-rw- 1 cbardel cbardel 4 28 oct.  13:33 essai
vdanjean@eyak:/tmp$ echo ok >> essai
bash: essai: Permission non accordée

With 0666 permission, anybody should be able to write
in the file (even if the containing directory has a
sticky bit)

Do you confirm this is a bug? Do you want I look
for the first kernel in Debian with this regression?

  Regards
Vincent
#!/bin/bash

LC_ALL=C

FILE=essai
OTHER_USER=toto
SHARED_GROUP=ubuntu
PRIVATE_GROUP=toto

display() {
echo "+ $*"
"$@"
}

check() {
display ls -l $FILE
cat $FILE > /dev/null || echo "READ FORBIDEN $1"
echo ok >> $FILE || echo "WRITE FORBIDEN $2"
}

display uname -a
display id
display id $OTHER_USER
display ls -ld $(pwd)
echo "foo" > $FILE

sudo chown $OTHER_USER $FILE
sudo chgrp $SHARED_GROUP $FILE

sudo chmod 660 $FILE
check "" "WHY?"

sudo chmod 666 $FILE
check "" "WHY?"

sudo chmod 606 $FILE
check "OK" "OK"


sudo chgrp $PRIVATE_GROUP $FILE

sudo chmod 660 $FILE
check "OK" "OK"

sudo chmod 666 $FILE
check "" "WHY?"

sudo chmod 606 $FILE
check "" "WHY?"
+ uname -a
Linux ubuntu 4.4.0-142-generic #168~14.04.1-Ubuntu SMP Sat Jan 19 11:26:28 UTC 
2019 x86_64 x86_64 x86_64 GNU/Linux
+ id
uid=999(ubuntu) gid=999(ubuntu) 
groups=999(ubuntu),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),108(lpadmin),124(sambashare)
+ id toto
uid=1000(toto) gid=1000(toto) groups=1000(toto),999(ubuntu)
+ ls -ld /home/ubuntu
drwxr-xr-x 15 ubuntu ubuntu 480 oct.  28 12:01 /home/ubuntu
+ ls -l essai
-rw-rw 1 toto ubuntu 4 oct.  28 12:01 essai
+ ls -l essai
-rw-rw-rw- 1 toto ubuntu 7 oct.  28 12:01 essai
+ ls -l essai
-rwrw- 1 toto ubuntu 10 oct.  28 12:01 essai
cat: essai: Permission denied
READ FORBIDEN OK
/home/ubuntu/test-perms: line 18: essai: Permission denied
WRITE FORBIDEN OK
+ ls -l essai
-rw-rw 1 toto toto 10 oct.  28 12:01 essai
cat: essai: Permission denied
READ FORBIDEN OK
/home/ubuntu/test-perms: line 18: essai: Permission denied
WRITE FORBIDEN OK
+ ls -l essai
-rw-rw-rw- 1 toto toto 10 oct.  28 12:01 essai
+ ls -l essai
-rwrw- 1 toto toto 13 oct.  28 12:01 essai
+ uname -a
Linux ubuntu 4.4.0-142-generic #168~14.04.1-Ubuntu SMP Sat Jan 19 11:26:28 UTC 
2019 x86_64 x86_64 x86_64 GNU/Linux
+ id
uid=999(ubuntu) gid=999(ubuntu) 
groups=999(ubuntu),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),108(lpadmin),124(sambashare)
+ id toto
uid=1000(toto) gid=1000(toto) groups=1000(toto),999(ubuntu)
+ ls -ld /tmp
drwxrwxrwt 4 root root 200 oct.  28 12:01 /tmp
+ ls -l essai
-rw-rw 1 toto ubuntu 4 oct.  28 12:01 essai
+ ls -l essai
-rw-rw-rw- 1 toto ubuntu 7 oct.  28 12:01 essai
+ ls -l essai
-rwrw- 1 toto ubuntu 10 oct.  28 12:01 essai
cat: essai: Permission denied
READ FORBIDEN OK
/home/ubuntu/test-perms: line 18: essai: Permission denied
WRITE FORBIDEN OK
+ ls -l essai
-rw-rw 1 toto toto 10 oct.  28 12:01 essai
cat: essai: Permission denied
READ FORBIDEN OK
/home/ubuntu/test-perms: line 18: essai: Permission denied
WRITE FORBIDEN OK
+ ls -l essai
-rw-rw-rw- 1 toto toto 10 oct.  28 12:01 essai
+ ls -l essai
-rwrw- 1 toto toto 13 oct.  28 12:01 essai
+ uname -a
Linux ubuntu 5.11.0-27-generic #29~20.04.1-Ubuntu SMP Wed Aug 11 15:58:17 UTC 
2021 x86_64 x86_64 x86_64 GNU/Linux
+ id
uid=999(ubuntu) gid=999(ubuntu) 
groupes=999(ubuntu),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),120(lpadmin),132(lxd),133(sambashare)
+ id toto
uid=1000(toto) gid=1000(toto) groupes=1000(toto),999(ubuntu)
+ ls -ld /home/ubuntu
drwxr-xr-x 15 ubuntu ubuntu 440 oct.  28 12:17 /home/ubuntu
+ ls -l essai
-rw-rw 1 toto ubuntu 4 oct.  28 12:18 essai
+ ls -l essai
-rw-rw-rw- 1 toto ubuntu 7 oct.  28 12:18 essai
+ ls -l essai
-rwrw- 1 toto ubuntu 10 oct.  28 12:18 essai
cat: essai: Permission non accordée
READ FORBIDEN OK
/home/ubuntu/test-perms: line 18: essai: Permission denied
WRITE FORBIDEN OK
+ ls -l essai
-rw-rw 1 toto toto 10 oct.  28 12:18 essai
cat: essai:

Bug#992555: 5.14 also affected

2021-10-28 Thread Hendrik Buchner 
I've installed 5.14 from bullseye backports and it's also affected. It
seems that something has changed from 4.x to 5.x-Series.

Bug#998001: Fw: linux-headers-amd64 dependency to linux-headers-5.10.0-0.bpo.8-amd64 is broken in buster-backports

2021-10-28 Thread Daniel BO Larsson 
Package: linux-headers-amd64
Version: 5.10.46-4~bpo10+1


Severity: important


Tags: a11y

Dear Maintainer,

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

   * What led up to the situation?

I wanted to install the linux-headers-amd64 package from buster-backports.

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

I ran the following command to install the linux-headers-amd64 package from 
buster-backports.

sudo apt -t buster-backports install linux-headers-amd64

   * What was the outcome of this action?

The package was not able to install. Here is the output of the command.

$ sudo apt install -t buster-backports linux-image-amd64 linux-headers-amd64
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 linux-headers-amd64 : Depends: linux-headers-5.10.0-0.bpo.8-amd64 (= 
5.10.46-4~bpo10+1) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

   * What outcome did you expect instead?

I expected that the linux-headers-amd64 package would install from 
buster-backports without any issues.

   * Suspected cause.

I suspect that the linux-headers-amd64 package from buster-backports is not 
installable because. The linux-headers-amd64_5.10.46-4~bpo10+1 depends on 
linux-headers-5.10.0-0.bpo.8-amd64_5.10.46-2~bpo10+1 but only 
linux-headers-5.10.0-0.bpo.8-amd64_5.10.46-4~bpo10+1 is available and thus a 
mismatch emerge and the installation fails.



Daniel Larsson

Linux Technical Support


daniel.bo.lars...@axis.com

Tel (direct): +46 708756852


Axis Communications AB

Emdalavägen 14, SE-223 69 Lund, Sweden

Tel: +46 46 272 18 00, Fax: +46 46 13 61 30, www.axis.com


P Please consider the environment before printing this e-mail