On Wed, 2025-02-12 at 08:50 +0100, Salvatore Bonaccorso wrote:
> Yes my undsetstanding from your comments was that 6.12.13-1 does not
> expose the problem.
Okay... let me summarise :-)
- 6.12. doesn't show the original problem (hanging mv) described in
this bug
I briefly (and wrongly) thought
Hey.
I think you misunderstood me:
Only the part where I thought that dCache showed the old size (after
the move has happened, without hanging, when using a current kernel) is
a non-issue.
The problem in 6.1.x, that mv hangs *is* still happening.
Cheers,
Chris.
On Mon, 2025-02-10 at 20:44 +0100, Christoph Anton Mitterer wrote:
> [0] Well there is another bug showing up (this time most likely being
> actually a dCache bug, i.e. the "new" file (after the move) shows the
> size of the old one, while it actually has the content of th
Hey Salvatore
On Fri, 2025-02-07 at 14:25 +0100, Salvatore Bonaccorso wrote:
> Sure, but it is still a very specialized usecase. As I understand
> there is for instance the PoolManager which takes action when a user
> performs a reading or writing operation on a file.
Yes. Though I would not expe
Hey Salvatore.
On Sat, 2025-02-01 at 14:52 +0100, Salvatore Bonaccorso wrote:
> While looking at some NFS related bugs I noticed this one which was
> unaswered, but reported against an old 6.1.y version.
It still happens with 6.1.119-1.
> 6.1.y version, then please reopen the bug and do remove
On Tue, 2025-02-04 at 03:12 +0100, Christoph Anton Mitterer wrote:
> When I just retried I also noticed that after Ctrl-C-ing the hanging
> mv
> it seems that dest file is kept, and the src file is gone (which I'd
> consider as data loss, caused by this issue).
Tried that sever
Hey.
On Mon, 2024-11-18 at 10:28 +0100, Uwe Kleine-König wrote:
> The patch is marked for stable, so I'd expect this to be solved for
> 6.11.y soon, too.
Hasn't made it into .9, but since Greg KH already added it to the
stable tree, it should be in .10 :-)
Thanks,
Chris.
Control: forwarded -1
https://lore.kernel.org/linux-integrity/8fe12e2eb9beb159d2af8462fa0b9b1f946deacb.ca...@hansenpartnership.com/T/#t
Hey.
It seems that the problem is always triggered when the system is
resumed from hibernation.
I.e. it does not seem to happen after a fresh boot.
That's the
Control: reopen -1
Hey.
It's back, so at least this wasn't a one time glitch, making it IMO
more likely that there actually is some regression.
Thus reopening for now.
Thanks,
Chris.
Source: linux
Version: 16
Severity: normal
Hey.
That either started with 6.11.7-1 (or perhaps alo with 6.11.6, which I skipped),
but it's at least not present with 6.11.5-1.
After boot, the kernel starts "flooding" (well every 10s) the kernel log
with:
Nov 11 17:49:25 heisenberg kernel: wlan0:
Hey Ben.
Nice to see a package for that :-)
On Tue, 2024-06-25 at 00:46 +0200, Ben Hutchings wrote:
> > net.ipv4.conf.all.rp_filter=1
>
> This is (effectively) set to 2 by the new configuration.
Just wondered why not using 1?
AFAIU, the RFC would recommend strict mode (1). Does that break
anyth
Hello there.
I just wondered whether it has even been considered to make just one
package which contains the actual kernel+modules, and another one that
contains the signatures?
I'm not an expert when it comes to the binary layout of that, but
AFAIU, the modules are anyway the same between the
Hey.
Seems there were at least a series of commits from upstream last
November and few again this January.
And there even seem to be some more in their dev branch.
The number of CVEs mentioned by Salvatore is worrying, but it looks
even much worse over the years for ntfs-3g:
https://cve.mitre.or
Hey Salvatore.
On Wed, 2023-02-15 at 07:12 +0100, Salvatore Bonaccorso wrote:
> Just to be sure, that I understood you correctly. That is if on the
> current system with the issue you roll back just only the kernel back
> to 6.1.8-1, then the issue dissaper?
Exactly, and the roll back even only
Source: linux
Version: 6.1.11-1
Severity: normal
Hey.
Over the year this has unfortunately happened numerous times, either by changes
in the Xorg driver, or libinput... and now it seems the kernel caused the
same:
After upgrading from linux-image-6.1.0-3-amd64 to linux-image-6.1.0-4-amd64 and
a
Hey.
Is this still followed up or already supported to some extent in the
meantime?
I've looked through the previous messages and suggested patches and
some notes on these:
- Auto-detection of resume device, when resuming happens, is most
likely a security hole, as I've described previously in
Just for the records, meanwhile I've also opened a proper ticket about
this over at BusyBox regarding the same bug in their sh at:
https://bugs.busybox.net/show_bug.cgi?id=15171
Hey Ben.
On Sun, 2022-11-27 at 17:51 +0100, Ben Hutchings wrote:
> I don't think I will work on this in klibc until there's a fix in
> upstream dash. If you're still watching upstream dash, please let me
> know when there's a fix I can pick.
A patch has now been posted for dash at:
https://lore.
Package: klibc-utils
Version: 2.0.11-1
Severity: normal
Tags: upstream
Hey there.
There’s a bug in ash-bashed shells, including the one shipped with
klibc.
The original variant is described here (for dash):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024635
respectively
https://lore.kern
Hey Diederik and Bastian
On Thu, 2022-11-10 at 13:07 +0100, Bastian Blank wrote:
> Those symlinks are included in linux-headers-6.0.0-3-amd64, see
> https://packages.debian.org/sid/amd64/linux-headers-6.0.0-3-amd64/filelist
>
> Did you remove that package as well?
You are both right, I have lin
Just noted, that part of what I wrote is probably bollocks. ^^
On Thu, 2022-11-10 at 03:37 +0100, Christoph Anton Mitterer wrote:
> $ ls -al 6.0.0-3-amd64/build 6.0.0-3-amd64/source
> lrwxrwxrwx 1 calestyo calestyo 36 Nov 5 14:41 6.0.0-3-amd64/build ->
> /usr/src/linux-headers-6
Source: linux
Version: 6.0.7-1
Severity: normal
Hey.
When I tried out some recent patch from the intel folks for i915,
I built a custom kernel as described in:
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official
Now before I installed the custom built de
Package: debian-kernel-handbook
Version: 1.0.20
Severity: normal
Hey.
Chapter 4.2.1.1. Disk space requirements explains how to disable debug info
during, build:
> You can disable debug info by changing the value of debug-info to false in
> debian/config/arch/defines, if it's set there, or in deb
Package: firmware-iwlwifi
Version: 20221012-1
Severity: normal
Hey there.
My new Fujitsu Lifebook U7512 has some Intel USB Bluetooh device:
# lsusb -v -d 8087:0033
Bus 001 Device 009: ID 8087:0033 Intel Corp.
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB
Package: firmware-iwlwifi
Version: 20221012-1
Severity: normal
Hey there.
There possibly is a firmware file missing. In the kernel log I see:
# dmesg | grep -i wifi
[ 158.112234] Intel(R) Wireless WiFi driver for Linux
[ 158.114662] iwlwifi :00:14.3: firmware: failed to load
iwlwifi-so-a0
On Sat, 2022-10-29 at 09:44 +0200, Salvatore Bonaccorso wrote:
> We do similar with intel-microcode updates, so maybe this is
> something
> we should consider to. But I think it's to early to think about a
> potential 20220913-1~deb11u1 via a bullseye point release.
It's just that for any bullseye
On Sat, 2022-10-29 at 09:23 +0200, Salvatore Bonaccorso wrote:
>
> No unfortunately we cannot do that. The reason is similar to what
> lead
> to
> https://salsa.debian.org/kernel-team/linux/-/commit/248736d493fcfd0e05cd23f97befe40f5c125c71
> or caused bugs like #916927.
Forgive me my ignorance, b
Hey Salvatore.
On Fri, 2022-10-28 at 06:49 +0200, Salvatore Bonaccorso wrote:
> I did decide to still do so, so we can have the CVE fix migrate
> finally to testing (which took some time as well given there was the
> perl transition ongoing).
Fine for me... I think it would be nice if there was a
Hey Bastian.
Thanks for fixing.
Is this going to be backported to bullseye?
Thanks,
Chris.
Am 27. Oktober 2022 20:56:49 MESZ schrieb Salvatore Bonaccorso
:
>According to your references there is the workaround of mounting with
>clear_cache,space_cache=v2 and convert the filesystem.
>
>What would one prevent doing so?
v2 space cache is still rather new and had only recently some bug
Control: retitle -1 6.0.5 fixes critical btrfs bug in 6.0.3, affecting space
cache v1 filesystems
Control: notfound -1 5.19.6-1
Control: found -1 6.0.3-1
No idea why reportbug picked 5.19.6, which I have not even installed
anymore... o.O
Source: linux
Version: 5.19.6-1
Severity: critical
Justification: breaks the whole system
Hi.
6.0.3 introduced a commit that causes (permanent) CPU soft lockups
for some people with btrfs filesystems, effectively breaking the
system, e.g. when booting.
See e.g.
https://lore.kernel.org/linux-btr
Am 25. September 2022 20:13:26 MESZ schrieb Bastian Blank :
>On Sun, Sep 25, 2022 at 08:05:29PM +0200, Christoph Anton Mitterer wrote:
>But an attacker can already modify the kernel command line. Secure boot
>up until recently was completely incompatible with hibernation, so
>
Package: initramfs-tools
Version: 0.142
Severity: important
Tags: security
Hey.
According to initramfs.conf(5):
> RESUME
> Specifies the device used for suspend-to-disk (hibernation),
> which the initramfs code should attempt to resume from. If this
>
On Thu, 2022-09-01 at 16:40 +0200, Salvatore Bonaccorso wrote:
> 5.19.6-1 has been uploaded earlier today.
Ah,... okay... I had only seen the UNRELEASED commit in salsa.
Cheers,
Chris.
Control: tags -1 + patch
Hey.
The patch for this has been merged in the stable kernels... could you
please cherry pick respectively update the sid kernel ASAP?
https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.6
commit: a2e54eb64229f07f917b05d0c323604fda9b89f7
btrfs: fix space cache c
Source: linux
Version: 5.18.16-1
Severity: important
Tags: upstream patch
Hey.
This is merely a heads up, that a potentially pretty nasty data corruption
issue has been found in btrfs.
As far as I understand:
It was introduced in 5.12, has the highest chances to occur with
free space cache v2,
Hey.
I just ran into the same problem in bullseye.
Linux lcg-lrz-admin 5.10.0-15-amd64 #1 SMP Debian 5.10.120-1 (2022-06-09)
x86_64 GNU/Linux
Salvatore, AFAICS, that kernel should already contain the commit you've
mentioned, however, it still gives an error about missing firmware.
Downloading t
Package: initramfs-tools
Version: 0.140
Severity: normal
Tags: security
Hi.
AFAIU, the UMASK option is there for cases like e.g. when dm-crypt keys
are included in the initramfs.
I played a bit with it, and found that it already doesn't just affect the
final initramfs image, but also parts belo
Hey.
This seems like a very trivial patch... and a very helpful one, too.
Any chance to get this merged?
Thanks,
Chris.
Source: linux
Version: 5.14.12-1
Severity: normal
Hey.
There are some leftovers when purging:
Purging configuration files for linux-image-5.14.0-2-amd64 (5.14.9-2) ...
rmdir: failed to remove '/lib/modules/5.14.0-2-amd64': Directory not empty
dpkg: warning: while removing linux-image-5.14.0-2-a
Hey.
Wanted to ask here, before I make (probably unnecessary noise at
lkml).. O:-)
I just noticed that \r is not escaped in e.g. /proc/mounts (and
possibly similar files that do such escaping).
The output does in fact contain then a \r, so I guess parsing for most
(all?) shell tools should be
Hey Romain.
Thanks for your ideas:
On Wed, 2021-10-06 at 18:49 +0200, Romain Perier wrote:
> Quickly, few ideas (perhaps not the perfect ones):
> 1. Check for what is currently mounted as "/" ? (which technically
> should differ between initramfs or real rootfs)
That sounds like a pretty nice id
Hey.
I've just wondered whether there is recommended way to find out whether
one is currently "within" the initramfs (i.e. early boot) as generated
by Debians initramfs-tools, or not?
I'd have probably done something like checking for:
if [ -f /conf/initramfs.conf ] && [ -f /scripts/init-top/ORDE
Package: nfs-kernel-server
Version: 1:1.3.4-6
Severity: wishlist
Hi.
It may make sense to ship exports(5) manpage in nfs-common as the same file
is also used by other NFS server implementations (e.g. one of them would be
dCache (http://dcache.org/), which provides a pNFS 4.1 server).
And obviso
On Sat, 2021-06-05 at 16:59 +0200, Ben Hutchings wrote:
> You mean, can the main initramfs be uncompressed? I'm not sure
> whether
> the kernel supports that. It's certainly not an option in initramfs-
> tools at the moment.
Forget it... I'm stupid ^^ ... it's just the microcode, that's
uncompre
On Sat, 2021-06-05 at 16:23 +0200, Ben Hutchings wrote:
> You have intel-microcode installed, which prepends an uncompressed
> initramfs. Not a bug.
Couldn't it then just skip the compression altogether?
Cheers,
Chris.
Control: tags -1 - moreinfo
On Mon, 2021-05-31 at 11:08 +0200, Nicolas Schier wrote:
> To validate my argumentation,
> please set 'COMPRESS=gzip' in '/etc/initramfs-tools/initramfs.conf',
> run 'update-initramfs -u' again and compare the sizes of the
> (probably)
> zstd-compressed one with the
Package: initramfs-tools
Version: 0.140
Severity: normal
Hey.
Just noted by coincidence, that even though I have set:
COMPRESS=zstd
and zstd is installed and even runs (seen in e.g. top utility) when running
update-initramfs -u
the files are in the end nevertheless plain cpio:
file /boot/i
On Sun, 2021-05-02 at 15:56 +0200, Salvatore Bonaccorso wrote:
> In this case I'm reopening the bug again. But I suggest to ping again
> upstream in this case, because without progress/movement/ideas
> upstream we cannot do anything here downstream.
I'm afraid that upstream has shown pretty clearl
This bug has actually NOT been fixed.
It's NOT the one with the CPU not going into the RC6 state.
Cheers,
Chris.
On Thu, 2020-04-23 at 23:50 +0100, Ben Hutchings wrote:
> I came up with a simpler alternative:
> https://salsa.debian.org/kernel-team/linux/-/commit/67fa568149b985f73b333acdec4481acf667192f
Looks good... and seems like the best solution.
Thanks,
Chris.
Package: debian-kernel-handbook
Version: 1.0.19
Severity: normal
Hi.
The handbook seems to use two git repos:
1) https://salsa.debian.org/kernel-team/linux.git
for Debian's packaging itself
2) git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
for the upstream soruces, e.g. w
Controle: retitle -1 huge CPU temperature increase from 5.2 to 5.5 ... and when
using intel_pstate
I've upgraded to 5.5.17 (again the stock Debian sid package), and all
future tests with 5.5.x will be with this.
Problems unchanged.
I've also checked 5.5.17 with intel_pstate being enabled bu
On Sat, 2020-04-18 at 22:54 +0100, Ben Hutchings wrote:
> No, it does not. It removes kmod's index files
I probably should have better checked the code I've copy&pased ^^
> This is a known bug but I don't know how to fix it.
Maybe I'm thinking way to simple... but if depmod fixes that...
couldn
Source: linux
Version: 5.5.17-1
Severity: important
Hi.
I've just switched from the linux-image-5.5.0-1-amd64-unsigned to
linux-image-5.5.0-1-amd64
(which wasn't available as soon as the -unsigned version) in on go via apt.
The consequence was, that many modules were missing.
Looking at the
Control: tags -1 - patch
Control: notfound -1 3.16.81-1
Control: notfound -1 4.19.87-1
Control: notfound -1 5.4-1~exp1
Control: forwarded -1
https://bugzilla.kernel.org/show_bug.cgi?id=207245
Hey Ben.
On Fri, 2020-04-17 at 18:02 +0100, Ben Hutchings wrote:
> This is now neither "fixed" nor "fo
I've made some further very extensive tests in the meantime, but these
were mostly for clearly GPU related stuff, i.e. the problem that the
temperatures go through the roof when playing back any video.
These were reported here:
https://gitlab.freedesktop.org/drm/intel/-/issues/953#note_463451
But
Hey.
For several months now, I've been chasing a tremendous heat increase
(CPU/GPU) respectively power usage on my notebook.
It basically started after upgrading from 5.2 to 5.3, at least I
haven't explicitly noted any grave changes from before 5.2 to 5.2.
The issue (actually there might be seve
Source: linux
Version: 5.5.13-2
Severity: wishlist
Hi.
Since quite a while now Linux seems to support a font for HighDPI
displays.
It woudl just need to be enabled:
CONFIG_FONT_TER16x32
Seems it will be auto-selected when appropriate:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/li
Control: notfound -1 5.5~rc5-1~exp1
Control: fixed -1 5.5~rc5-1~exp1
Oh I've just seen that the fixing commit seems to be a already part of
5.5-rc1:
$ git log --oneline --all | grep "drm/i915/gt: Schedule request retirement when
timeline idles"
311770173fac drm/i915/gt: Schedule request retireme
Control: found -1 3.16.81-1
Control: found -1 4.19.87-1
Control: found -1 5.4-1~exp1
Control: found -1 5.5~rc5-1~exp1
Control: tags -1 + patch
Control: forwarded -1 https://gitlab.freedesktop.org/drm/intel/issues/614
Hey.
The offending patch is apparently:
drm/i915/gen8+: Add RC6 CTX corruption
Hey.
According to https://gitlab.freedesktop.org/drm/intel/issues/953 the
bug was introduced by:
drm/i915/gen8+: Add RC6 CTX corruption WA
(d4360736a7c0a6326e3bbdf7d41181f6ed03d9a6)
which, AFAIU, is actually a security fix.
There seem to be some patches, but not sure when they'll be "final" (i
Control: forwarded -1
https://lore.kernel.org/lkml/d05aba2742ae42783788c954e2a380e7fcb10830.ca...@scientia.net/
Hey.
I've forwarded this to lkml.
My most recent post in that thread[0] contains an pretty elaborate test
series comparing kernel 5.2 vs. 5.4 (each with intel_pstate=disable and
witho
Control: severity -1 grave
Raising severity, since this current kernels are completely unusable on
at least some hardware (i.e. the one I use here), since the temperature
just explodes.
I'd say grave is justified already by potential hardware damages of
systems running even at little actual load a
Package: linux-base
Version: 4.6
Severity: grave
Justification: renders package unusable
Hi.
Since last April, the package can't be upgraded as it conflicts with
the current version of kernel-common.
Would be nice if this could be resolved.
Probably it's this change:
* Take over kernel-img.c
I should perhaps add that there is some slight indication that this
might be graphics related.
Cause when I switch from the running X/Cinnamon (with the CPU at
average temperatures between 75-70°C, while top doesn't show really
much) to the virtual kernel console, temperatures go down drastically
btw: 5.3.15-1 seems to be still affected.
While I see mostly "normal" temperatures right after boot (and when
everything has settled)... after some point in time, tmeperatures get
up and remain at high levels, e.g. :
Package id 0: +81.0°C (high = +100.0°C, crit = +100.0°C)
Core 0:+7
Source: linux
Version: 5.3.7-1
Severity: important
Hi.
Apparently changes from 5.2+107 -> 5.3.7-1 break sound completely.
As soon as I login to the desktop environment the following goes of:
Oct 24 18:33:10 heisenberg kernel: snd_hda_intel :00:1f.3: azx_get_response
timeout, switching to p
Hey.
Is there anything one can help to speed this up?
A patch is available for two weeks now, while Debian users of testing
and unstable are left with the danger of catastrophic btrfs corruption
without even any warning to them (so that they could at least downgrade
to <5.2).
Cheers,
Chris.
Hey.
Just to put some emphasise on this, the fix has now been merged late to
5.3 as urgent.
Also note Filipe's post[0] that the issue can more or less hit anyone.
Cheers,
Chris.
[0]
https://lore.kernel.org/linux-btrfs/9731b0e7-81f3-4ee5-6f89-b4fd8d981...@petaramesh.org/T/#m7b3863ef7ec5f62a2f7
Source: linux
Version: 5.2.9-2
Severity: critical
Tags: upstream patch
Justification: causes serious data loss
Hi.
There were some reports over the last weeks from users on linux-btrfs which
suffered from catastrophic btrfs corruption.
The bug which is apparently a regression introduced in 5.2 h
Hey Ben, Salvatore.
Thanks for cherry-picking the bug for unstable.
AFAIU stretch and jessie[-backports] should be affected as well.
Shouldn't it go there, too?
At least at the upstream mailing list it was said[0] the the bug was
introduced around October 2008, which should be roughly kernel 2.6
Here's the "proper" patch:
https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg85515.html
Source: linux
Version: 4.19.20-1
Severity: critical
Tags: upstream patch
Justification: causes serious data loss
Hi.
Apparently there was a longer existing data corruption bug in btrfs[0],
AFAIU it happened when compression was used together with holes in data
and there was *no* recognition by ch
For those reading along, Jens Axboe gave a summary on how to
check whether one's affected or not:
Quoting from: https://bugzilla.kernel.org/show_bug.cgi?id=201685#c294
> scsi_mod.use_blk_mq=0 will do the trick, as will just ensuring that you have
> a scheduler for your device. Eg for sda, check:
>
Source: linux
Version: 4.18.20-2
Severity: critical
Tags: upstream patch
Justification: causes serious data loss
Hi.
There's a bug in the blk-mq schedulers which may cause serious data
curruption...
See https://bugzilla.kernel.org/show_bug.cgi?id=201685
Seems like a patch was made recently,...
Control: forwarded -1 https://bugzilla.kernel.org/show_bug.cgi?id=201791
Hey.
Just wondered if a maintainer could possibly tell me whether this could
happen anytime soon?
It's no big problem for me if not, I'd just want to avoid compiling the
whole kernel on my system (which is not the fastest one ^^) if you'd
enable it anyway on the next version or so.
Cheers,
Chri
Source: linux
Version: 4.18.20-1
Severity: important
Tags: upstream
Hi.
Possibly the following may be also partially iptables (i.e. the userland tool)
fault.
I'm using fail2ban with some custom usage mode, which is that the hook-rule
for fail2ban's change isn't just appended somehwere, but an
Source: linux
Version: 4.18.10-2+b1
Severity: wishlist
Hi.
Could you please enable the crypto modules for MORUS and AEGIS
AEAD ciphers?
It shoul be supported now in cryptsetup/dm-crypt for volumes
with integrity protection and I'd like to play with them.
Thanks,
Chris.
-- System Information:
Just had a look at this by comparing the list of kernel modules loaded
just before cryptsetup waits for passphrase entry at boot, with
modules=most and =dep.
By that I found out, that with =most the module psmouse is loaded while
it is not with =dep.
If I add psmouse to /etc/initramfs-tools/modul
There is some indication, that this issue doesn't occur with the kernel
from oldstable (i.e. 3.16.51-3+deb8u1, with the rest of our userland
still at stretch)... at least we have on node downgraded to that
kernel, and so far that one wasn't hit in nearly two weeks, while many
other were.
If there'
The severity would have shown people which haven't upgraded, that there
are issues... :-(
On Tue, 2017-10-31 at 16:01 +, Ben Hutchings wrote:
> Although you can disable it (security=dac or apparmor=0) if you want.
Sure. I never said this wasn't possible.
> > While I'm usually in favour of a
Package: src:linux
Version: 4.13.10-1
Severity: critical
Justification: breaks unrelated software
Hi.
Apparently AppArmor was enabled per default in the last version.
While I'm usually in favour of anything that improves security
(leaving aside the question here whether SELinux wouldn't be the
Package: initramfs-tools
Version: 0.130
Severity: important
Hi.
The following is a quite strange problem, and it may actually be a kernel bug.
Few days ago, I got a new notebook (a Fujitsu U757), before I removed the HDD
from
the old one, I changed MODULES=most on the old and updated the initra
On Fri, 2017-09-15 at 19:18 +0100, Ben Hutchings wrote:
> Probably less critical than you think, since we enable
> CONFIG_CC_STACKPROTECTOR.
Well... yes, but it wouldn't be the first time in history, that such
defence could then also be circumvented in the next evolution of an
exploit :-)
But of
Source: linux
Version: 4.12.12-2
Severity: critical
Tags: security
Justification: root security hole
Hi.
Any chance to get CVE-2017-1000251, which seems to be quite critical fixed
anytime soon? :-)
https://security-tracker.debian.org/tracker/CVE-2017-1000251
Thx,
Chris
Source: linux
Version: 4.9.30-2+deb9u2
Severity: normal
Hey Ben, et al.
There seems to be an annoying bug in btrfs, as described here:
https://www.spinics.net/lists/linux-btrfs/msg67479.html
It's not really extremely critical as it causes no direct fs corruption,
but it gives spurious ENOSPC in
On Mon, 2017-01-16 at 02:37 +, Ben Hutchings wrote:
> This should possibly go to 4.9-stable, but in any case I've queued it
> up for our next upload.
Could you ping the responsible people? Guess you have far better
contacts there than me ;-)
Cheers,
Chris.
smime.p7s
Description: S/MIME cryp
Source: linux
Version: 4.9.2-2
Severity: normal
Tags: patch upstream
Hey.
There's an issue in NBD which prevents some larger images to be
correctly "connected" on the client side (if done by the kernel),
largely described here:
https://github.com/NetworkBlockDevice/nbd/issues/44
Thers's a patch
Hey Ben.
Sorry I oversaw your mail back then.
Provided the information from perf top now in the kernel.org bugzilla,
and pinged the linux-usb list as you suggested:
https://www.spinics.net/lists/linux-usb/msg151899.html
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
On Tue, 2016-12-20 at 04:39 +, Ben Hutchings wrote:
> It looks like dpkg will remove it on the next upgrade of initramfs-
> tools-core. The problem only occurs once because dpkg tries to
> remove
> the directory before the conffile.
I've seen such tickets several times before,... and had the
Hey
I had the very same,... empty dir left behind... never modified any
configs in it (and even then I couldn't see how this can be desired, if
the modified config itself wasn't left behind somehow :) ).
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
The bug in question was a wishlist matter, so it's not really "fixed"
by recent upstream versions.
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
Source: linux
Version: 4.2.6-1
Severity: wishlist
Hey.
Not sure if linux is the right source package for this...
In several circumstances it would be handy, if there were
/vmlinux. and /initrd.img. symlinks
where each of them points to the most recent installed
kernel/initramfs of the respective
Package: src:linux
Version: 4.2.6-1
Severity: normal
Hey.
This is originall from http://article.gmane.org/gmane.linux.kernel/2090843:
I bough a USB3.0 ExpressCard from StarTech[0] which is apparently[1]
based on the NEC uPD720200.
Using a kernel 4.2.6 on amd64, the System is Debian sid, the fo
Hey.
That seems to work again at least since 4.2.5-1, but probably already
since few versions earlier (I didn't check this every time).
See upstream for little more details
Closing,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
Package: initramfs-tools
Version: 0.120
Severity: normal
Hi.
I've just noted the following:
Processing triggers for initramfs-tools (0.120) ...
update-initramfs: /boot/initrd.img-4.2.0-1-amd64 has been altered.
update-initramfs: Cannot update. Override with -t option.
Not sure what caused it to
Source: linux
Severity: minor
Hey.
This is absolutely just cosmetic ;-)
I've noted that the symlink /initrd.img is always absolute,
while /vmlinuz is always relative, e.g.:
$ ls -al /initrd.img /vmlinuz
lrwxrwxrwx 1 root root 30 Sep 27 13:37 /initrd.img ->
/boot/initrd.img-4.2.0-1-amd64
lrwxrwx
1 - 100 of 183 matches
Mail list logo
