[PATCH v2] ASoC: SOF: ipc-msg-injector: fix copy in sof_msg_inject_ipc4_dfs_write()
There are two bugs that have to do with when we copy the payload:
size = simple_write_to_buffer(ipc4_msg->data_ptr, priv->max_msg_size, ppos, buffer, count);
The value of "*ppos" was supposed to be zero but it is sizeof(ipc4_msg->header_u64) so it will copy the data into the middle of the "ipc4_msg->data_ptr" buffer instead of to the start. The second problem is "buffer" should be "buffer + sizeof(ipc4_msg->header_u64)".
This function is used for fuzz testing so the data is normally random and this bug likely does not affect anyone very much.
In this context, it's simpler and more appropriate to use copy_from_user() instead of simple_write_to_buffer() so I have re-written the function.
Fixes: 066c67624d8c ("ASoC: SOF: ipc-msg-injector: Add support for IPC4 messages") Signed-off-by: Dan Carpenter dan.carpenter@oracle.com --- v2: In v1 I missed the "buffer + sizeof(ipc4_msg->header_u64)" bug.
sound/soc/sof/sof-client-ipc-msg-injector.c | 29 +++++++++------------ 1 file changed, 12 insertions(+), 17 deletions(-)
diff --git a/sound/soc/sof/sof-client-ipc-msg-injector.c b/sound/soc/sof/sof-client-ipc-msg-injector.c index 6bdfa527b7f7..752d5320680f 100644 --- a/sound/soc/sof/sof-client-ipc-msg-injector.c +++ b/sound/soc/sof/sof-client-ipc-msg-injector.c @@ -181,7 +181,7 @@ static ssize_t sof_msg_inject_ipc4_dfs_write(struct file *file, struct sof_client_dev *cdev = file->private_data; struct sof_msg_inject_priv *priv = cdev->data; struct sof_ipc4_msg *ipc4_msg = priv->tx_buffer; - ssize_t size; + size_t data_size; int ret;
if (*ppos) @@ -191,25 +191,20 @@ static ssize_t sof_msg_inject_ipc4_dfs_write(struct file *file, return -EINVAL;
/* copy the header first */ - size = simple_write_to_buffer(&ipc4_msg->header_u64, - sizeof(ipc4_msg->header_u64), - ppos, buffer, count); - if (size < 0) - return size; - if (size != sizeof(ipc4_msg->header_u64)) + if (copy_from_user(&ipc4_msg->header_u64, buffer, + sizeof(ipc4_msg->header_u64))) return -EFAULT;
- count -= size; + data_size = count - sizeof(ipc4_msg->header_u64); + if (data_size > priv->max_msg_size) + return -EINVAL; + /* Copy the payload */ - size = simple_write_to_buffer(ipc4_msg->data_ptr, - priv->max_msg_size, ppos, buffer, - count); - if (size < 0) - return size; - if (size != count) + if (copy_from_user(ipc4_msg->data_ptr, + buffer + sizeof(ipc4_msg->header_u64), data_size)) return -EFAULT;
- ipc4_msg->data_size = count; + ipc4_msg->data_size = data_size;
/* Initialize the reply storage */ ipc4_msg = priv->rx_buffer; @@ -221,9 +216,9 @@ static ssize_t sof_msg_inject_ipc4_dfs_write(struct file *file,
/* return the error code if test failed */ if (ret < 0) - size = ret; + return ret;
- return size; + return count; };
static int sof_msg_inject_dfs_release(struct inode *inode, struct file *file)
On Fri, 8 Jul 2022 16:48:36 +0300, Dan Carpenter wrote:
There are two bugs that have to do with when we copy the payload:
size = simple_write_to_buffer(ipc4_msg->data_ptr, priv->max_msg_size, ppos, buffer, count);
The value of "*ppos" was supposed to be zero but it is sizeof(ipc4_msg->header_u64) so it will copy the data into the middle of the "ipc4_msg->data_ptr" buffer instead of to the start. The second problem is "buffer" should be "buffer + sizeof(ipc4_msg->header_u64)".
[...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: SOF: ipc-msg-injector: fix copy in sof_msg_inject_ipc4_dfs_write() commit: fa9b878ff86f4adccddf62492a5894fbdb04f97d
All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying to this mail.
Thanks, Mark
participants (2)
-
Dan Carpenter
-
Mark Brown