Security hole in kernel fixed?
Dear developers, in April 2024 the security hole CVE-2023-6546 was discovered in linux-image, and I believe, it is fixed in kernel 6.1.0 (from debian/stable) as soon after this a new kernel was released. However, there is no new kernel 6.5.0-*-bpo released at that time, so my question: Does anyone know, if this fix was also integrated in kernel 6.5.0-*.bpo ? Thanks for your answer. Best Hans
Re: Dovecot correct ownership for logs
Interesting. That's not even configured in our main.cfg. We have these concerning dovecot: smtpd_sasl_type = dovecot mailbox_command = /usr/lib/dovecot/deliver -d $USER But that's still not that helpful for the main issue. Why on earth is postfix throwing issues about the log files, even when they are world-readable and -writable? It's not that dovecot doesn't log to them, but it's also not the case that it's an error message that can just be ignored, as it brings mail delivery to a halt. Am Mi., 15. Mai 2024 um 05:00 Uhr schrieb jeremy ardley < jeremy.ard...@gmail.com>: > This can be configured in postfix main.conf as > > virtual_transport = lmtp:unix:private/dovecot-lmtp or mailbox_transport > = lmtp:unix:private/dovecot-lmtp > > From the postfix howto guide > > mailbox_transport_maps (default: empty) > > Optional lookup tables with per-recipient message delivery transports > to use for local(8) mailbox delivery, whether or not the recipients are > found in the UNIX passwd database. > > The precedence of local(8) delivery features from high to low is: > aliases, .forward files, mailbox_transport_maps, mailbox_transport, > mailbox_command_maps, > mailbox_command, home_mailbox, mail_spool_directory, > fallback_transport_maps, fallback_transport and luser_relay. > > https://www.postfix.org/local.8.html > > https://doc.dovecot.org/configuration_manual/howto/postfix_dovecot_lmtp/ > >
Re: Dovecot correct ownership for logs
On 15/5/24 18:23, Richard wrote: Interesting. That's not even configured in our main.cfg. We have these concerning dovecot: smtpd_sasl_type = dovecot mailbox_command = /usr/lib/dovecot/deliver -d $USER The sasl line is not relevant The mailbox_command is unusual. It means whatever process actually execute the mailbox_command runs as (some) postfix user to run the deliver application. This may well cause permission issues. The usual case is dovecot listens for commands on a unix socket or maybe an IP socket. In any case it has an entirely separate user ID from postfix. You may want to look at using the mailbox_transport option instead of the mailbox_command option mailbox_transport = lmtp:unix:private/dovecot-lmtp
Re: Dovecot correct ownership for logs
mailbox_transport isn't defined anywhere. Am Mi., 15. Mai 2024 um 12:37 Uhr schrieb jeremy ardley < jeremy.ard...@gmail.com>: > > On 15/5/24 18:23, Richard wrote: > > Interesting. That's not even configured in our main.cfg. We have these > > concerning dovecot: > > smtpd_sasl_type = dovecot > > mailbox_command = /usr/lib/dovecot/deliver -d $USER > > The sasl line is not relevant > > The mailbox_command is unusual. It means whatever process actually > execute the mailbox_command runs as (some) postfix user to run the > deliver application. This may well cause permission issues. > > The usual case is dovecot listens for commands on a unix socket or maybe > an IP socket. In any case it has an entirely separate user ID from postfix. > > You may want to look at using the mailbox_transport option instead of > the mailbox_command option > > mailbox_transport = lmtp:unix:private/dovecot-lmtp > >
Re: Dovecot correct ownership for logs
On 15/5/24 18:52, Richard wrote: mailbox_transport isn't defined anywhere. Am Mi., 15. Mai 2024 um 12:37 Uhr schrieb jeremy ardley : On 15/5/24 18:23, Richard wrote: > Interesting. That's not even configured in our main.cfg. We have these > concerning dovecot: > smtpd_sasl_type = dovecot > mailbox_command = /usr/lib/dovecot/deliver -d $USER The sasl line is not relevant The mailbox_command is unusual. It means whatever process actually execute the mailbox_command runs as (some) postfix user to run the deliver application. This may well cause permission issues. The usual case is dovecot listens for commands on a unix socket or maybe an IP socket. In any case it has an entirely separate user ID from postfix. You may want to look at using the mailbox_transport option instead of the mailbox_command option mailbox_transport = lmtp:unix:private/dovecot-lmtp Then you may want to look at the manuals and find out how to add a mailbox_transport entry and comment out the mailbox_command entry. There are many other options of course, but mailbox_transport is a very common configuration and usually avoids most permission issues.
Re: Security hole in kernel fixed?
On 2024-05-15 at 03:05, Hans wrote: > Dear developers, As usual, most of us here are not Debian developers, even if some of us may be software developers. > in April 2024 the security hole CVE-2023-6546 was discovered in linux-image, > and I believe, it > is fixed in kernel 6.1.0 (from debian/stable) as soon after this a new kernel > was released. > > However, there is no new kernel 6.5.0-*-bpo released at that time, so my > question: > > Does anyone know, if this fix was also integrated in kernel 6.5.0-*.bpo ? I don't have a definitive answer, but you might look at: https://security-tracker.debian.org/tracker/CVE-2023-6546 The only place it mentions 6.5 is in the Notes section, where it mentions 6.5-rc7 (with a kernel.org link) in the context of a statement that the Linux kernel in Debian buster does not include the vulnerable code. I would therefore suspect that any 6.5.x kernel probably was not affected by this vulnerability to begin with. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Dovecot correct ownership for logs
On Wed, May 15, 2024 at 12:23:35PM +0200, Richard wrote: > [...] > But that's still not that helpful for the main issue. Why on earth is > postfix throwing issues about the log files, even when they are > world-readable and -writable? It's not that dovecot doesn't log to them, > but it's also not the case that it's an error message that can just be > ignored, as it brings mail delivery to a halt. > Maybe because you write directly to the logfile. One process trying to write t it while a different already holds a lock to it. -H -- Henning Follmann | hfollm...@itcfollmann.com
Re: OT: Top Posting
-Original Message- From: gene heskett To: debian-user@lists.debian.org Subject: Re: OT: Top Posting Date: 05/14/24 10:54:50 On 5/14/24 10:09, Richard wrote: Just because something isn't an official ISO standard doesn't mean it's not standard behavior. And how it relates to this mailing list? It's called a setting. No its not, its your refusal to use the down arrow in your reply editor to put your reply after the question. It really is that simple. If your choice of email agents cannot do that, its time to switch to an agent that can. There are dozens of them. DISCLAIMER: I just realized above portion might not quote properly. My apologies in advance if it does not. That's one glitch I haven't located a fix for, yet. The rest of the email: I think Evolution has finally fixed my own latest issues with tech reply emails just since Gmail forced all users onto its more dynamic release. My biggest issue is, hopefully "was," line length. This email is only my second reply sent in maybe 2 months so am about to find out how things are progressing. Accidentally just this second was reminded there's a setting for avoiding top posting by lunging to bottom of reply emails. That setting is found by going through the now classic 3-line settings "hamburger" then: Edit > Preferences > Composer Preferences > General (tab) There's a simple toggle on/off checkbox that says, "Start typing at the bottom." The setting for word wrapping is just a few lines above that. Regarding line length (word wrapping), that's an even less spoken "standard" that has merit at its base. I think I've seen it mentioned maybe one time in more than a decade++ on Debian. That "standard" is about usability.. readability.. aka conscious consideration for fellow list members. Best as I was able to discern from the Net [0], 72 characters is the magic number for line length because 4 extra characters are added to both ends when e.g. git processes submissions. Makes good common sense to me. PS I thought it was 80. Guess it was about those extra 8 characters. Or.. Maybe whoever I saw write that over ten years ago almost understood that "handshake standard" but not quite. That's one scary part of trusting strangers on the WWW. :) Again back to the concept of tech listserv standards, the source I'm referencing after randomly finding it via search this morning says, "The 50/72 Rule is a set of standards that are pretty well agreed upon in the industry to standardize the format of commit messages." "Pretty well agreed upon..." That's implying that unspoken list standards are really not users "picking on each other." Listserv standards is a concept that has evolved over decades for rational reasons as Developer and User communications evolved. Am not embarrassed to say Evolution has kicked my backside k/t its learning curve versus a user's level of cognitive ability. This experience ended up touching on "frightening" a couple times, e.g. I sent 2,000 online emails to (online) trash when that was not intended. It's easy to mess up badly while moving emails around between desktop folders because that activity directly affects the linked online email provider if a user approves those access permissions. For what it's worth as a huge selling point for me, I have a massive online email account. There are hundreds of thousands of emails from the last 20 years. Evolution said whatever, bring it on. Evolution appears to do some form of maybe symlinking instead of downloading so everything is available almost immediately seconds after the first time Evolution is ever fired up. Other email software I've used only seems to work by downloading. That difference is huge for anyone using a data download limiting Internet provider. NOTE: Evolution appears to possibly offer related tweaking if one prefers working offline. In the other email software cases I attempted, the software could only reach back a limited time span into history before I a-sume Gmail cut off access to touching older emails. If there's a work-around for that, I never found it. I simply (and immediately) purged the email software, instead. With Evolution, I'm instantly looking at emails I haven't seen in ~20 years. I was having a horrible time accessing those same emails in Gmail itself online. Talk about mind blowing nostalgia overload... Cindy :) [0] https://dev.to/noelworden/improving-your-commit-message-with-the-50-72-rule-3g79 -- Talking Rock, Pickens County, North Georgia * runs with birdseed! *
Re: OT: Top Posting
Cindy Sue Causey (12024-05-15): > Best as I was able to discern from the Net [0], 72 characters is the > magic number for line length because 4 extra characters are added to > both ends when e.g. git processes submissions. Makes good common sense > to me. Git is an order of magnitude younger than the limit at 72 characters. > PS I thought it was 80. Guess it was about those extra 8 characters. It is 80 but you anticipate that people will be adding “> ” in front of your lines. > "Pretty well agreed upon..." That's implying that unspoken list > standards are really not users "picking on each other." Listserv > standards is a concept that has evolved over decades for rational > reasons as Developer and User communications evolved. Indeed. > It's easy to mess up badly while moving emails around As a general rule, GUIs suck at anything but trivial tasks. > Evolution appears to do some form of maybe symlinking instead of > downloading so everything is available almost immediately seconds after > the first time Evolution is ever fired up. The IMAP protocol is designed to let us manipulate mails directly on the server without downloading the bulk of them. A lot of GUI MUA are still designed around the old paradigm where mails are downloaded, and turned it into some kind of cache: it rarely works well. Manipulate mails directly on the server. Have a backup. If your server is often down and accessing the mails is urgent, have a local *copy* of it. > reach back a limited time span into history before I a-sume Gmail cut > off access to touching older emails. If you want mail that works well, start by avoiding services meant for the lowest common denominator of the general public. Regards, -- Nicolas George
Re: OT: Top Posting
-Original Message- From: Greg Wooledge To: debian-user@lists.debian.org Subject: Re: OT: Top Posting Date: 05/14/24 13:41:17 On Tue, May 14, 2024 at 05:01:31PM +, fxkl4...@protonmail.com wrote: > how many times has this top post crap been dug up > don't y'all have any thing better to do It's never going to stop. We have a clash of two cultures here. The first culture are Unix users who grew up with Internet email and Usenet news. For people in this culture, there is a well-defined set of "netiquette" rules -- plain text messages, inline quoting with "> " citation characters, lines limited to ~72 characters, etc. Too funny for words! Make that twice now that I've seen line length mentioned here on Debian in over a decade++. I also referenced the inline quoting method since my new chosen email software appears to be failing with its default on that feature. Will try AGAIN to fix that as soon as I hit "Send" here BECAUSE tech reply emails are difficult to follow without those stacked ">" over ">>" pointers attached showing who said what when. And, yeah, netiquette, that's the word echoed across the Internet. I totally forgot that in my own response. It's not users picking on each other. It's a respectful "virtual handshake approved" set of standards with the straightforward purpose of putting everyone on as close to the same page as is humanly possible. PS Afterthought is that email signatures are another of that widely accepted netiquette set of standards. I consciously altered mine many years ago after reading about that, most likely also here on Debian- User. Might have been over on W3C, too, now that I think about it. That's where I first heard of Linux circa 1999. W3C's Linux reference was about installing HTML validators locally, and the rest is terminal command line history. Thank you, Developers! What you all do and that works so near flawlessly in nanoseconds still.. blows my mind to this.. second. Watching daily upgrades methodically unfold as each package successfully coordinates its place in line with the others is pure magic. :) Cindy :) -- Talking Rock, Pickens County, North Georgia * runs with birdseed! *
Re: OT: Top Posting
On Wed, May 15, 2024 at 09:46:08AM -0400, Cindy Sue Causey wrote: > Best as I was able to discern from the Net [0], 72 characters is the > magic number for line length because 4 extra characters are added to > both ends when e.g. git processes submissions. Makes good common sense > to me. > > PS I thought it was 80. Guess it was about those extra 8 characters. For many decades, there was an industry standard that lines of text should be up to 80 characters wide. Punch cards were 80 characters wide, for example. I don't know whether punch cards were the *first* place it appeared, but they're the first I'm aware of. A lot of the printers from the last century allowed 80 characters per line on standard US 8.5x11 inch paper. I'm not sure if teletypes used 80-column paper, or 133-column paper (green bar), or a mixture. Later, we got terminals. A typical ASCII terminal (a physical one, like a DEC VT-100) is 80x24 characters, or sometimes 80x25. The 80-character line standard continued. When hardware evolved and most of us started using X11 or similar GUI interfaces, terminal emulators became the norm. xterm and other software terminal emulators use an 80x24 window as the default, for compatibility with physical terminals. When writing code in most programming languages, there are style guides that still suggest sticking to 80-character lines whenever possible. It avoids line wrapping when being read in an 80-character terminal, and besides that, really long lines of code are harder to read than shorter lines. When it comes to email or Usenet, though, the 72-character suggestion is meant to allow a bit of room for quoting markup. If I write a 79-character line of text, and then you reply to it with "> " in front, the resulting 81-character line of text either gets wrapped or truncated. Limiting yourself to 72-character lines allows a few levels of quoting before the text becomes unreadable. This is why the 72-character limit is just a suggestion, not a hard requirement. If you write lines that are 74 characters wide, probably nobody's going to care. The goal is simply to make it easy to carry on a conversation.
Re: OT: Top Posting
On 5/15/24 10:06, Nicolas George wrote: Cindy Sue Causey (12024-05-15): Best as I was able to discern from the Net [0], 72 characters is the magic number for line length because 4 extra characters are added to both ends when e.g. git processes submissions. Makes good common sense to me. Git is an order of magnitude younger than the limit at 72 characters. PS I thought it was 80. Guess it was about those extra 8 characters. It is 80 but you anticipate that people will be adding “> ” in front of your lines. "Pretty well agreed upon..." That's implying that unspoken list standards are really not users "picking on each other." Listserv standards is a concept that has evolved over decades for rational reasons as Developer and User communications evolved. Indeed. It's easy to mess up badly while moving emails around As a general rule, GUIs suck at anything but trivial tasks. Evolution appears to do some form of maybe symlinking instead of downloading so everything is available almost immediately seconds after the first time Evolution is ever fired up. The IMAP protocol is designed to let us manipulate mails directly on the server without downloading the bulk of them. A lot of GUI MUA are still designed around the old paradigm where mails are downloaded, and turned it into some kind of cache: it rarely works well. Manipulate mails directly on the server. Have a backup. If your server is often down and accessing the mails is urgent, have a local *copy* of it. reach back a limited time span into history before I a-sume Gmail cut off access to touching older emails. If you want mail that works well, start by avoiding services meant for the lowest common denominator of the general public. Regards, I'll add that googles gmail, written by former outlook developers is the biggest pita to ever hit the net. They break every rfc that can. Cheers, Gene Heskett, CET. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: OT: Top Posting
Cindy Sue Causey (12024-05-15): > PS Afterthought is that email signatures are another of that widely > accepted netiquette set of standards. You can add the “Re: ” to that list. It is the sequence of four octets 0x52, 0x65, 0x3a, 0x20, and nothing else. The MUAs who write “RE: ” are wrong. The MUAs who write “Re : ” are wrong. The MUAs who write “AW: ” are wrong. The MUAs who put it in base64 are wrong. It is not a string that is designed to be internationalized, we cannot expect every MUA to know every stupid local or vanity variant of “Re: ”. Regards, -- Nicolas George
Re: Markup in mail messages
On 15/05/2024 03:17, Max Nikulin wrote: On 15/05/2024 02:32, Greg Wooledge wrote: On Tue, May 14, 2024 at 08:16:20PM +0200, Nicolas George wrote: Messages in Markdown in the Windows world? I have never seen it. [...] The only sensible interpretation I can come up with for why these asterisks were added is that they're being placed around text that's supposed to be emphasized/italicized. *Bold*, /italics/, and _underlined_ markup is supported by various mailers, e.g. Thunderbird and Gnus. Some render superscripts^1 and subscripts_2 as well. Backticks (`echo $PATH`) are more specific to markdown. However sometimes I use them not expecting that the message will be rendered as markdown. Just to avoid ambiguity where a piece of code starts and ends. When this sort of subject comes up (as it does, every so often), I wonder why `text/markdown` isn't offered as a mime type for sending emails. If you're an MUA and you're going to parse text/plain for markup, then why not offer text/markdown as the body of the message? I know that there have been various attempts to bridge the gap between "text/plain is too basic" and "text/html is too powerful" such as text/enriched and text/rtf, but Markdown seems to be hitting a sweet spot of being easy to write and being widely adopted elsewhere. OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bookworm's /etc/mailcap seems to break s-nail
On 07/05/2024 23:24, Max Nikulin wrote: On 2024-05-06 17:04, Max Nikulin wrote: So doubled backslashes (as in .desktop files) are correct. What is wrong is lack of backslashes added before ";" and it is a bug. I have filed https://bugs.debian.org/1071036 update-mime does not escape semicolon in .desktop Exec entries This particular bug almost certainly may be fixed by adding an extra line of perl code. However 2 layer of quoting in .desktop files: special rules for Exec and general for any strings require more work to get entries properly escaped for mailcap in general case. In the meanwhile I have realized that BASH implementation of parsing Exec entries in xdg-open fallback function search_desktop_file is really ugly: https://gitlab.freedesktop.org/xdg/xdg-utils/-/blob/master/scripts/xdg-open.in?ref_type=heads#L312 I am unsure if it is possible to implement double quotes rule https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s07.html Since xdg-open usually delegates handling of URIs to the desktop environment, this code is active only for those who avoid any DE.
Re: OT: Top Posting
Since my request started this offtopic subthread I hope I can put it to rest. Yes I requested to not toppost. I asked politely, and I added pertinent response on topic. I do not claim to be right or wrong about this. I prefer interleaved style for reason. Everyone on this list heard all arguments pro and con in previous discussions, and there is no need to repeat them. It is a matter of personal choice though I have to admit I feel a bit emboldened by the posting guidelines. And in my experience a polite question goes a long way with most civilized people. You can ignore my request, well you even ask me to toppost. I will ignore it. There is no need for a lecture, you have no claim to right or wrong either. Claiming a de facto industry standard (I avoided the literally sidebar here) on majority is a questionable argument. Large numbers do not make right. There are many examples where the majority is wrong. Well I go along with majority practice knowing they are wrong, just to make life easier. I try not to yell at people though for choosing differently. And it is questionable to get you anywhere anytime fast. And I do not like that Gene was called an "epitome of humanity" in a cynical way and I earned a hypocrite long after I copped out of that discussion. Please let this rest. -H -- Henning Follmann | hfollm...@itcfollmann.com
Re: OT: Top Posting
On 5/15/24 6:46 AM, Cindy Sue Causey wrote: . . . No its not, its your refusal to use the down arrow in your reply editor to put your reply after the question. It really is that simple. If your choice of email agents cannot do that, its time to switch to an agent that can. There are dozens of them. . . . Actually, it isn't necessarily the user's fault. Thanks to the "business standard," (and think about the initials) of top-posting over the complete, unpared quote of the entire thread, there are an awful lot of email readers (and especially webmail interfaces) that make it difficult to follow any other convention, and a few that make it damn-near impossible. Just as there are an awful lot that make it difficult or impossible to send a plain-text email. Incidentally, regarding the Hollerith card origins of the 80-column standard, the very first Hollerith cards, from the 1890 U.S. Census, had 24 columns and 12 rows of round holes, and were punched with a pantograph punch. In 1928, IBM introduced rectangular holes, in an 80-column, 10-row format, later expanded to 12 rows. -- JHHL
Re: OT: Top Posting
On 5/15/24 10:50, Nicolas George wrote: Cindy Sue Causey (12024-05-15): PS Afterthought is that email signatures are another of that widely accepted netiquette set of standards. You can add the “Re: ” to that list. It is the sequence of four octets 0x52, 0x65, 0x3a, 0x20, and nothing else. The MUAs who write “RE: ” are wrong. The MUAs who write “Re : ” are wrong. The MUAs who write “AW: ” are wrong. The MUAs who put it in base64 are wrong. It is not a string that is designed to be internationalized, we cannot expect every MUA to know every stupid local or vanity variant of “Re: ”. + 5, Excellent point Nicolas The same can be said for sig separators. One fellow here has it as part of his sig but his definition in his sig is incomplete. Its actually an lf,dash,dash,space.lf ignoring the comma's I used here..Some email agents won't use it as a sig separator w/o the full lf's as wrapper. cr's are not valid subs for the lf's.. Regards, Take care & stay well Nicolas. Cheers, Gene Heskett, CET. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: Markup in mail messages
On Wed, 2024-05-15 at 15:57 +0100, Darac Marjal wrote: > On 15/05/2024 03:17, Max Nikulin wrote: > > > On 15/05/2024 02:32, Greg Wooledge wrote: > > > > > On Tue, May 14, 2024 at 08:16:20PM +0200, Nicolas George wrote: > > > > > > > Messages in Markdown in the Windows world? I have never seen it. > > > > > > > [...] > > > > > The only sensible interpretation I can > > > come up with for why these asterisks were added is that they're being > > > placed around text that's supposed to be emphasized/italicized. > > > > > > *Bold*, /italics/, and _underlined_ markup is supported by various > > mailers, e.g. Thunderbird and Gnus. Some render superscripts^1 and > > subscripts_2 as well. > > > > Backticks (`echo $PATH`) are more specific to markdown. However > > sometimes I use them not expecting that the message will be rendered as > > markdown. Just to avoid ambiguity where a piece of code starts and ends. > > > > When this sort of subject comes up (as it does, every so often), I > wonder why `text/markdown` isn't offered as a mime type for sending > emails. If you're an MUA and you're going to parse text/plain for > markup, then why not offer text/markdown as the body of the message? I > know that there have been various attempts to bridge the gap between > "text/plain is too basic" and "text/html is too powerful" such as > text/enriched and text/rtf, but Markdown seems to be hitting a sweet > spot of being easy to write and being widely adopted elsewhere. Evolution delivers on a markdown option.\ Cheers!
Regression in Radeon driver in latest Debian Stable kernel
Hello, I have reported a regression in latest Linux kernel in Debian Stable: segfault at amdgpu_dm_atomic_commit_tail https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071080 It throws a lot of errors related to AMD GPU every day. I also experienced full desktop hang, where I had to restart my computer: https://bugs.kde.org/show_bug.cgi?id=486970 This happens on 6.1.0-21-amd64. Booting previous version 6.1.0-20-amd64 solves all problems. Can anyone help me with getting attention from some developers? KDE dev said this is downstream, not KDE problem. Debian bug reported, but no reply from anyone yet. -- With kindest regards, Piotr. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄
Re: Regression in Radeon driver in latest Debian Stable kernel
On 15 May 2024 20:40 +0100, from pior...@gmx.com (piorunz): > I have reported a regression in latest Linux kernel in Debian Stable: > > segfault at amdgpu_dm_atomic_commit_tail > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071080 You made this bug report less than 48 hours ago. While I can certainly understand that you would like to see it fixed, that's not an inordinate amount of time to wait. What probably _would_ be helpful is to see whether you can recreate the same scenario with the vanilla kernel.org kernels of the same versions; confirming that the issue exists with the vanilla 6.1.90 kernel _and_ that the issue goes away when booting the vanilla kernel of whatever exact version your earlier package is (I'm guessing 6.1.85), both when built with the same configuration options as the kernels shipped by Debian. That would confirm whether what you are seeing is something somehow introduced by Debian, or an upstream bug. -- Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Re: Security hole in kernel fixed?
ср, 15 мая 2024 г. в 16:55, Hans : > Dear developers, Users. > in April 2024 the security hole CVE-2023-6546 was discovered in linux-image, > and I believe, it is fixed in kernel 6.1.0 (from debian/stable) as soon after > this a new kernel was released. https://security-tracker.debian.org/tracker/CVE-2023-6546 may be help -- Stanislav
