Bug with /dev/vcs* devices

PATCH In review Storm Dragon 7 participants 23 messages Feb 19, 2023 – Mar 10, 2023

Subsystems (2)

TTY layer and serial drivers Regressions

lore

Share & tools

lore

Storm Dragon

author

2023-02-19 21:21 UTC #0 lore raw

Howdy,

This is my first time ever submitting a kernel bug, so I apologize if this is the wrong place. As per the instructions I found, I first filed a bug in Arch Linux:

https://bugs.archlinux.org/task/77575

I will add the contents of the response here:

For the record, here are the 2 associated mailing list threads [1][2].

The reason why it affects both LTS and current linux is because it appears a security patch was applied to both trees to fix a UAF (use after free) bug.

If that patch is problematic, you should report it upstream to the kernel folks. Maybe even email the patch author directly. It's this patch [3]. Please let us know what you find out.

[1] https://lists.archlinux.org/archives/list/arch-general%40lists.archlinux.org/thread/EOSHIVGUZLNAD7BPHSUGOXFYSAFWDYH7/
[2] https://lists.archlinux.org/archives/list/arch-general%40lists.archlinux.org/thread/S6R6UDUMX2LWL4HJ74MFNYOES45UBFLF/
[3] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/tty/vt/vc_screen.c?h=v5.15.94&id=fc9e27f3ba083534b8bbf72ab0f5c810ffdc7d18

----------End Response ----------

Methods for reproducing the bug are included in the link to the bug above. But I will include one of them here as well. As root:

[root@mjollnir ~]# cat /dev/vcsa1

cat: /dev/vcsa1: No such device or address

The contents is displayed very briefly before the No such device or address error.

Thank you,
Storm

Randy Dunlap

2023-02-19 22:11 UTC #1 lore raw

[add George and Greg]

@Storm: You should always send emails directly to someone as well as to the mailing list.

Quoted 27 lines · Storm Dragon

Howdy,
This is my first time ever submitting a kernel bug, so I apologize if this is the wrong place. As per the instructions I found, I first filed a bug in Arch Linux:
https://bugs.archlinux.org/task/77575
I will add the contents of the response here:
For the record, here are the 2 associated mailing list threads [1][2].
                                                                                                                                                                The reason why it affects both LTS and current linux is because it appears a security patch was applied to both trees to fix a UAF (use after free) bug. If that patch is problematic, you should report it upstream to the kernel folks. Maybe even email the patch author directly. It's this patch [3]. Please let us know what you find out.
                                                                                                                                                                [1] https://lists.archlinux.org/archives/list/arch-general%40lists.archlinux.org/thread/EOSHIVGUZLNAD7BPHSUGOXFYSAFWDYH7/
[2] https://lists.archlinux.org/archives/list/arch-general%40lists.archlinux.org/thread/S6R6UDUMX2LWL4HJ74MFNYOES45UBFLF/
[3] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/tty/vt/vc_screen.c?h=v5.15.94&id=fc9e27f3ba083534b8bbf72ab0f5c810ffdc7d18
----------End Response ----------
Methods for reproducing the bug are included in the link to the bug above. But I will include one of them here as well. As root:
[root@mjollnir ~]# cat /dev/vcsa1
                                                                                                                                                                   cat: /dev/vcsa1: No such device or address
The contents is displayed very briefly before the No such device or address error.
Thank you,
Storm

Signature · 1 line

~Randy

Storm Dragon

author

2023-02-19 23:13 UTC #2 lore raw

Quoted 5 lines · Randy Dunlap

[add George and Greg]
@Storm: You should always send emails directly to someone as well as to the mailing list.

Howdy Randy,

Thank you for adding the correct people. I thought I put someone in CC, but apparently it did not work as expected. Part of the problem caused by this bug is it causes my screen reader to behave a little strangely sometimes. in this case, it read the CC field, but I must have put the address in a different field, maybe bcc, or somewhere that caused it to be dropped. Of course, it is probably a good thing, because the address I found was not the one you added.

Thanks,
Storm

[email protected]

2023-02-20 06:46 UTC #3 lore raw

PATCH 1/1 vc_screen: don't clobber return value in vcs_read

From: Thomas Weißschuh <[email protected]>

Commit 226fae124b2d
("vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF") moved the call to vcs_vc() into the loop.
While doing this it also moved the unconditional assignment of "ret = -ENXIO".
This unconditional assignment was valid outside the loop but within it it clobbers the actual value of ret.

To avoid this only assign "ret = -ENXIO" when actually needed.

Reported-by Storm Dragon <[email protected]>

Link https://lore.kernel.org/lkml/Y%[email protected]/ open here

Fixes 226fae124b2d ("vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF")

Signed-off-by Thomas Weißschuh <[email protected]>

---

@Storm Could you validate this patch?

---
 drivers/tty/vt/vc_screen.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

drivers/tty/vt/vc_screen.c +3 -2

index f566eb1839dc..2ef519a40a87 100644
@@ -403,10 +403,11 @@ vcs_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
 		unsigned int this_round, skip = 0;
 		int size;
 
-		ret = -ENXIO;
 		vc = vcs_vc(inode, &viewed);
-		if (!vc)
+		if (!vc) {
+			ret = -ENXIO;
 			goto unlock_out;
+		}
 
 		/* Check whether we are above size each round,
 		 * as copy_to_user at the end of this loop

base-commit: c9c3395d5e3dcc6daee66c6908354d47bf98cb0c

Signature · 1 line

2.39.2

Jiri Slaby

maintainer

2023-02-20 11:49 UTC #4 lore raw

Re: [PATCH] vc_screen: don't clobber return value in vcs_read

Quoted 11 lines · On 20. 02. 23, 7:46, [email protected] wrote:

From: Thomas Weißschuh <[email protected]>
Commit 226fae124b2d
("vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF") moved the call to vcs_vc() into the loop.
While doing this it also moved the unconditional assignment of "ret = -ENXIO".
This unconditional assignment was valid outside the loop but within it it clobbers the actual value of ret.
To avoid this only assign "ret = -ENXIO" when actually needed.

Not sure -- I cannot find it -- but hasn't George fixed this yet?

Quoted 32 lines

Reported-by Storm Dragon <[email protected]>
Link https://lore.kernel.org/lkml/Y%[email protected]/ open here
Fixes 226fae124b2d ("vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF")
Signed-off-by Thomas Weißschuh <[email protected]>
---
@Storm Could you validate this patch?
---
  drivers/tty/vt/vc_screen.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)
drivers/tty/vt/vc_screen.c +3 -2
index f566eb1839dc..2ef519a40a87 100644
@@ -403,10 +403,11 @@ vcs_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
  		unsigned int this_round, skip = 0;
  		int size;
 
-		ret = -ENXIO;
  		vc = vcs_vc(inode, &viewed);
-		if (!vc)
+		if (!vc) {
+			ret = -ENXIO;
  			goto unlock_out;
+		}
 
  		/* Check whether we are above size each round,
  		 * as copy_to_user at the end of this loop
base-commit: c9c3395d5e3dcc6daee66c6908354d47bf98cb0c

Signature · 2 lines

js
suse labs

Thomas Weißschuh

2023-02-20 16:34 UTC #5 lore raw

Re: [PATCH] vc_screen: don't clobber return value in vcs_read

+Cc people who were involved in the original thread.

Quoted 11 lines · Jiri Slaby

Quoted 10 lines · On 20. 02. 23, 7:46, [email protected] wrote:
From: Thomas Weißschuh <[email protected]>
Commit 226fae124b2d
("vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF") moved the call to vcs_vc() into the loop.
While doing this it also moved the unconditional assignment of "ret = -ENXIO".
This unconditional assignment was valid outside the loop but within it it clobbers the actual value of ret.

Quoted 3 lines

Quoted 1 line
To avoid this only assign "ret = -ENXIO" when actually needed.
Not sure -- I cannot find it -- but hasn't George fixed this yet?

Indeed there was a proposed fix at
https://lore.kernel.org/lkml/[email protected]/

Linus had some suggestions so it was not applied as is.

I'm not sure what the current state is.
George, do you have something in the pipeline?

I also tested the patch proposed by Linus as attachment and that works. (The small inline patch snippet doesn't)

Quoted 35 lines

Quoted 30 lines
Reported-by Storm Dragon <[email protected]>
Link https://lore.kernel.org/lkml/Y%[email protected]/ open here
Fixes 226fae124b2d ("vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF")
Signed-off-by Thomas Weißschuh <[email protected]>
---
@Storm Could you validate this patch?
---
  drivers/tty/vt/vc_screen.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)
drivers/tty/vt/vc_screen.c +3 -2
index f566eb1839dc..2ef519a40a87 100644
@@ -403,10 +403,11 @@ vcs_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
  		unsigned int this_round, skip = 0;
  		int size;
-		ret = -ENXIO;
  		vc = vcs_vc(inode, &viewed);
-		if (!vc)
+		if (!vc) {
+			ret = -ENXIO;
  			goto unlock_out;
+		}
  		/* Check whether we are above size each round,
  		 * as copy_to_user at the end of this loop
 
base-commit: c9c3395d5e3dcc6daee66c6908354d47bf98cb0c
Signature · 2 lines
js
suse labs

George Kennedy

2023-02-21 13:31 UTC #6 lore raw

Re: [PATCH] vc_screen: don't clobber return value in vcs_read

Quoted 15 lines · Thomas Weißschuh

+Cc people who were involved in the original thread.
Quoted 12 lines · Jiri Slaby
Quoted 11 lines · On 20. 02. 23, 7:46, [email protected] wrote:
From: Thomas Weißschuh <[email protected]>
Commit 226fae124b2d
("vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF") moved the call to vcs_vc() into the loop.
While doing this it also moved the unconditional assignment of "ret = -ENXIO".
This unconditional assignment was valid outside the loop but within it it clobbers the actual value of ret.
To avoid this only assign "ret = -ENXIO" when actually needed.

Quoted 8 lines

Quoted 1 line
Not sure -- I cannot find it -- but hasn't George fixed this yet?
Indeed there was a proposed fix at
https://lore.kernel.org/lkml/[email protected]/
Linus had some suggestions so it was not applied as is.
I'm not sure what the current state is.
George, do you have something in the pipeline?

Yes, that is in the pipeline:
https://lore.kernel.org/lkml/[email protected]/

Linus suggested the fix, which was tested and submitted.

Jiri commented on the patch, which I believe was directed at Linus as he suggested the fix.

George

Quoted 38 lines

I also tested the patch proposed by Linus as attachment and that works. (The small inline patch snippet doesn't)
Quoted 34 lines
Quoted 30 lines
Reported-by Storm Dragon <[email protected]>
Link https://lore.kernel.org/lkml/Y%[email protected]/ open here
Fixes 226fae124b2d ("vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF")
Signed-off-by Thomas Weißschuh <[email protected]>
---
@Storm Could you validate this patch?
---
   drivers/tty/vt/vc_screen.c | 5 +++--
   1 file changed, 3 insertions(+), 2 deletions(-)
drivers/tty/vt/vc_screen.c +3 -2
index f566eb1839dc..2ef519a40a87 100644
@@ -403,10 +403,11 @@ vcs_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
   		unsigned int this_round, skip = 0;
   		int size;
-		ret = -ENXIO;
   		vc = vcs_vc(inode, &viewed);
-		if (!vc)
+		if (!vc) {
+			ret = -ENXIO;
   			goto unlock_out;
+		}
   		/* Check whether we are above size each round,
   		 * as copy_to_user at the end of this loop
 
base-commit: c9c3395d5e3dcc6daee66c6908354d47bf98cb0c
Signature · 2 lines
js
suse labs

Thomas Weißschuh

2023-02-21 13:50 UTC #7 lore raw

Re: [PATCH] vc_screen: don't clobber return value in vcs_read

Quoted 27 lines · George Kennedy

Quoted 15 lines · Thomas Weißschuh
+Cc people who were involved in the original thread.
Quoted 12 lines · Jiri Slaby
Quoted 11 lines · On 20. 02. 23, 7:46, [email protected] wrote:
From: Thomas Weißschuh <[email protected]>
Commit 226fae124b2d
("vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF") moved the call to vcs_vc() into the loop.
While doing this it also moved the unconditional assignment of "ret = -ENXIO".
This unconditional assignment was valid outside the loop but within it it clobbers the actual value of ret.
To avoid this only assign "ret = -ENXIO" when actually needed.
Quoted 8 lines
Quoted 1 line
Not sure -- I cannot find it -- but hasn't George fixed this yet?
Indeed there was a proposed fix at
https://lore.kernel.org/lkml/[email protected]/
Linus had some suggestions so it was not applied as is.
I'm not sure what the current state is.
George, do you have something in the pipeline?

Quoted 7 lines

Yes, that is in the pipeline:
https://lore.kernel.org/lkml/[email protected]/
Linus suggested the fix, which was tested and submitted.
Jiri commented on the patch, which I believe was directed at Linus as he suggested the fix.

Thanks for the pointer!

I searched for it by its Fixes: tag.
The v2 has a different one than the v1.
To me the v1 Fixes: seems more correct, was the change intentional?

Quoted 40 lines

George
Quoted 38 lines
I also tested the patch proposed by Linus as attachment and that works. (The small inline patch snippet doesn't)
Quoted 34 lines
Quoted 30 lines
Reported-by Storm Dragon <[email protected]>
Link https://lore.kernel.org/lkml/Y%[email protected]/ open here
Fixes 226fae124b2d ("vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF")
Signed-off-by Thomas Weißschuh <[email protected]>
---
@Storm Could you validate this patch?
---
   drivers/tty/vt/vc_screen.c | 5 +++--
   1 file changed, 3 insertions(+), 2 deletions(-)
drivers/tty/vt/vc_screen.c +3 -2
index f566eb1839dc..2ef519a40a87 100644
@@ -403,10 +403,11 @@ vcs_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
   		unsigned int this_round, skip = 0;
   		int size;
-		ret = -ENXIO;
   		vc = vcs_vc(inode, &viewed);
-		if (!vc)
+		if (!vc) {
+			ret = -ENXIO;
   			goto unlock_out;
+		}
   		/* Check whether we are above size each round,
   		 * as copy_to_user at the end of this loop
 
base-commit: c9c3395d5e3dcc6daee66c6908354d47bf98cb0c
Signature · 2 lines
js
suse labs

Greg Kroah-Hartman

maintainer

2023-02-21 13:50 UTC #8 lore raw

Re: [PATCH] vc_screen: don't clobber return value in vcs_read

In reply to George Kennedy

Quoted 27 lines · George Kennedy

Quoted 15 lines · Thomas Weißschuh
+Cc people who were involved in the original thread.
Quoted 12 lines · Jiri Slaby
Quoted 11 lines · On 20. 02. 23, 7:46, [email protected] wrote:
From: Thomas Weißschuh <[email protected]>
Commit 226fae124b2d
("vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF") moved the call to vcs_vc() into the loop.
While doing this it also moved the unconditional assignment of "ret = -ENXIO".
This unconditional assignment was valid outside the loop but within it it clobbers the actual value of ret.
To avoid this only assign "ret = -ENXIO" when actually needed.
Quoted 8 lines
Quoted 1 line
Not sure -- I cannot find it -- but hasn't George fixed this yet?
Indeed there was a proposed fix at
https://lore.kernel.org/lkml/[email protected]/
Linus had some suggestions so it was not applied as is.
I'm not sure what the current state is.
George, do you have something in the pipeline?

Quoted 7 lines

Yes, that is in the pipeline:
https://lore.kernel.org/lkml/[email protected]/
Linus suggested the fix, which was tested and submitted.
Jiri commented on the patch, which I believe was directed at Linus as he suggested the fix.

And I was waiting for a new version from you based on those comments :(

Can you fix that up and send?

thanks,

greg k-h

Linux regression tracking (Thorsten Leemhuis)

2023-02-27 14:20 UTC #9 lore raw

Re: [PATCH] vc_screen: don't clobber return value in vcs_read

Hi, this is your Linux kernel regression tracker. Top-posting for once, to make this easily accessible to everyone.

George, is there anything we can do to help you moving forward to finally get this regression fixed? It seems (or am I missing something?) everyone is waiting for you (see below) to act on the feedback Jiri provided here:

https://lore.kernel.org/lkml/[email protected]/

Side note: would be good to add a "Link:" tag pointing to the start of this thread as well, but that's just a detail.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) --
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

Quoted 34 lines · Greg Kroah-Hartman

Quoted 25 lines · George Kennedy
Quoted 15 lines · Thomas Weißschuh
+Cc people who were involved in the original thread.
Quoted 12 lines · Jiri Slaby
Quoted 11 lines · On 20. 02. 23, 7:46, [email protected] wrote:
From: Thomas Weißschuh <[email protected]>
Commit 226fae124b2d
("vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF") moved the call to vcs_vc() into the loop.
While doing this it also moved the unconditional assignment of "ret = -ENXIO".
This unconditional assignment was valid outside the loop but within it it clobbers the actual value of ret.
To avoid this only assign "ret = -ENXIO" when actually needed.
Quoted 8 lines
Quoted 1 line
Not sure -- I cannot find it -- but hasn't George fixed this yet?
Indeed there was a proposed fix at
https://lore.kernel.org/lkml/[email protected]/
Linus had some suggestions so it was not applied as is.
I'm not sure what the current state is.
George, do you have something in the pipeline?
Quoted 7 lines
Yes, that is in the pipeline:
https://lore.kernel.org/lkml/[email protected]/
Linus suggested the fix, which was tested and submitted.
Jiri commented on the patch, which I believe was directed at Linus as he suggested the fix.

Quoted 7 lines

And I was waiting for a new version from you based on those comments :(
Can you fix that up and send?
thanks,
greg k-h

#regzbot monitor:
https://lore.kernel.org/lkml/[email protected]/
#regzbot poke

George Kennedy

2023-02-27 20:00 UTC #10 lore raw

Re: [PATCH] vc_screen: don't clobber return value in vcs_read

Hello Thomas,

Quoted 8 lines · Linux regression tracking (Thorsten Leemhuis)

Hi, this is your Linux kernel regression tracker. Top-posting for once, to make this easily accessible to everyone.
George, is there anything we can do to help you moving forward to finally get this regression fixed? It seems (or am I missing something?) everyone is waiting for you (see below) to act on the feedback Jiri provided here:

Quoted 4 lines

https://lore.kernel.org/lkml/[email protected]/
Side note: would be good to add a "Link:" tag pointing to the start of this thread as well, but that's just a detail.

I just sent the requested patch up for review.

https://lore.kernel.org/lkml/[email protected]/

Last post on the previous patch that led to the requested patch:
https://lore.kernel.org/lkml/[email protected]/

Thank you,
George

Quoted 50 lines

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) --
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.
Quoted 32 lines · Greg Kroah-Hartman
Quoted 24 lines · George Kennedy
Quoted 15 lines · Thomas Weißschuh
+Cc people who were involved in the original thread.
Quoted 12 lines · Jiri Slaby
Quoted 11 lines · On 20. 02. 23, 7:46, [email protected] wrote:
From: Thomas Weißschuh <[email protected]>
Commit 226fae124b2d
("vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF") moved the call to vcs_vc() into the loop.
While doing this it also moved the unconditional assignment of "ret = -ENXIO".
This unconditional assignment was valid outside the loop but within it it clobbers the actual value of ret.
To avoid this only assign "ret = -ENXIO" when actually needed.
Quoted 8 lines
Quoted 1 line
Not sure -- I cannot find it -- but hasn't George fixed this yet?
Indeed there was a proposed fix at
https://lore.kernel.org/lkml/[email protected]/
Linus had some suggestions so it was not applied as is.
I'm not sure what the current state is.
George, do you have something in the pipeline?
Quoted 7 lines
Yes, that is in the pipeline:
https://lore.kernel.org/lkml/[email protected]/
Linus suggested the fix, which was tested and submitted.
Jiri commented on the patch, which I believe was directed at Linus as he suggested the fix.
Quoted 7 lines
And I was waiting for a new version from you based on those comments :(
Can you fix that up and send?
thanks,
greg k-h
#regzbot monitor:
https://lore.kernel.org/lkml/[email protected]/
#regzbot poke

Linux regression tracking (Thorsten Leemhuis)

2023-02-28 05:38 UTC #11 lore raw

Re: [PATCH] vc_screen: don't clobber return value in vcs_read

Quoted 11 lines · George Kennedy

Hello Thomas,
Quoted 8 lines · Linux regression tracking (Thorsten Leemhuis)
Hi, this is your Linux kernel regression tracker. Top-posting for once, to make this easily accessible to everyone.
George, is there anything we can do to help you moving forward to finally get this regression fixed? It seems (or am I missing something?) everyone is waiting for you (see below) to act on the feedback Jiri provided here:

Quoted 8 lines

Quoted 4 lines
https://lore.kernel.org/lkml/[email protected]/
Side note: would be good to add a "Link:" tag pointing to the start of this thread as well, but that's just a detail.
I just sent the requested patch up for review.
https://lore.kernel.org/lkml/[email protected]/

Thx for handling this!

And I see it very quickly made its way to mainline. :-D

Ciao, Thorsten

Quoted 49 lines

Quoted 46 lines · Greg Kroah-Hartman
Quoted 35 lines · George Kennedy
Quoted 26 lines · Thomas Weißschuh
Quoted 17 lines
+Cc people who were involved in the original thread.
Quoted 14 lines · Jiri Slaby
Quoted 13 lines · On 20. 02. 23, 7:46, [email protected] wrote:
From: Thomas Weißschuh <[email protected]>
Commit 226fae124b2d
("vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF")
moved the call to vcs_vc() into the loop.
While doing this it also moved the unconditional assignment of "ret = -ENXIO".
This unconditional assignment was valid outside the loop but within it
it clobbers the actual value of ret.
To avoid this only assign "ret = -ENXIO" when actually needed.
Quoted 8 lines
Quoted 1 line
Not sure -- I cannot find it -- but hasn't George fixed this yet?
Indeed there was a proposed fix at
https://lore.kernel.org/lkml/[email protected]/
Linus had some suggestions so it was not applied as is.
I'm not sure what the current state is.
George, do you have something in the pipeline?
Quoted 8 lines
Yes, that is in the pipeline:
https://lore.kernel.org/lkml/[email protected]/
Linus suggested the fix, which was tested and submitted.
Jiri commented on the patch, which I believe was directed at Linus as he
suggested the fix.
Quoted 7 lines
And I was waiting for a new version from you based on those comments :(
Can you fix that up and send?
thanks,
greg k-h
#regzbot monitor:
https://lore.kernel.org/lkml/[email protected]/
#regzbot poke

Storm Dragon

author

2023-02-20 16:06 UTC #12 lore raw

Re: [PATCH] vc_screen: don't clobber return value in vcs_read

In reply to [email protected]

Quoted 3 lines · On Mon, Feb 20, 2023 at 06:46:12AM +0000, [email protected] wrote:

From: Thomas Weißschuh <[email protected]>
@Storm Could you validate this patch?

I am willing to test, but I have almost no experience doing anything with the kernel other than upgrading it from time to time. Can you send me some instructions for testing this?

Thanks,
Storm

Thomas Weißschuh

2023-03-03 21:13 UTC #13 lore raw

Re: [PATCH] vc_screen: don't clobber return value in vcs_read

Quoted 9 lines · Storm Dragon

Quoted 3 lines · On Mon, Feb 20, 2023 at 06:46:12AM +0000, [email protected] wrote:
From: Thomas Weißschuh <[email protected]>
@Storm Could you validate this patch?
I am willing to test, but I have almost no experience doing anything with the kernel other than upgrading it from time to time. Can you send me some instructions for testing this?

Sorry for the long delay, but this should be fixed in the current round of stable kernels. Can you try the following:

pacman -U https://mirrors.edge.kernel.org/archlinux/testing/os/x86_64/linux-6.2.2.arch1-1-x86_64.pkg.tar.zst

Thomas

Storm Dragon

author

2023-03-03 21:53 UTC #14 lore raw

Re: [PATCH] vc_screen: don't clobber return value in vcs_read

Quoted 6 lines · Thomas Weißschuh

Sorry for the long delay, but this should be fixed in the current round of stable kernels. Can you try the following:
pacman -U https://mirrors.edge.kernel.org/archlinux/testing/os/x86_64/linux-6.2.2.arch1-1-x86_64.pkg.tar.zst
Thomas

I have installed the package above. My screen reader is behaving much better now. Interestingly, however, trying to cat the /dev/vcs device still shows the following:

cat: /dev/vcs: No such device or address

cat: /dev/vcsa: No such device or address

cat: /dev/vcsa1: No such device or address

Is this expected behavior?

Thomas Weißschuh

2023-03-03 23:25 UTC #15 lore raw

Re: [PATCH] vc_screen: don't clobber return value in vcs_read

Quoted 12 lines · Storm Dragon

Quoted 6 lines · Thomas Weißschuh
Sorry for the long delay, but this should be fixed in the current round of stable kernels. Can you try the following:
pacman -U https://mirrors.edge.kernel.org/archlinux/testing/os/x86_64/linux-6.2.2.arch1-1-x86_64.pkg.tar.zst
Thomas
I have installed the package above. My screen reader is behaving much better now. Interestingly, however, trying to cat the /dev/vcs device still shows the following:

Quoted 7 lines

cat: /dev/vcs: No such device or address
cat: /dev/vcsa: No such device or address
cat: /dev/vcsa1: No such device or address
Is this expected behavior?

No it isn't.

Is this reliably reproducible? I doesn't happen on my side. Maybe you can provide more detailed reproduction steps.

Just to be sure; did you reboot into the new kernel?

Does this mean the screenreader now works correctly or is it still broken somehow?

Thomas

Storm Dragon

author

2023-03-04 03:30 UTC #16 lore raw

Re: [PATCH] vc_screen: don't clobber return value in vcs_read

Quoted 11 lines · Thomas Weißschuh

No it isn't.
Is this reliably reproducible? I doesn't happen on my side. Maybe you can provide more detailed reproduction steps.
Just to be sure; did you reboot into the new kernel?
Does this mean the screenreader now works correctly or is it still broken somehow?
Thomas

I found the problem when I was writing the steps I did to reproduce it. I did install the kernel, I did reboot, but I did not uninstall the lts kernel I was using currently, nor did I run grub-mkconfig. Now that I have done things the right way, it works as expected. Everything is awesome again.

Thanks, and sorry for the false alarm.
Storm

Storm Dragon

author

2023-03-04 03:42 UTC #17 lore raw

Re: [PATCH] vc_screen: don't clobber return value in vcs_read

In reply to Thomas Weißschuh

Quoted 4 lines · Thomas Weißschuh

Does this mean the screenreader now works correctly or is it still broken somehow?
Thomas

I forgot to answer the screen reader question. I hadn't rebooted in a while, and I forgot that the work around Chrys put in place for Fenrir does really well until the screen fills up. So, right after I sent the message saying it was working better, it reverted to doing its weird jumps and things caused by the bug. Now that the correct version is actually running, it really is better.

Thanks,
Storm

Storm Dragon

author

2023-03-04 19:58 UTC #18 lore raw

Re: [PATCH] vc_screen: don't clobber return value in vcs_read

In reply to Thomas Weißschuh

Quoted 4 lines · Thomas Weißschuh

Does this mean the screenreader now works correctly or is it still broken somehow?
Thomas

I have still been testing this kernel. Most things work as expected, but the pasting functionality for Fenrir's clipboard is broken. After checking into the problem, it seems that tiocsti is disabled, and that is causing the problem. Was that something done in this test kernel only, or will that be the default for all new Arch kernels? If it is the default, is there a way to turn it back on? I tried the following:

[storm@mjollnir ~] $ sudo sysctl dev.tty.legacy_tiocsti=1
sysctl: setting key "dev.tty.legacy_tiocsti": Invalid argument

Thanks,
Storm

Thomas Weißschuh

2023-03-04 22:35 UTC #19 lore raw

Re: [PATCH] vc_screen: don't clobber return value in vcs_read

Quoted 5 lines · Storm Dragon

Quoted 3 lines · Thomas Weißschuh
Does this mean the screenreader now works correctly or is it still broken somehow?

Quoted 8 lines

Quoted 1 line
Thomas
I have still been testing this kernel. Most things work as expected, but the pasting functionality for Fenrir's clipboard is broken. After checking into the problem, it seems that tiocsti is disabled, and that is causing the problem. Was that something done in this test kernel only, or will that be the default for all new Arch kernels? If it is the default, is there a way to turn it back on?

By now this package has been promoted to [core] so it is in fact the default ArchLinux kernel.

As a workaround you can use the "linux-lts" package that now also carries the fix for your original problem but not the code responsible for the new issue.

pacman -Sy linux-lts

Quoted 4 lines

I tried the following:
[storm@mjollnir ~] $ sudo sysctl dev.tty.legacy_tiocsti=1
sysctl: setting key "dev.tty.legacy_tiocsti": Invalid argument

This is indeed the correct way to enable the feature again.

It seems that the commit that introduced this sysctl[0] depends on another commit [1] to be applied. But the 6.2.2 stable kernel is missing the requirement.

I'll validate that this indeed is the issue and will then send a formal request for backporting.

[0] 83efeeeb3d04 ("tty: Allow TIOCSTI to be disabled")
[1] f1aa2eb5ea05 ("sysctl: fix proc_dobool() usability")

Thomas Weißschuh

2023-03-10 21:32 UTC #20 lore raw

Re: [PATCH] vc_screen: don't clobber return value in vcs_read

In reply to Storm Dragon

Quoted 14 lines · Storm Dragon

Quoted 4 lines · Thomas Weißschuh
Does this mean the screenreader now works correctly or is it still broken somehow?
Thomas
I have still been testing this kernel. Most things work as expected, but the pasting functionality for Fenrir's clipboard is broken. After checking into the problem, it seems that tiocsti is disabled, and that is causing the problem. Was that something done in this test kernel only, or will that be the default for all new Arch kernels? If it is the default, is there a way to turn it back on? I tried the following:

Quoted 2 lines

[storm@mjollnir ~] $ sudo sysctl dev.tty.legacy_tiocsti=1
sysctl: setting key "dev.tty.legacy_tiocsti": Invalid argument

The sysctl to enable the ioctl should be fixed in 6.2.3:

pacman -U https://mirrors.edge.kernel.org/archlinux/testing/os/x86_64/linux-6.2.3.arch1-1-x86_64.pkg.tar.zst

Thomas

Thomas Weißschuh

2023-02-24 14:25 UTC #21 lore raw

In reply to Storm Dragon

Quoted 20 lines · Storm Dragon

Howdy,
This is my first time ever submitting a kernel bug, so I apologize if this is the wrong place. As per the instructions I found, I first filed a bug in Arch Linux:
https://bugs.archlinux.org/task/77575
I will add the contents of the response here:
For the record, here are the 2 associated mailing list threads [1][2].
The reason why it affects both LTS and current linux is because it appears a security patch was applied to both trees to fix a UAF (use after free) bug. If that patch is problematic, you should report it upstream to the kernel folks. Maybe even email the patch author directly. It's this patch [3]. Please let us know what you find out.
[1] https://lists.archlinux.org/archives/list/arch-general%40lists.archlinux.org/thread/EOSHIVGUZLNAD7BPHSUGOXFYSAFWDYH7/
[2] https://lists.archlinux.org/archives/list/arch-general%40lists.archlinux.org/thread/S6R6UDUMX2LWL4HJ74MFNYOES45UBFLF/
[3] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/tty/vt/vc_screen.c?h=v5.15.94&id=fc9e27f3ba083534b8bbf72ab0f5c810ffdc7d18
----------End Response ----------
Methods for reproducing the bug are included in the link to the bug above. But I will include one of them here as well. As root:

Quoted 7 lines

[root@mjollnir ~]# cat /dev/vcsa1
cat: /dev/vcsa1: No such device or address
The contents is displayed very briefly before the No such device or address error.
Thank you,
Storm

#regzbot title: vc_screen: unexpected ENXIO on read #regzbot introduced: 226fae124b2dac217ea5436060d623ff3385bc34 ^

Linux regression tracking #update (Thorsten Leemhuis)

2023-02-28 04:29 UTC #22 lore raw

[TLDR: This mail in primarily relevant for Linux kernel regression tracking. See link in footer if these mails annoy you.]

Quoted 23 lines · Thomas Weißschuh

Quoted 22 lines · Storm Dragon
This is my first time ever submitting a kernel bug, so I apologize if this is the wrong place. As per the instructions I found, I first filed a bug in Arch Linux:
https://bugs.archlinux.org/task/77575
I will add the contents of the response here:
For the record, here are the 2 associated mailing list threads [1][2].
The reason why it affects both LTS and current linux is because it appears a security patch was applied to both trees to fix a UAF (use after free) bug. If that patch is problematic, you should report it upstream to the kernel folks. Maybe even email the patch author directly. It's this patch [3]. Please let us know what you find out.
[1] https://lists.archlinux.org/archives/list/arch-general%40lists.archlinux.org/thread/EOSHIVGUZLNAD7BPHSUGOXFYSAFWDYH7/
[2] https://lists.archlinux.org/archives/list/arch-general%40lists.archlinux.org/thread/S6R6UDUMX2LWL4HJ74MFNYOES45UBFLF/
[3] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/tty/vt/vc_screen.c?h=v5.15.94&id=fc9e27f3ba083534b8bbf72ab0f5c810ffdc7d18
----------End Response ----------
Methods for reproducing the bug are included in the link to the bug above. But I will include one of them here as well. As root:
[root@mjollnir ~]# cat /dev/vcsa1
cat: /dev/vcsa1: No such device or address

Quoted 7 lines

Quoted 4 lines
The contents is displayed very briefly before the No such device or address error.
Thank you,
Storm
#regzbot title: vc_screen: unexpected ENXIO on read #regzbot introduced: 226fae124b2dac217ea5436060d623ff3385bc34 ^

#regzbot fix: ae3419fbac84

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) --
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
That page also explains what to do if mails like this annoy you.

#regzbot ignore-activity