LinuxLists.cc - A divide error bug in snd_pcm

2022-09-26 09:45:07

Subject: A divide error bug in snd_pcm_write

Hi, there is a divide error bug in snd_pcm_write in
sound/core/pcm_native.c in the latest kernel.

##Root Cause
When open the device of /dev/snd/pcmC#D#p, there would attach a
runtime to pcm->substream via snd_pcm_open_substream. see the code
below:
```
int snd_pcm_attach_substream(struct snd_pcm *pcm, int stream,
struct file *file,
struct snd_pcm_substream **rsubstream)
{
......

runtime = kzalloc(sizeof(*runtime), GFP_KERNEL);
if (runtime == NULL)
return -ENOMEM;

size = PAGE_ALIGN(sizeof(struct snd_pcm_mmap_status));
runtime->status = alloc_pages_exact(size, GFP_KERNEL);
if (runtime->status == NULL) {
kfree(runtime);
return -ENOMEM;
}
memset(runtime->status, 0, size);

size = PAGE_ALIGN(sizeof(struct snd_pcm_mmap_control));
runtime->control = alloc_pages_exact(size, GFP_KERNEL);
if (runtime->control == NULL) {
free_pages_exact(runtime->status,
PAGE_ALIGN(sizeof(struct snd_pcm_mmap_status)));
kfree(runtime);
return -ENOMEM;
}
memset(runtime->control, 0, size);

init_waitqueue_head(&runtime->sleep);
init_waitqueue_head(&runtime->tsleep);

runtime->status->state = SNDRV_PCM_STATE_OPEN;
mutex_init(&runtime->buffer_mutex);
atomic_set(&runtime->buffer_accessing, 0);

substream->runtime = runtime;
substream->private_data = pcm->private_data;
substream->ref_count = 1;
substream->f_flags = file->f_flags;
substream->pid = get_pid(task_pid(current));
pstr->substream_opened++;
*rsubstream = substream;
return 0;
}
```
It would kzmalloc a new runtime. And initialize runtime simply.
If we write some data to the device. it would call snd_pcm_write or
snd_pcm_writev. and read some date from the device, it would call
snd_pcm_read or snd_pcm_readv.
Anyway, the four function would use data of runtime, but some data of
runtime is NULL not be initialized, see the code below:
```
static ssize_t snd_pcm_write(struct file *file, const char __user *buf,
size_t count, loff_t * offset)
{
struct snd_pcm_file *pcm_file;
struct snd_pcm_substream *substream;
struct snd_pcm_runtime *runtime;
snd_pcm_sframes_t result;

pcm_file = file->private_data;
substream = pcm_file->substream;
if (PCM_RUNTIME_CHECK(substream))
return -ENXIO;
runtime = substream->runtime;
if (runtime->status->state == SNDRV_PCM_STATE_OPEN ||
runtime->status->state == SNDRV_PCM_STATE_DISCONNECTED)
return -EBADFD;
if (!frame_aligned(runtime, count)) /////// [1]
return -EINVAL;
count = bytes_to_frames(runtime, count); /////// [2]
result = snd_pcm_lib_write(substream, buf, count);
if (result > 0)
result = frames_to_bytes(runtime, result);
return result;
}
```
[1] call frame_aligned to aligned.
```
static inline int frame_aligned(struct snd_pcm_runtime *runtime, ssize_t bytes)
{
return bytes % runtime->byte_align == 0;
}
```
but runtime->byte_align is NULL.

[2] call bytes_to_frames.
```
static inline ssize_t frames_to_bytes(struct snd_pcm_runtime *runtime,
snd_pcm_sframes_t size)
{
return size * runtime->frame_bits / 8;
}
```
but runtime->frame_bits is NULL.

##reproduce it
[ 1189.305083][ T4656] divide error: 0000 [#1] PREEMPT SMP
[ 1189.305600][ T4656] CPU: 1 PID: 4656 Comm: snd_pcm_write Not
tainted 6.0.0-rc7 #16
[ 1189.306157][ T4656] Hardware name: QEMU Standard PC (i440FX + PIIX,
1996), BIOS 1.13.0-1ubuntu1 04/01/2014
[ 1189.306760][ T4656] RIP: 0010:snd_pcm_write+0x33/0xa0
[ 1189.307155][ T4656] Code: 8b 38 48 85 ff 74 72 48 8b 9f c0 00 00 00
48 85 db 74 66 48 8b 83 00 01 00 00 f7 00 f7 ff ff ff 74 6b 48 89 d0
48 89 d1 31 d2 <48> f7 b3 91
[ 1189.308553][ T4656] RSP: 0018:ffffc9000adc7e68 EFLAGS: 00010246
[ 1189.309034][ T4656] RAX: 0000000000000000 RBX: ffff888048ec2000
RCX: 0000000000000000
[ 1189.309583][ T4656] RDX: 0000000000000000 RSI: 0000000000000000
RDI: ffff888046fc9c00
[ 1189.310163][ T4656] RBP: 0000000000000000 R08: 0000000000000000
R09: 0000000000020026
[ 1189.310679][ T4656] R10: 0000000000000001 R11: 0000000000000000
R12: 0000000000000000
[ 1189.311226][ T4656] R13: ffffc9000adc7f08 R14: 0000000000000000
R15: 0000000000000000
[ 1189.311754][ T4656] FS: 00000000012d8880(0000)
GS:ffff88807ec00000(0000) knlGS:0000000000000000
[ 1189.312350][ T4656] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1189.312780][ T4656] CR2: 0000000020000000 CR3: 000000004b496000
CR4: 00000000000006e0
[ 1189.313234][ T4656] Call Trace:
[ 1189.313424][ T4656] <TASK>
[ 1189.313597][ T4656] vfs_write+0xe6/0x4d0
[ 1189.313836][ T4656] ksys_write+0x60/0xe0
[ 1189.314071][ T4656] do_syscall_64+0x35/0xb0
[ 1189.314324][ T4656] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 1189.314734][ T4656] RIP: 0033:0x44dc3d
[ 1189.315007][ T4656] Code: 28 c3 e8 36 29 00 00 66 0f 1f 44 00 00 f3
0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b
4c 24 08 0f 05 <48> 3d 01 f8
[ 1189.316338][ T4656] RSP: 002b:00007ffcbdf5ef38 EFLAGS: 00000246
ORIG_RAX: 0000000000000001
[ 1189.317012][ T4656] RAX: ffffffffffffffda RBX: 0000000000400530
RCX: 000000000044dc3d
[ 1189.317693][ T4656] RDX: 0000000000000000 RSI: 0000000000000000
RDI: 0000000000000003
[ 1189.318172][ T4656] RBP: 00007ffcbdf5ef50 R08: 0000000082000000
R09: 0000000000000000
[ 1189.318648][ T4656] R10: 000000000000ffff R11: 0000000000000246
R12: 00000000004030a0
[ 1189.319182][ T4656] R13: 0000000000000000 R14: 00000000004c5018
R15: 0000000000000000

Regrads,
butt3rflyh4ck.

--
Active Defense Lab of Venustech

2022-09-26 11:25:11

by Takashi Iwai

[permalink] [raw]

Subject: Re: A divide error bug in snd_pcm_write

On Mon, 26 Sep 2022 11:26:17 +0200,
butt3rflyh4ck wrote:
>
> Hi, there is a divide error bug in snd_pcm_write in
> sound/core/pcm_native.c in the latest kernel.
>
> ##Root Cause
> When open the device of /dev/snd/pcmC#D#p, there would attach a
> runtime to pcm->substream via snd_pcm_open_substream. see the code
> below:
> ```
> int snd_pcm_attach_substream(struct snd_pcm *pcm, int stream,
> struct file *file,
> struct snd_pcm_substream **rsubstream)
> {
> ......
>
> runtime = kzalloc(sizeof(*runtime), GFP_KERNEL);
> if (runtime == NULL)
> return -ENOMEM;
>
> size = PAGE_ALIGN(sizeof(struct snd_pcm_mmap_status));
> runtime->status = alloc_pages_exact(size, GFP_KERNEL);
> if (runtime->status == NULL) {
> kfree(runtime);
> return -ENOMEM;
> }
> memset(runtime->status, 0, size);
>
> size = PAGE_ALIGN(sizeof(struct snd_pcm_mmap_control));
> runtime->control = alloc_pages_exact(size, GFP_KERNEL);
> if (runtime->control == NULL) {
> free_pages_exact(runtime->status,
> PAGE_ALIGN(sizeof(struct snd_pcm_mmap_status)));
> kfree(runtime);
> return -ENOMEM;
> }
> memset(runtime->control, 0, size);
>
> init_waitqueue_head(&runtime->sleep);
> init_waitqueue_head(&runtime->tsleep);
>
> runtime->status->state = SNDRV_PCM_STATE_OPEN;
> mutex_init(&runtime->buffer_mutex);
> atomic_set(&runtime->buffer_accessing, 0);
>
> substream->runtime = runtime;
> substream->private_data = pcm->private_data;
> substream->ref_count = 1;
> substream->f_flags = file->f_flags;
> substream->pid = get_pid(task_pid(current));
> pstr->substream_opened++;
> *rsubstream = substream;
> return 0;
> }
> ```
> It would kzmalloc a new runtime. And initialize runtime simply.
> If we write some data to the device. it would call snd_pcm_write or
> snd_pcm_writev. and read some date from the device, it would call
> snd_pcm_read or snd_pcm_readv.
> Anyway, the four function would use data of runtime, but some data of
> runtime is NULL not be initialized, see the code below:
> ```
> static ssize_t snd_pcm_write(struct file *file, const char __user *buf,
> size_t count, loff_t * offset)
> {
> struct snd_pcm_file *pcm_file;
> struct snd_pcm_substream *substream;
> struct snd_pcm_runtime *runtime;
> snd_pcm_sframes_t result;
>
> pcm_file = file->private_data;
> substream = pcm_file->substream;
> if (PCM_RUNTIME_CHECK(substream))
> return -ENXIO;
> runtime = substream->runtime;
> if (runtime->status->state == SNDRV_PCM_STATE_OPEN ||
> runtime->status->state == SNDRV_PCM_STATE_DISCONNECTED)
> return -EBADFD;
> if (!frame_aligned(runtime, count)) /////// [1]
> return -EINVAL;
> count = bytes_to_frames(runtime, count); /////// [2]
> result = snd_pcm_lib_write(substream, buf, count);
> if (result > 0)
> result = frames_to_bytes(runtime, result);
> return result;
> }
> ```
> [1] call frame_aligned to aligned.
> ```
> static inline int frame_aligned(struct snd_pcm_runtime *runtime, ssize_t bytes)
> {
> return bytes % runtime->byte_align == 0;
> }
> ```
> but runtime->byte_align is NULL.
>
> [2] call bytes_to_frames.
> ```
> static inline ssize_t frames_to_bytes(struct snd_pcm_runtime *runtime,
> snd_pcm_sframes_t size)
> {
> return size * runtime->frame_bits / 8;
> }
> ```
> but runtime->frame_bits is NULL.
>
> ##reproduce it
> [ 1189.305083][ T4656] divide error: 0000 [#1] PREEMPT SMP
> [ 1189.305600][ T4656] CPU: 1 PID: 4656 Comm: snd_pcm_write Not
> tainted 6.0.0-rc7 #16
> [ 1189.306157][ T4656] Hardware name: QEMU Standard PC (i440FX + PIIX,
> 1996), BIOS 1.13.0-1ubuntu1 04/01/2014
> [ 1189.306760][ T4656] RIP: 0010:snd_pcm_write+0x33/0xa0
> [ 1189.307155][ T4656] Code: 8b 38 48 85 ff 74 72 48 8b 9f c0 00 00 00
> 48 85 db 74 66 48 8b 83 00 01 00 00 f7 00 f7 ff ff ff 74 6b 48 89 d0
> 48 89 d1 31 d2 <48> f7 b3 91
> [ 1189.308553][ T4656] RSP: 0018:ffffc9000adc7e68 EFLAGS: 00010246
> [ 1189.309034][ T4656] RAX: 0000000000000000 RBX: ffff888048ec2000
> RCX: 0000000000000000
> [ 1189.309583][ T4656] RDX: 0000000000000000 RSI: 0000000000000000
> RDI: ffff888046fc9c00
> [ 1189.310163][ T4656] RBP: 0000000000000000 R08: 0000000000000000
> R09: 0000000000020026
> [ 1189.310679][ T4656] R10: 0000000000000001 R11: 0000000000000000
> R12: 0000000000000000
> [ 1189.311226][ T4656] R13: ffffc9000adc7f08 R14: 0000000000000000
> R15: 0000000000000000
> [ 1189.311754][ T4656] FS: 00000000012d8880(0000)
> GS:ffff88807ec00000(0000) knlGS:0000000000000000
> [ 1189.312350][ T4656] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 1189.312780][ T4656] CR2: 0000000020000000 CR3: 000000004b496000
> CR4: 00000000000006e0
> [ 1189.313234][ T4656] Call Trace:
> [ 1189.313424][ T4656] <TASK>
> [ 1189.313597][ T4656] vfs_write+0xe6/0x4d0
> [ 1189.313836][ T4656] ksys_write+0x60/0xe0
> [ 1189.314071][ T4656] do_syscall_64+0x35/0xb0
> [ 1189.314324][ T4656] entry_SYSCALL_64_after_hwframe+0x63/0xcd
> [ 1189.314734][ T4656] RIP: 0033:0x44dc3d
> [ 1189.315007][ T4656] Code: 28 c3 e8 36 29 00 00 66 0f 1f 44 00 00 f3
> 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b
> 4c 24 08 0f 05 <48> 3d 01 f8
> [ 1189.316338][ T4656] RSP: 002b:00007ffcbdf5ef38 EFLAGS: 00000246
> ORIG_RAX: 0000000000000001
> [ 1189.317012][ T4656] RAX: ffffffffffffffda RBX: 0000000000400530
> RCX: 000000000044dc3d
> [ 1189.317693][ T4656] RDX: 0000000000000000 RSI: 0000000000000000
> RDI: 0000000000000003
> [ 1189.318172][ T4656] RBP: 00007ffcbdf5ef50 R08: 0000000082000000
> R09: 0000000000000000
> [ 1189.318648][ T4656] R10: 000000000000ffff R11: 0000000000000246
> R12: 00000000004030a0
> [ 1189.319182][ T4656] R13: 0000000000000000 R14: 00000000004c5018
> R15: 0000000000000000

The question is how the code passes the check before [1]:

if (runtime->status->state == SNDRV_PCM_STATE_OPEN ||
runtime->status->state == SNDRV_PCM_STATE_DISCONNECTED)
return -EBADFD;

The uninitialized state should have been with SNDRV_PCM_STATE_OPEN,
and runtime->byte_align is set up at snd_pcm_hw_params() followed by
snd_pcm-set_state() to chage the state to SNDRV_PCM_STATE_SETUP.

Which kernel version are you testing?

Takashi

2022-09-26 18:21:58

by butt3rflyh4ck

[permalink] [raw]

Subject: Re: A divide error bug in snd_pcm_write

The latest kernel upstream.
Yes, but using mmap, you can map the runtime->status page, and then
copy the data through memcpy to overwrite the status->state data, or
even more, which is incredible.
this is debug log:
````
gef➤ c
Continuing.
Cannot remove breakpoints because program is no longer writable.
Further execution is probably impossible.

Thread 2 hit Hardware access (read/write) watchpoint 7: *0xffff88804c5cb000

Old value = 0x0
New value = 0x7665642f
0xffffffff828501a9 in snd_pcm_write (file=<optimized out>,
buf=0x20000000 "/dev/snd/pcmC#D#p", count=0x18,
offset=0xffffc9000a81bf08) at sound/core/pcm_native.c:3494
3494 if (runtime->status->state == SNDRV_PCM_STATE_OPEN ||

0xffffffff82850199 <snd_pcm_write+25> (bad) [rsi+riz*2+0x48]
0xffffffff8285019d <snd_pcm_write+29> mov eax, DWORD PTR [rbx+0x100]
0xffffffff828501a3 <snd_pcm_write+35> test DWORD PTR [rax], 0xfffffff7
→ 0xffffffff828501a9 <snd_pcm_write+41> je 0xffffffff82850216
<snd_pcm_write+150> NOT taken [Reason: !(Z)]
0xffffffff828501ab <snd_pcm_write+43> mov rax, rdx
0xffffffff828501ae <snd_pcm_write+46> mov rcx, rdx
0xffffffff828501b1 <snd_pcm_write+49> xor edx, edx
0xffffffff828501b3 <snd_pcm_write+51> div QWORD PTR [rbx+0x90]
0xffffffff828501ba <snd_pcm_write+58> test rdx, rdx
[!] Command 'context' failed to execute properly, reason: argument of
type 'NoneType' is not iterable
gef➤ p/x 0xffff88804c5cb000
$14 = 0xffff88804c5cb000
gef➤ x/10gx 0xffff88804c5cb000
0xffff88804c5cb000: 0x646e732f7665642f 0x234423436d63702f
0xffff88804c5cb010: 0x0000000000000070 0x0000000000000000
0xffff88804c5cb020: 0x0000000000000000 0x0000000000000000
0xffff88804c5cb030: 0x0000000000000000 0x0000000000000000
0xffff88804c5cb040: 0x0000000000000000 0x0000000000000000
gef➤ x/s 0xffff88804c5cb000
0xffff88804c5cb000: "/dev/snd/pcmC#D#p"
gef➤ p/x *(struct snd_pcm_mmap_status *)0xffff88804c5cb000
$15 = {
state = 0x7665642f,
pad1 = 0x646e732f,
__pad1 = 0xffff88804c5cb008,
hw_ptr = 0x234423436d63702f,
__pad2 = 0xffff88804c5cb010,
tstamp = {
tv_sec = 0x70,
tv_nsec = 0x0
},
suspended_state = 0x0,
pad3 = 0x0,
audio_tstamp = {
tv_sec = 0x0,
tv_nsec = 0x0
}
}
gef➤
````

Regards,
butt3rflyh4ck.

On Mon, Sep 26, 2022 at 6:21 PM Takashi Iwai <[email protected]> wrote:
>
> On Mon, 26 Sep 2022 11:26:17 +0200,
> butt3rflyh4ck wrote:
> >
> > Hi, there is a divide error bug in snd_pcm_write in
> > sound/core/pcm_native.c in the latest kernel.
> >
> > ##Root Cause
> > When open the device of /dev/snd/pcmC#D#p, there would attach a
> > runtime to pcm->substream via snd_pcm_open_substream. see the code
> > below:
> > ```
> > int snd_pcm_attach_substream(struct snd_pcm *pcm, int stream,
> > struct file *file,
> > struct snd_pcm_substream **rsubstream)
> > {
> > ......
> >
> > runtime = kzalloc(sizeof(*runtime), GFP_KERNEL);
> > if (runtime == NULL)
> > return -ENOMEM;
> >
> > size = PAGE_ALIGN(sizeof(struct snd_pcm_mmap_status));
> > runtime->status = alloc_pages_exact(size, GFP_KERNEL);
> > if (runtime->status == NULL) {
> > kfree(runtime);
> > return -ENOMEM;
> > }
> > memset(runtime->status, 0, size);
> >
> > size = PAGE_ALIGN(sizeof(struct snd_pcm_mmap_control));
> > runtime->control = alloc_pages_exact(size, GFP_KERNEL);
> > if (runtime->control == NULL) {
> > free_pages_exact(runtime->status,
> > PAGE_ALIGN(sizeof(struct snd_pcm_mmap_status)));
> > kfree(runtime);
> > return -ENOMEM;
> > }
> > memset(runtime->control, 0, size);
> >
> > init_waitqueue_head(&runtime->sleep);
> > init_waitqueue_head(&runtime->tsleep);
> >
> > runtime->status->state = SNDRV_PCM_STATE_OPEN;
> > mutex_init(&runtime->buffer_mutex);
> > atomic_set(&runtime->buffer_accessing, 0);
> >
> > substream->runtime = runtime;
> > substream->private_data = pcm->private_data;
> > substream->ref_count = 1;
> > substream->f_flags = file->f_flags;
> > substream->pid = get_pid(task_pid(current));
> > pstr->substream_opened++;
> > *rsubstream = substream;
> > return 0;
> > }
> > ```
> > It would kzmalloc a new runtime. And initialize runtime simply.
> > If we write some data to the device. it would call snd_pcm_write or
> > snd_pcm_writev. and read some date from the device, it would call
> > snd_pcm_read or snd_pcm_readv.
> > Anyway, the four function would use data of runtime, but some data of
> > runtime is NULL not be initialized, see the code below:
> > ```
> > static ssize_t snd_pcm_write(struct file *file, const char __user *buf,
> > size_t count, loff_t * offset)
> > {
> > struct snd_pcm_file *pcm_file;
> > struct snd_pcm_substream *substream;
> > struct snd_pcm_runtime *runtime;
> > snd_pcm_sframes_t result;
> >
> > pcm_file = file->private_data;
> > substream = pcm_file->substream;
> > if (PCM_RUNTIME_CHECK(substream))
> > return -ENXIO;
> > runtime = substream->runtime;
> > if (runtime->status->state == SNDRV_PCM_STATE_OPEN ||
> > runtime->status->state == SNDRV_PCM_STATE_DISCONNECTED)
> > return -EBADFD;
> > if (!frame_aligned(runtime, count)) /////// [1]
> > return -EINVAL;
> > count = bytes_to_frames(runtime, count); /////// [2]
> > result = snd_pcm_lib_write(substream, buf, count);
> > if (result > 0)
> > result = frames_to_bytes(runtime, result);
> > return result;
> > }
> > ```
> > [1] call frame_aligned to aligned.
> > ```
> > static inline int frame_aligned(struct snd_pcm_runtime *runtime, ssize_t bytes)
> > {
> > return bytes % runtime->byte_align == 0;
> > }
> > ```
> > but runtime->byte_align is NULL.
> >
> > [2] call bytes_to_frames.
> > ```
> > static inline ssize_t frames_to_bytes(struct snd_pcm_runtime *runtime,
> > snd_pcm_sframes_t size)
> > {
> > return size * runtime->frame_bits / 8;
> > }
> > ```
> > but runtime->frame_bits is NULL.
> >
> > ##reproduce it
> > [ 1189.305083][ T4656] divide error: 0000 [#1] PREEMPT SMP
> > [ 1189.305600][ T4656] CPU: 1 PID: 4656 Comm: snd_pcm_write Not
> > tainted 6.0.0-rc7 #16
> > [ 1189.306157][ T4656] Hardware name: QEMU Standard PC (i440FX + PIIX,
> > 1996), BIOS 1.13.0-1ubuntu1 04/01/2014
> > [ 1189.306760][ T4656] RIP: 0010:snd_pcm_write+0x33/0xa0
> > [ 1189.307155][ T4656] Code: 8b 38 48 85 ff 74 72 48 8b 9f c0 00 00 00
> > 48 85 db 74 66 48 8b 83 00 01 00 00 f7 00 f7 ff ff ff 74 6b 48 89 d0
> > 48 89 d1 31 d2 <48> f7 b3 91
> > [ 1189.308553][ T4656] RSP: 0018:ffffc9000adc7e68 EFLAGS: 00010246
> > [ 1189.309034][ T4656] RAX: 0000000000000000 RBX: ffff888048ec2000
> > RCX: 0000000000000000
> > [ 1189.309583][ T4656] RDX: 0000000000000000 RSI: 0000000000000000
> > RDI: ffff888046fc9c00
> > [ 1189.310163][ T4656] RBP: 0000000000000000 R08: 0000000000000000
> > R09: 0000000000020026
> > [ 1189.310679][ T4656] R10: 0000000000000001 R11: 0000000000000000
> > R12: 0000000000000000
> > [ 1189.311226][ T4656] R13: ffffc9000adc7f08 R14: 0000000000000000
> > R15: 0000000000000000
> > [ 1189.311754][ T4656] FS: 00000000012d8880(0000)
> > GS:ffff88807ec00000(0000) knlGS:0000000000000000
> > [ 1189.312350][ T4656] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [ 1189.312780][ T4656] CR2: 0000000020000000 CR3: 000000004b496000
> > CR4: 00000000000006e0
> > [ 1189.313234][ T4656] Call Trace:
> > [ 1189.313424][ T4656] <TASK>
> > [ 1189.313597][ T4656] vfs_write+0xe6/0x4d0
> > [ 1189.313836][ T4656] ksys_write+0x60/0xe0
> > [ 1189.314071][ T4656] do_syscall_64+0x35/0xb0
> > [ 1189.314324][ T4656] entry_SYSCALL_64_after_hwframe+0x63/0xcd
> > [ 1189.314734][ T4656] RIP: 0033:0x44dc3d
> > [ 1189.315007][ T4656] Code: 28 c3 e8 36 29 00 00 66 0f 1f 44 00 00 f3
> > 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b
> > 4c 24 08 0f 05 <48> 3d 01 f8
> > [ 1189.316338][ T4656] RSP: 002b:00007ffcbdf5ef38 EFLAGS: 00000246
> > ORIG_RAX: 0000000000000001
> > [ 1189.317012][ T4656] RAX: ffffffffffffffda RBX: 0000000000400530
> > RCX: 000000000044dc3d
> > [ 1189.317693][ T4656] RDX: 0000000000000000 RSI: 0000000000000000
> > RDI: 0000000000000003
> > [ 1189.318172][ T4656] RBP: 00007ffcbdf5ef50 R08: 0000000082000000
> > R09: 0000000000000000
> > [ 1189.318648][ T4656] R10: 000000000000ffff R11: 0000000000000246
> > R12: 00000000004030a0
> > [ 1189.319182][ T4656] R13: 0000000000000000 R14: 00000000004c5018
> > R15: 0000000000000000
>
> The question is how the code passes the check before [1]:
>
> if (runtime->status->state == SNDRV_PCM_STATE_OPEN ||
> runtime->status->state == SNDRV_PCM_STATE_DISCONNECTED)
> return -EBADFD;
>
> The uninitialized state should have been with SNDRV_PCM_STATE_OPEN,
> and runtime->byte_align is set up at snd_pcm_hw_params() followed by
> snd_pcm-set_state() to chage the state to SNDRV_PCM_STATE_SETUP.
>
> Which kernel version are you testing?
>
>
> Takashi

--
Active Defense Lab of Venustech

2022-09-26 19:00:51

by Takashi Iwai

[permalink] [raw]

Subject: Re: A divide error bug in snd_pcm_write

On Mon, 26 Sep 2022 19:16:48 +0200,
butt3rflyh4ck wrote:
>
> The latest kernel upstream.
> Yes, but using mmap, you can map the runtime->status page, and then
> copy the data through memcpy to overwrite the status->state data, or
> even more, which is incredible.

Ah, then that's exactly the case my latest patch set covers.
Either the first patch or the second patch alone should work.
https://lore.kernel.org/r/[email protected]
https://lore.kernel.org/r/[email protected]

Could you verify either of them fixes the problem?

thanks,

Takashi

2022-09-29 15:59:40

by butt3rflyh4ck

[permalink] [raw]

Subject: Re: A divide error bug in snd_pcm_write

This one fixes the problem.
https://lore.kernel.org/all/[email protected]/

Regards,
butt3rflyh4ck.

On Tue, Sep 27, 2022 at 2:01 AM Takashi Iwai <[email protected]> wrote:
>
> On Mon, 26 Sep 2022 19:16:48 +0200,
> butt3rflyh4ck wrote:
> >
> > The latest kernel upstream.
> > Yes, but using mmap, you can map the runtime->status page, and then
> > copy the data through memcpy to overwrite the status->state data, or
> > even more, which is incredible.
>
> Ah, then that's exactly the case my latest patch set covers.
> Either the first patch or the second patch alone should work.
> https://lore.kernel.org/r/[email protected]
> https://lore.kernel.org/r/[email protected]
>
> Could you verify either of them fixes the problem?
>
>
> thanks,
>
> Takashi

--
Active Defense Lab of Venustech

2022-09-29 16:17:11

by Takashi Iwai

[permalink] [raw]

Subject: Re: A divide error bug in snd_pcm_write

On Thu, 29 Sep 2022 16:52:10 +0200,
butt3rflyh4ck wrote:
>
> This one fixes the problem.
> https://lore.kernel.org/all/[email protected]/

Thanks for confirmation! The fix should be included in 6.1-rc1.

Takashi

>
> Regards,
> butt3rflyh4ck.
>
> On Tue, Sep 27, 2022 at 2:01 AM Takashi Iwai <[email protected]> wrote:
> >
> > On Mon, 26 Sep 2022 19:16:48 +0200,
> > butt3rflyh4ck wrote:
> > >
> > > The latest kernel upstream.
> > > Yes, but using mmap, you can map the runtime->status page, and then
> > > copy the data through memcpy to overwrite the status->state data, or
> > > even more, which is incredible.
> >
> > Ah, then that's exactly the case my latest patch set covers.
> > Either the first patch or the second patch alone should work.
> > https://lore.kernel.org/r/[email protected]
> > https://lore.kernel.org/r/[email protected]
> >
> > Could you verify either of them fixes the problem?
> >
> >
> > thanks,
> >
> > Takashi
>
>
>
> --
> Active Defense Lab of Venustech
>