sys/linux/dev_snd_control: support using existing kctls

[necipfazil]

Drivers can register hundreds of potentially interesting custom controls, which cannot be captured with the existing small range of numids (0:10).

Add a pseudo-syscall (syz_sndrv_get_elem_id()) to retrieve existing control numids.

Also make the argument of WR IOCTLs inout instead of in.

---

Before sending a pull request, please review Contribution Guidelines:
https://github.com/google/syzkaller/blob/master/docs/contributing.md

---

[a-nogikh]

Please address CI test failures.

A couple of questions:

1. Does it work much better this way in practice than if you replace numid int32[0:10] with e.g. numid int32[0:200] or just numid int32?
   
   Because e.g. to reference the element 123 you anyway need the fuzzer to auto-guess 123 (to be exact, some x=123+N*j, so that x%N==123), even though it be an argument to syz_sndrv_get_elem_id instead. Does the boost you get during fuzzing make it worth the complication? Is it much worse if you let the fuzzer generate numid directly?

2. Does the number of elements returned by SNDRV_CTL_IOCTL_ELEM_LIST change dynamically or is it fixed per machine/kernel?

[necipfazil]

Please address CI test failures.

A couple of questions:

1. Does it work much better this way in practice than if you replace numid int32[0:10] with e.g. numid int32[0:200] or just numid int32?

I did not test these alternatives.

Because e.g. to reference the element 123 you anyway need the fuzzer to auto-guess 123 (to be exact, some x=123+N*j, so that x%N==123), even though it be an argument to syz_sndrv_get_elem_id instead. Does the boost you get during fuzzing make it worth the complication? Is it much worse if you let the fuzzer generate numid directly?

I can't think of a specific case where using these alternatives would make things much worse. I am not sure about a good upper limit: just using int32 might be a good idea.

2. Does the number of elements returned by SNDRV_CTL_IOCTL_ELEM_LIST change dynamically or is it fixed per machine/kernel?

It can change dynamically with SNDRV_CTL_IOCTL_ELEM_ADD/SNDRV_CTL_IOCTL_ELEM_REMOVE ioctls. Also, the initial number of controls depend on what the driver might register. I have seen examples with 100 to 2000 controls, and not sure if there an upper limit to it.

Due to add/remove ioctls, the current implementation from this PR is wrong: removing elements breaks the "sequential numids" assumption I made while implementing the pseudo-syscall.

I can see a couple alternatives:

1. Use numid int32[0:200]/numid int32, trust the fuzzer to hit the valid ids given enough time
2. Keep using the pseudo-syscall, fix the implementation. For this, I will get rid of the assumption that numids are in [1,count] range, and instead do another SNDRV_CTL_IOCTL_ELEM_LIST ioctl with offset=random(1,count) to find a random valid element.

@a-nogikh what do you think?

[a-nogikh]

I'd go with the simpler alternative first -- let's just use a wider numid range and trust the fuzzer. It has to guess the number anyway, in both approaches.