In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to pcim_iomap_regions() is placed on the stack. Neither pcim_iomap_regions() nor the functions it calls copy that string.
Should the string later ever be used, this, consequently, causes undefined behavior since the stack frame will by then have disappeared.
Fix the bug by allocating the strings on the heap through devm_kasprintf().
Cc: stable@vger.kernel.org # v6.3 Fixes: 51a8f9d7f587 ("virtio: vdpa: new SolidNET DPU driver.") Reported-by: Christophe JAILLET christophe.jaillet@wanadoo.fr Closes: https://lore.kernel.org/all/74e9109a-ac59-49e2-9b1d-d825c9c9f891@wanadoo.fr/ Suggested-by: Andy Shevchenko andy@kernel.org Signed-off-by: Philipp Stanner pstanner@redhat.com --- drivers/vdpa/solidrun/snet_main.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/vdpa/solidrun/snet_main.c b/drivers/vdpa/solidrun/snet_main.c index 99428a04068d..c8b74980dbd1 100644 --- a/drivers/vdpa/solidrun/snet_main.c +++ b/drivers/vdpa/solidrun/snet_main.c @@ -555,7 +555,7 @@ static const struct vdpa_config_ops snet_config_ops = {
static int psnet_open_pf_bar(struct pci_dev *pdev, struct psnet *psnet) { - char name[50]; + char *name; int ret, i, mask = 0; /* We don't know which BAR will be used to communicate.. * We will map every bar with len > 0. @@ -573,7 +573,10 @@ static int psnet_open_pf_bar(struct pci_dev *pdev, struct psnet *psnet) return -ENODEV; }
- snprintf(name, sizeof(name), "psnet[%s]-bars", pci_name(pdev)); + name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "psnet[%s]-bars", pci_name(pdev)); + if (!name) + return -ENOMEM; + ret = pcim_iomap_regions(pdev, mask, name); if (ret) { SNET_ERR(pdev, "Failed to request and map PCI BARs\n"); @@ -590,10 +593,13 @@ static int psnet_open_pf_bar(struct pci_dev *pdev, struct psnet *psnet)
static int snet_open_vf_bar(struct pci_dev *pdev, struct snet *snet) { - char name[50]; + char *name; int ret;
- snprintf(name, sizeof(name), "snet[%s]-bar", pci_name(pdev)); + name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "snet[%s]-bars", pci_name(pdev)); + if (!name) + return -ENOMEM; + /* Request and map BAR */ ret = pcim_iomap_regions(pdev, BIT(snet->psnet->cfg.vf_bar), name); if (ret) {
On Thu, Aug 29, 2024 at 04:16:25PM +0200, Philipp Stanner wrote:
In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to pcim_iomap_regions() is placed on the stack. Neither pcim_iomap_regions() nor the functions it calls copy that string.
Should the string later ever be used, this, consequently, causes undefined behavior since the stack frame will by then have disappeared.
Fix the bug by allocating the strings on the heap through devm_kasprintf().
Cc: stable@vger.kernel.org # v6.3 Fixes: 51a8f9d7f587 ("virtio: vdpa: new SolidNET DPU driver.") Reported-by: Christophe JAILLET christophe.jaillet@wanadoo.fr Closes: https://lore.kernel.org/all/74e9109a-ac59-49e2-9b1d-d825c9c9f891@wanadoo.fr/ Suggested-by: Andy Shevchenko andy@kernel.org Signed-off-by: Philipp Stanner pstanner@redhat.com
Post this separately, so I can apply?
drivers/vdpa/solidrun/snet_main.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/vdpa/solidrun/snet_main.c b/drivers/vdpa/solidrun/snet_main.c index 99428a04068d..c8b74980dbd1 100644 --- a/drivers/vdpa/solidrun/snet_main.c +++ b/drivers/vdpa/solidrun/snet_main.c @@ -555,7 +555,7 @@ static const struct vdpa_config_ops snet_config_ops = { static int psnet_open_pf_bar(struct pci_dev *pdev, struct psnet *psnet) {
- char name[50];
- char *name; int ret, i, mask = 0; /* We don't know which BAR will be used to communicate..
- We will map every bar with len > 0.
@@ -573,7 +573,10 @@ static int psnet_open_pf_bar(struct pci_dev *pdev, struct psnet *psnet) return -ENODEV; }
- snprintf(name, sizeof(name), "psnet[%s]-bars", pci_name(pdev));
- name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "psnet[%s]-bars", pci_name(pdev));
- if (!name)
return -ENOMEM;- ret = pcim_iomap_regions(pdev, mask, name); if (ret) { SNET_ERR(pdev, "Failed to request and map PCI BARs\n");
@@ -590,10 +593,13 @@ static int psnet_open_pf_bar(struct pci_dev *pdev, struct psnet *psnet) static int snet_open_vf_bar(struct pci_dev *pdev, struct snet *snet) {
- char name[50];
- char *name; int ret;
- snprintf(name, sizeof(name), "snet[%s]-bar", pci_name(pdev));
- name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "snet[%s]-bars", pci_name(pdev));
- if (!name)
return -ENOMEM;- /* Request and map BAR */ ret = pcim_iomap_regions(pdev, BIT(snet->psnet->cfg.vf_bar), name); if (ret) {
-- 2.46.0
On Thu, Aug 29, 2024 at 5:23 PM Michael S. Tsirkin mst@redhat.com wrote:
On Thu, Aug 29, 2024 at 04:16:25PM +0200, Philipp Stanner wrote:
In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to pcim_iomap_regions() is placed on the stack. Neither pcim_iomap_regions() nor the functions it calls copy that string.
Should the string later ever be used, this, consequently, causes undefined behavior since the stack frame will by then have disappeared.
Fix the bug by allocating the strings on the heap through devm_kasprintf().
Cc: stable@vger.kernel.org # v6.3 Fixes: 51a8f9d7f587 ("virtio: vdpa: new SolidNET DPU driver.") Reported-by: Christophe JAILLET christophe.jaillet@wanadoo.fr Closes: https://lore.kernel.org/all/74e9109a-ac59-49e2-9b1d-d825c9c9f891@wanadoo.fr/ Suggested-by: Andy Shevchenko andy@kernel.org Signed-off-by: Philipp Stanner pstanner@redhat.com
Post this separately, so I can apply?
Don't you use `b4`? With it it as simple as
b4 am -P 6 $MSG_ID_OF_THIS_SERIES
On Thu, Aug 29, 2024 at 05:26:39PM +0300, Andy Shevchenko wrote:
On Thu, Aug 29, 2024 at 5:23 PM Michael S. Tsirkin mst@redhat.com wrote:
On Thu, Aug 29, 2024 at 04:16:25PM +0200, Philipp Stanner wrote:
In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to pcim_iomap_regions() is placed on the stack. Neither pcim_iomap_regions() nor the functions it calls copy that string.
Should the string later ever be used, this, consequently, causes undefined behavior since the stack frame will by then have disappeared.
Fix the bug by allocating the strings on the heap through devm_kasprintf().
Cc: stable@vger.kernel.org # v6.3 Fixes: 51a8f9d7f587 ("virtio: vdpa: new SolidNET DPU driver.") Reported-by: Christophe JAILLET christophe.jaillet@wanadoo.fr Closes: https://lore.kernel.org/all/74e9109a-ac59-49e2-9b1d-d825c9c9f891@wanadoo.fr/ Suggested-by: Andy Shevchenko andy@kernel.org Signed-off-by: Philipp Stanner pstanner@redhat.com
Post this separately, so I can apply?
Don't you use `b4`? With it it as simple as
b4 am -P 6 $MSG_ID_OF_THIS_SERIES
-- With Best Regards, Andy Shevchenko
I can do all kind of things, but if it's posted as part of a patchset, it is not clear to me this has been tested outside of the patchset.
On Thu, 2024-08-29 at 10:41 -0400, Michael S. Tsirkin wrote:
On Thu, Aug 29, 2024 at 05:26:39PM +0300, Andy Shevchenko wrote:
On Thu, Aug 29, 2024 at 5:23 PM Michael S. Tsirkin mst@redhat.com wrote:
On Thu, Aug 29, 2024 at 04:16:25PM +0200, Philipp Stanner wrote:
In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to pcim_iomap_regions() is placed on the stack. Neither pcim_iomap_regions() nor the functions it calls copy that string.
Should the string later ever be used, this, consequently, causes undefined behavior since the stack frame will by then have disappeared.
Fix the bug by allocating the strings on the heap through devm_kasprintf().
Cc: stable@vger.kernel.org # v6.3 Fixes: 51a8f9d7f587 ("virtio: vdpa: new SolidNET DPU driver.") Reported-by: Christophe JAILLET christophe.jaillet@wanadoo.fr Closes: https://lore.kernel.org/all/74e9109a-ac59-49e2-9b1d-d825c9c9f891@wanadoo.fr/ Suggested-by: Andy Shevchenko andy@kernel.org Signed-off-by: Philipp Stanner pstanner@redhat.com
Post this separately, so I can apply?
Don't you use `b4`? With it it as simple as
b4 am -P 6 $MSG_ID_OF_THIS_SERIES
-- With Best Regards, Andy Shevchenko
I can do all kind of things, but if it's posted as part of a patchset, it is not clear to me this has been tested outside of the patchset.
Separating it from the series would lead to merge conflicts, because patch 7 depends on it.
If you're responsible for vdpa in general I could send patches 6 and 7 separately to you.
But number 7 depends on number 1, because pcim_iounmap_region() needs to be public. So if patches 1-5 enter through a different tree than yours, that could be a problem.
P.
On Thu, Aug 29, 2024 at 04:49:50PM +0200, Philipp Stanner wrote:
On Thu, 2024-08-29 at 10:41 -0400, Michael S. Tsirkin wrote:
On Thu, Aug 29, 2024 at 05:26:39PM +0300, Andy Shevchenko wrote:
On Thu, Aug 29, 2024 at 5:23 PM Michael S. Tsirkin mst@redhat.com wrote:
On Thu, Aug 29, 2024 at 04:16:25PM +0200, Philipp Stanner wrote:
In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to pcim_iomap_regions() is placed on the stack. Neither pcim_iomap_regions() nor the functions it calls copy that string.
Should the string later ever be used, this, consequently, causes undefined behavior since the stack frame will by then have disappeared.
Fix the bug by allocating the strings on the heap through devm_kasprintf().
Cc: stable@vger.kernel.org # v6.3 Fixes: 51a8f9d7f587 ("virtio: vdpa: new SolidNET DPU driver.") Reported-by: Christophe JAILLET christophe.jaillet@wanadoo.fr Closes: https://lore.kernel.org/all/74e9109a-ac59-49e2-9b1d-d825c9c9f891@wanadoo.fr/ Suggested-by: Andy Shevchenko andy@kernel.org Signed-off-by: Philipp Stanner pstanner@redhat.com
Post this separately, so I can apply?
Don't you use `b4`? With it it as simple as
b4 am -P 6 $MSG_ID_OF_THIS_SERIES
-- With Best Regards, Andy Shevchenko
I can do all kind of things, but if it's posted as part of a patchset, it is not clear to me this has been tested outside of the patchset.
Separating it from the series would lead to merge conflicts, because patch 7 depends on it.
If you're responsible for vdpa in general I could send patches 6 and 7 separately to you.
But number 7 depends on number 1, because pcim_iounmap_region() needs to be public. So if patches 1-5 enter through a different tree than yours, that could be a problem.
P.
Defer 1/7 until after the merge window, this is what is normally done. Adding new warnings is not nice, anyway.
On Thu, 2024-08-29 at 11:10 -0400, Michael S. Tsirkin wrote:
On Thu, Aug 29, 2024 at 04:49:50PM +0200, Philipp Stanner wrote:
On Thu, 2024-08-29 at 10:41 -0400, Michael S. Tsirkin wrote:
On Thu, Aug 29, 2024 at 05:26:39PM +0300, Andy Shevchenko wrote:
On Thu, Aug 29, 2024 at 5:23 PM Michael S. Tsirkin mst@redhat.com wrote:
On Thu, Aug 29, 2024 at 04:16:25PM +0200, Philipp Stanner wrote:
In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to pcim_iomap_regions() is placed on the stack. Neither pcim_iomap_regions() nor the functions it calls copy that string.
Should the string later ever be used, this, consequently, causes undefined behavior since the stack frame will by then have disappeared.
Fix the bug by allocating the strings on the heap through devm_kasprintf().
Cc: stable@vger.kernel.org # v6.3 Fixes: 51a8f9d7f587 ("virtio: vdpa: new SolidNET DPU driver.") Reported-by: Christophe JAILLET christophe.jaillet@wanadoo.fr Closes: https://lore.kernel.org/all/74e9109a-ac59-49e2-9b1d-d825c9c9f891@wanadoo.fr/ Suggested-by: Andy Shevchenko andy@kernel.org Signed-off-by: Philipp Stanner pstanner@redhat.com
Post this separately, so I can apply?
Don't you use `b4`? With it it as simple as
b4 am -P 6 $MSG_ID_OF_THIS_SERIES
-- With Best Regards, Andy Shevchenko
I can do all kind of things, but if it's posted as part of a patchset, it is not clear to me this has been tested outside of the patchset.
Separating it from the series would lead to merge conflicts, because patch 7 depends on it.
If you're responsible for vdpa in general I could send patches 6 and 7 separately to you.
But number 7 depends on number 1, because pcim_iounmap_region() needs to be public. So if patches 1-5 enter through a different tree than yours, that could be a problem.
P.
Defer 1/7 until after the merge window, this is what is normally done.
1 cannot be deferred. Take a look what 1 does.
Your message is not comprehensible. Be so kind and write some more sentences. *What* is normally done? Sending patches? It's up to subsystem maintainers to queue them for the right cycle.
Adding new warnings is not nice, anyway.
What?
linux-stable-mirror@lists.linaro.org
-
Andy Shevchenko -
Michael S. Tsirkin -
Philipp Stanner