The reproducer does this:
ioctl(3, TIOCLINUX, TIOCL_SETSEL, selection: xs:3 ys:0 xe:0 ye:0 mode:0) = 0
-> sets the text selection area
ioctl(4, KDFONTOP) with op=0 (con_font_set), charcount=512 width=8 height=32, 0x20000000) = 0
-> changes the font size.
It does not crash with current Linus' head (v5.19-rc8).
Kernel v5.16, which was used by this KASAN report, hasn't received backports
since months, so I tried stable kernel v5.15.58 instead, and this
kernel crashed with the reproducer.
The reproducer brings up two issues with current code:
1. The reproducer uses ioctl(TIOCLINUX, TIOCL_SETSEL) and hands over (invalid)
zero-values for ys and ye for the starting lines.
This is wrong, since the API seems to expect a "1" as the very first line for the selection.
This can be easily fixed by adding checks for zero-values and return -EINVAL if found.
But this bug isn't critical itself and is not the reason for the kernel crash.
Without the checks, the ioctl handler simply wraps the coordinate values and converts them
from:
input selection: xs:3 ys:0 xe:0 ye:0 mode:0 to the new:
vc_selection = xs:2 ys:23 xe:127 ye:23 mode:0
which is the current maximum coordinates for the screen.
Those higher values now trigger issue #2:
After the TIOCL_SETSEL the last line on the screen is now selected. The KDFONTOP ioctl
then sets a 8x32 console font, and replaces the former 8x16 console font.
With the bigger font the current screen selection is now outside the visible screen
and this finally triggeres this backtrace, because vc_do_resize() calls clear_selection()
to unhighlight the selection (which starts to render chars outside of the screen):
drm_fb_helper_sys_imageblit drivers/gpu/drm/drm_fb_helper.c:794 [inline]
drm_fbdev_fb_imageblit+0x15c/0x350 drivers/gpu/drm/drm_fb_helper.c:2288
bit_putcs_unaligned drivers/video/fbdev/core/bitblit.c:124 [inline]
bit_putcs+0x6e1/0xd20 drivers/video/fbdev/core/bitblit.c:173
fbcon_putcs+0x353/0x440 drivers/video/fbdev/core/fbcon.c:1277
do_update_region+0x399/0x630 drivers/tty/vt/vt.c:676
invert_screen+0x1d4/0x600 drivers/tty/vt/vt.c:800
highlight drivers/tty/vt/selection.c:57 [inline]
clear_selection drivers/tty/vt/selection.c:84 [inline]
clear_selection+0x55/0x70 drivers/tty/vt/selection.c:80
vc_do_resize+0xe6e/0x1180 drivers/tty/vt/vt.c:1257
IMHO the easiest way to prevent this crash is to simply clear the
selection before the various con_font_set() console handlers are called.
Otherwise every console driver needs to add checks and verify if the current
selection still fits with the selected font, which gets tricky because some
of those drivers fiddle with the screen width&height before calling vc_do_resize().
I'll follow up to this mail with patches for both issues shortly.
Helge
The line and column numbers for the selection need to start at 1.
Add the checks to prevent invalid input.
Signed-off-by: Helge Deller <deller@gmx.de>
Reported-by: syzbot+14b0e8f3fd1612e35350@syzkaller.appspotmail.com
When changing the console font with ioctl(KDFONTOP) the new font size
can be bigger than the previous font. A previous selection may thus now
be outside of the new screen size and thus trigger out-of-bounds
accesses to graphics memory if the selection is removed in
vc_do_resize().
Prevent such out-of-memory accesses by dropping the selection before the
various con_font_set() console handlers are called.
Signed-off-by: Helge Deller <deller@gmx.de>
Reported-by: syzbot+14b0e8f3fd1612e35350@syzkaller.appspotmail.com
How did you find out the selection values? From strace and man pages I
know the third argument is an address.
-> sets the text selection area
ioctl(4, KDFONTOP) with op=0 (con_font_set), charcount=512 width=8 height=32, 0x20000000) = 0
Same here, It would be very helpful if you could tell me how.
-> changes the font size.
It does not crash with current Linus' head (v5.19-rc8).
I tested in 5.19-rc8 in Qemu x86_64 and it crashed for me.
Kernel v5.16, which was used by this KASAN report, hasn't received backports
since months, so I tried stable kernel v5.15.58 instead, and this
kernel crashed with the reproducer.
The reproducer brings up two issues with current code:
1. The reproducer uses ioctl(TIOCLINUX, TIOCL_SETSEL) and hands over (invalid)
zero-values for ys and ye for the starting lines.
This is wrong, since the API seems to expect a "1" as the very first line for the selection.
This can be easily fixed by adding checks for zero-values and return -EINVAL if found.
But this bug isn't critical itself and is not the reason for the kernel crash.
Without the checks, the ioctl handler simply wraps the coordinate values and converts them
from:
input selection: xs:3 ys:0 xe:0 ye:0 mode:0 to the new:
vc_selection = xs:2 ys:23 xe:127 ye:23 mode:0
which is the current maximum coordinates for the screen.
Those higher values now trigger issue #2:
After the TIOCL_SETSEL the last line on the screen is now selected. The KDFONTOP ioctl
then sets a 8x32 console font, and replaces the former 8x16 console font.
With the bigger font the current screen selection is now outside the visible screen
and this finally triggeres this backtrace, because vc_do_resize() calls clear_selection()
to unhighlight the selection (which starts to render chars outside of the screen):
That makes sense.
drm_fb_helper_sys_imageblit drivers/gpu/drm/drm_fb_helper.c:794 [inline]
drm_fbdev_fb_imageblit+0x15c/0x350 drivers/gpu/drm/drm_fb_helper.c:2288
bit_putcs_unaligned drivers/video/fbdev/core/bitblit.c:124 [inline]
bit_putcs+0x6e1/0xd20 drivers/video/fbdev/core/bitblit.c:173
fbcon_putcs+0x353/0x440 drivers/video/fbdev/core/fbcon.c:1277
do_update_region+0x399/0x630 drivers/tty/vt/vt.c:676
invert_screen+0x1d4/0x600 drivers/tty/vt/vt.c:800
highlight drivers/tty/vt/selection.c:57 [inline]
clear_selection drivers/tty/vt/selection.c:84 [inline]
clear_selection+0x55/0x70 drivers/tty/vt/selection.c:80
vc_do_resize+0xe6e/0x1180 drivers/tty/vt/vt.c:1257
IMHO the easiest way to prevent this crash is to simply clear the
selection before the various con_font_set() console handlers are called.
Otherwise every console driver needs to add checks and verify if the current
selection still fits with the selected font, which gets tricky because some
of those drivers fiddle with the screen width&height before calling vc_do_resize().
I'll follow up to this mail with patches for both issues shortly.
I tested the patches. The crash no longer occurs with the reproducer.
How did you find out the selection values? From strace and man pages I know
the third argument is an address.
Right. It's a pointer into userspace.
I simply added printk debug code to see what's happening.
I've attached that patch below.
quoted
-> sets the text selection area
ioctl(4, KDFONTOP) with op=0 (con_font_set), charcount=512 width=8 height=32, 0x20000000) = 0
Same here, It would be very helpful if you could tell me how.
See patch below.
quoted
-> changes the font size.
It does not crash with current Linus' head (v5.19-rc8).
I tested in 5.19-rc8 in Qemu x86_64 and it crashed for me.
That's strange, since I tested the same. Maybe I did something wrong.
Anyway, the patches I sent applies to all kernel versions.
quoted
Kernel v5.16, which was used by this KASAN report, hasn't received backports
since months, so I tried stable kernel v5.15.58 instead, and this
kernel crashed with the reproducer.
The reproducer brings up two issues with current code:
1. The reproducer uses ioctl(TIOCLINUX, TIOCL_SETSEL) and hands over (invalid)
zero-values for ys and ye for the starting lines.
This is wrong, since the API seems to expect a "1" as the very first line for the selection.
This can be easily fixed by adding checks for zero-values and return -EINVAL if found.
But this bug isn't critical itself and is not the reason for the kernel crash.
Without the checks, the ioctl handler simply wraps the coordinate values and converts them
from:
input selection: xs:3 ys:0 xe:0 ye:0 mode:0 to the new:
vc_selection = xs:2 ys:23 xe:127 ye:23 mode:0
which is the current maximum coordinates for the screen.
Those higher values now trigger issue #2:
After the TIOCL_SETSEL the last line on the screen is now selected. The KDFONTOP ioctl
then sets a 8x32 console font, and replaces the former 8x16 console font.
With the bigger font the current screen selection is now outside the visible screen
and this finally triggeres this backtrace, because vc_do_resize() calls clear_selection()
to unhighlight the selection (which starts to render chars outside of the screen):
That makes sense.
quoted
drm_fb_helper_sys_imageblit drivers/gpu/drm/drm_fb_helper.c:794 [inline]
drm_fbdev_fb_imageblit+0x15c/0x350 drivers/gpu/drm/drm_fb_helper.c:2288
bit_putcs_unaligned drivers/video/fbdev/core/bitblit.c:124 [inline]
bit_putcs+0x6e1/0xd20 drivers/video/fbdev/core/bitblit.c:173
fbcon_putcs+0x353/0x440 drivers/video/fbdev/core/fbcon.c:1277
do_update_region+0x399/0x630 drivers/tty/vt/vt.c:676
invert_screen+0x1d4/0x600 drivers/tty/vt/vt.c:800
highlight drivers/tty/vt/selection.c:57 [inline]
clear_selection drivers/tty/vt/selection.c:84 [inline]
clear_selection+0x55/0x70 drivers/tty/vt/selection.c:80
vc_do_resize+0xe6e/0x1180 drivers/tty/vt/vt.c:1257
IMHO the easiest way to prevent this crash is to simply clear the
selection before the various con_font_set() console handlers are called.
Otherwise every console driver needs to add checks and verify if the current
selection still fits with the selected font, which gets tricky because some
of those drivers fiddle with the screen width&height before calling vc_do_resize().
I'll follow up to this mail with patches for both issues shortly.
I tested the patches. The crash no longer occurs with the reproducer.
Thanks for testing!
Maybe you want to reply to the patches with a Tested-by: tag?
Below is my debug code.
Helge
@@ -3194,6 +3194,8 @@ int tioclinux(struct tty_struct *tty, unsigned long arg)return-EFAULT;ret=0;+printk("tioclinux: type = %d\n",type);// TIOCL_SETSEL+switch(type){caseTIOCL_SETSEL:
How did you find out the selection values? From strace and man pages I know
the third argument is an address.
Right. It's a pointer into userspace.
I simply added printk debug code to see what's happening.
I've attached that patch below.
quoted
quoted
-> sets the text selection area
ioctl(4, KDFONTOP) with op=0 (con_font_set), charcount=512 width=8 height=32, 0x20000000) = 0
Same here, It would be very helpful if you could tell me how.
See patch below.
quoted
quoted
-> changes the font size.
It does not crash with current Linus' head (v5.19-rc8).
I tested in 5.19-rc8 in Qemu x86_64 and it crashed for me.
That's strange, since I tested the same. Maybe I did something wrong.
Anyway, the patches I sent applies to all kernel versions.
quoted
quoted
Kernel v5.16, which was used by this KASAN report, hasn't received backports
since months, so I tried stable kernel v5.15.58 instead, and this
kernel crashed with the reproducer.
The reproducer brings up two issues with current code:
1. The reproducer uses ioctl(TIOCLINUX, TIOCL_SETSEL) and hands over (invalid)
zero-values for ys and ye for the starting lines.
This is wrong, since the API seems to expect a "1" as the very first line for the selection.
This can be easily fixed by adding checks for zero-values and return -EINVAL if found.
But this bug isn't critical itself and is not the reason for the kernel crash.
Without the checks, the ioctl handler simply wraps the coordinate values and converts them
from:
input selection: xs:3 ys:0 xe:0 ye:0 mode:0 to the new:
vc_selection = xs:2 ys:23 xe:127 ye:23 mode:0
which is the current maximum coordinates for the screen.
Those higher values now trigger issue #2:
After the TIOCL_SETSEL the last line on the screen is now selected. The KDFONTOP ioctl
then sets a 8x32 console font, and replaces the former 8x16 console font.
With the bigger font the current screen selection is now outside the visible screen
and this finally triggeres this backtrace, because vc_do_resize() calls clear_selection()
to unhighlight the selection (which starts to render chars outside of the screen):
That makes sense.
quoted
drm_fb_helper_sys_imageblit drivers/gpu/drm/drm_fb_helper.c:794 [inline]
drm_fbdev_fb_imageblit+0x15c/0x350 drivers/gpu/drm/drm_fb_helper.c:2288
bit_putcs_unaligned drivers/video/fbdev/core/bitblit.c:124 [inline]
bit_putcs+0x6e1/0xd20 drivers/video/fbdev/core/bitblit.c:173
fbcon_putcs+0x353/0x440 drivers/video/fbdev/core/fbcon.c:1277
do_update_region+0x399/0x630 drivers/tty/vt/vt.c:676
invert_screen+0x1d4/0x600 drivers/tty/vt/vt.c:800
highlight drivers/tty/vt/selection.c:57 [inline]
clear_selection drivers/tty/vt/selection.c:84 [inline]
clear_selection+0x55/0x70 drivers/tty/vt/selection.c:80
vc_do_resize+0xe6e/0x1180 drivers/tty/vt/vt.c:1257
IMHO the easiest way to prevent this crash is to simply clear the
selection before the various con_font_set() console handlers are called.
Otherwise every console driver needs to add checks and verify if the current
selection still fits with the selected font, which gets tricky because some
of those drivers fiddle with the screen width&height before calling vc_do_resize().
I'll follow up to this mail with patches for both issues shortly.
I tested the patches. The crash no longer occurs with the reproducer.
Thanks for testing!
Maybe you want to reply to the patches with a Tested-by: tag?
@@ -3194,6 +3194,8 @@ int tioclinux(struct tty_struct *tty, unsigned long arg)return-EFAULT;ret=0;+printk("tioclinux: type = %d\n",type);// TIOCL_SETSEL+switch(type){caseTIOCL_SETSEL:
When changing the console font with ioctl(KDFONTOP) the new font size
can be bigger than the previous font. A previous selection may thus now
be outside of the new screen size and thus trigger out-of-bounds
accesses to graphics memory if the selection is removed in
vc_do_resize().
Prevent such out-of-memory accesses by dropping the selection before the
various con_font_set() console handlers are called.
Signed-off-by: Helge Deller <deller@gmx.de>
The reproducer does this:
ioctl(3, TIOCLINUX, TIOCL_SETSEL, selection: xs:3 ys:0 xe:0 ye:0 mode:0) = 0
-> sets the text selection area
ioctl(4, KDFONTOP) with op=0 (con_font_set), charcount=512 width=8 height=32, 0x20000000) = 0
-> changes the font size.
It does not crash with current Linus' head (v5.19-rc8).
Kernel v5.16, which was used by this KASAN report, hasn't received backports
since months, so I tried stable kernel v5.15.58 instead, and this
kernel crashed with the reproducer.
The reproducer brings up two issues with current code:
1. The reproducer uses ioctl(TIOCLINUX, TIOCL_SETSEL) and hands over (invalid)
zero-values for ys and ye for the starting lines.
This is wrong, since the API seems to expect a "1" as the very first line for the selection.
Why do you think that API expects a 1?
This can be easily fixed by adding checks for zero-values and return -EINVAL if found.
But this bug isn't critical itself and is not the reason for the kernel crash.
Without the checks, the ioctl handler simply wraps the coordinate values and converts them
from:
input selection: xs:3 ys:0 xe:0 ye:0 mode:0 to the new:
vc_selection = xs:2 ys:23 xe:127 ye:23 mode:0
which is the current maximum coordinates for the screen.
Those higher values now trigger issue #2:
After the TIOCL_SETSEL the last line on the screen is now selected. The KDFONTOP ioctl
then sets a 8x32 console font, and replaces the former 8x16 console font.
With the bigger font the current screen selection is now outside the visible screen
and this finally triggeres this backtrace, because vc_do_resize() calls clear_selection()
to unhighlight the selection (which starts to render chars outside of the screen):
drm_fb_helper_sys_imageblit drivers/gpu/drm/drm_fb_helper.c:794 [inline]
drm_fbdev_fb_imageblit+0x15c/0x350 drivers/gpu/drm/drm_fb_helper.c:2288
bit_putcs_unaligned drivers/video/fbdev/core/bitblit.c:124 [inline]
bit_putcs+0x6e1/0xd20 drivers/video/fbdev/core/bitblit.c:173
fbcon_putcs+0x353/0x440 drivers/video/fbdev/core/fbcon.c:1277
do_update_region+0x399/0x630 drivers/tty/vt/vt.c:676
invert_screen+0x1d4/0x600 drivers/tty/vt/vt.c:800
highlight drivers/tty/vt/selection.c:57 [inline]
clear_selection drivers/tty/vt/selection.c:84 [inline]
clear_selection+0x55/0x70 drivers/tty/vt/selection.c:80
vc_do_resize+0xe6e/0x1180 drivers/tty/vt/vt.c:1257
IMHO the easiest way to prevent this crash is to simply clear the
selection before the various con_font_set() console handlers are called.
Otherwise every console driver needs to add checks and verify if the current
selection still fits with the selected font, which gets tricky because some
of those drivers fiddle with the screen width&height before calling vc_do_resize().
I'll follow up to this mail with patches for both issues shortly.
Helge
The reproducer does this:
ioctl(3, TIOCLINUX, TIOCL_SETSEL, selection: xs:3 ys:0 xe:0 ye:0 mode:0) = 0
-> sets the text selection area
ioctl(4, KDFONTOP) with op=0 (con_font_set), charcount=512 width=8 height=32, 0x20000000) = 0
-> changes the font size.
It does not crash with current Linus' head (v5.19-rc8).
Kernel v5.16, which was used by this KASAN report, hasn't received backports
since months, so I tried stable kernel v5.15.58 instead, and this
kernel crashed with the reproducer.
The reproducer brings up two issues with current code:
1. The reproducer uses ioctl(TIOCLINUX, TIOCL_SETSEL) and hands over (invalid)
zero-values for ys and ye for the starting lines.
This is wrong, since the API seems to expect a "1" as the very first line for the selection.
Why do you think that API expects a 1?
because the code in drivers/tty/vt/selection.c indicates this:
See:
static int vc_selection(struct vc_data *vc, struct tiocl_selection *v, struct tty_struct *tty)
{
int ps, pe;
...
v->xs = min_t(u16, v->xs - 1, vc->vc_cols - 1);
v->ys = min_t(u16, v->ys - 1, vc->vc_rows - 1);
v->xe = min_t(u16, v->xe - 1, vc->vc_cols - 1);
v->ye = min_t(u16, v->ye - 1, vc->vc_rows - 1);
...
ps = v->ys * vc->vc_size_row + (v->xs << 1);
pe = v->ye * vc->vc_size_row + (v->xe << 1);
The userspace-provided xs,ys,xe and ye values are decremented by one
before ps and pe (the pointers into the text screen array) are calculated.
So, for the xs...ye values in the range from 1..max-screen-lines/columns
are expected.
Helge
The reproducer does this:
ioctl(3, TIOCLINUX, TIOCL_SETSEL, selection: xs:3 ys:0 xe:0 ye:0 mode:0) = 0
-> sets the text selection area
ioctl(4, KDFONTOP) with op=0 (con_font_set), charcount=512 width=8 height=32, 0x20000000) = 0
-> changes the font size.
It does not crash with current Linus' head (v5.19-rc8).
Kernel v5.16, which was used by this KASAN report, hasn't received backports
since months, so I tried stable kernel v5.15.58 instead, and this
kernel crashed with the reproducer.
The reproducer brings up two issues with current code:
1. The reproducer uses ioctl(TIOCLINUX, TIOCL_SETSEL) and hands over (invalid)
zero-values for ys and ye for the starting lines.
This is wrong, since the API seems to expect a "1" as the very first line for the selection.
Why do you think that API expects a 1?
because the code in drivers/tty/vt/selection.c indicates this:
See:
static int vc_selection(struct vc_data *vc, struct tiocl_selection *v, struct tty_struct *tty)
{
int ps, pe;
...
v->xs = min_t(u16, v->xs - 1, vc->vc_cols - 1);
v->ys = min_t(u16, v->ys - 1, vc->vc_rows - 1);
v->xe = min_t(u16, v->xe - 1, vc->vc_cols - 1);
v->ye = min_t(u16, v->ye - 1, vc->vc_rows - 1);
...
ps = v->ys * vc->vc_size_row + (v->xs << 1);
pe = v->ye * vc->vc_size_row + (v->xe << 1);
The userspace-provided xs,ys,xe and ye values are decremented by one
before ps and pe (the pointers into the text screen array) are calculated.
So, for the xs...ye values in the range from 1..max-screen-lines/columns
are expected.
Oh. I got it. It is pretty simple. Thanks again for explaining.
The line and column numbers for the selection need to start at 1.
Add the checks to prevent invalid input.
Signed-off-by: Helge Deller <deller@gmx.de>
Reported-by: syzbot+14b0e8f3fd1612e35350@syzkaller.appspotmail.com
Hello Jiri,
Thanks for looking into this patch!
On 8/4/22 07:47, Jiri Slaby wrote:
On 30. 07. 22, 20:49, Helge Deller wrote:
quoted
The line and column numbers for the selection need to start at 1.
Add the checks to prevent invalid input.
Signed-off-by: Helge Deller <deller@gmx.de>
Reported-by: syzbot+14b0e8f3fd1612e35350@syzkaller.appspotmail.com
Hmm, I'm not sure about this. It potentially breaks userspace (by
returning EINVAL now).
Right.
According to the code below, my interpretation is that all xs/ys/xe/ye values
should be > 0. But of course I might be wrong on this, as I didn't find any
documentation for TIOCL_SETSEL.
And if userspace tries to set an invalid selection (e.g. by selecting row 0),
my patch now returns -EINVAL, while it returned success before.
And the code below should handle this just fine, right:
It "handles it fine" in the sense that it can cope with the
input and will not crash.
But it returns (maybe?) unexpected results...
For example, if a user selects row 0 (where I assume he wanted to set
the first line), he instead selects the last row.
I'm not sure if this is the expected behaviour.
Do you know of any userspace program which breaks because of this?
Helge
Hello Jiri,
Thanks for looking into this patch!
On 8/4/22 07:47, Jiri Slaby wrote:
quoted
On 30. 07. 22, 20:49, Helge Deller wrote:
quoted
The line and column numbers for the selection need to start at 1.
Add the checks to prevent invalid input.
Signed-off-by: Helge Deller <deller@gmx.de>
Reported-by: syzbot+14b0e8f3fd1612e35350@syzkaller.appspotmail.com
Hmm, I'm not sure about this. It potentially breaks userspace (by
returning EINVAL now).
Right.
According to the code below, my interpretation is that all xs/ys/xe/ye values
should be > 0. But of course I might be wrong on this, as I didn't find any
documentation for TIOCL_SETSEL.
And if userspace tries to set an invalid selection (e.g. by selecting row 0),
my patch now returns -EINVAL, while it returned success before.
quoted
And the code below should handle this just fine, right:
It "handles it fine" in the sense that it can cope with the
input and will not crash.
But it returns (maybe?) unexpected results...
After some more thinking maybe you are right.
In case a user provided invalid values in the past, simply an unexpected
selection was set, but nothing broke.
Since the patch doesn't fix any critical issue, we could just drop this patch
and leave it as is.
Helge
Hello Jiri,
Thanks for looking into this patch!
On 8/4/22 07:47, Jiri Slaby wrote:
quoted
On 30. 07. 22, 20:49, Helge Deller wrote:
quoted
The line and column numbers for the selection need to start at 1.
Add the checks to prevent invalid input.
Signed-off-by: Helge Deller <deller@gmx.de>
Reported-by: syzbot+14b0e8f3fd1612e35350@syzkaller.appspotmail.com
Hmm, I'm not sure about this. It potentially breaks userspace (by
returning EINVAL now).
Right.
According to the code below, my interpretation is that all xs/ys/xe/ye values
should be > 0. But of course I might be wrong on this, as I didn't find any
documentation for TIOCL_SETSEL.
And if userspace tries to set an invalid selection (e.g. by selecting row 0),
my patch now returns -EINVAL, while it returned success before.
quoted
And the code below should handle this just fine, right:
It "handles it fine" in the sense that it can cope with the
input and will not crash.
But it returns (maybe?) unexpected results...
After some more thinking maybe you are right.
In case a user provided invalid values in the past, simply an unexpected
selection was set, but nothing broke.
Since the patch doesn't fix any critical issue, we could just drop this patch
and leave it as is.
We can still do a trial and revert it if something breaks... It's just
that _noone_ knows with all this undocumented stuff ;).
But in fact, 0 currently means full row/column. Isn't it on purpose?
Today, we are out of luck, codesearch.debian.net gives no clue about users:
https://codesearch.debian.net/search?q=%5CbTIOCL_SETSEL%5Cb&literal=0
thanks,
--
js
suse labs
Hmm, I'm not sure about this. It potentially breaks userspace (by
returning EINVAL now).
We can still do a trial and revert it if something breaks... It's just that
_noone_ knows with all this undocumented stuff ;).
But in fact, 0 currently means full row/column. Isn't it on purpose?
Today, we are out of luck, codesearch.debian.net gives no clue about users:
https://codesearch.debian.net/search?q=%5CbTIOCL_SETSEL%5Cb&literal=0
That's because the macro is undocumented.
"man ioctl_console" says:
TIOCLINUX, subcode=2
Set selection. argp points to a [...]
thus everyone writes it as a number.
You'd need to grep for TIOCLINUX; there's not that many references to
check...
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Say what you want about Adolf, at least he was the man who
⢿⡄⠘⠷⠚⠋⠀ killed Hitler. Your turn, Vlad!
⠈⠳⣄⠀⠀⠀⠀