October 2020 - Linux-stable-mirror

[tip: perf/urgent] crypto: qat - check cipher length for aead AES-CBC-HMAC-SHA

by tip-bot2 for Dominik Przychodni

The following commit has been merged into the perf/urgent branch of tip: Commit-ID: 876ca389c95c69b0328ee887ab89207b7e4a66a3 Gitweb: https://git.kernel.org/tip/876ca389c95c69b0328ee887ab89207b7e4a66a3 Author: Dominik Przychodni <dominik.przychodni(a)intel.com> AuthorDate: Mon, 31 Aug 2020 11:59:59 +01:00 Committer: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> CommitterDate: Sat, 17 Oct 2020 08:31:22 +02:00 crypto: qat - check cipher length for aead AES-CBC-HMAC-SHA commit 45cb6653b0c355fc1445a8069ba78a4ce8720511 upstream. Return -EINVAL for authenc(hmac(sha1),cbc(aes)), authenc(hmac(sha256),cbc(aes)) and authenc(hmac(sha512),cbc(aes)) if the cipher length is not multiple of the AES block. This is to prevent an undefined device behaviour. Fixes: d370cec32194 ("crypto: qat - Intel(R) QAT crypto interface") Cc: <stable(a)vger.kernel.org> Signed-off-by: Dominik Przychodni <dominik.przychodni(a)intel.com> [giovanni.cabiddu(a)intel.com: reworded commit message] Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu(a)intel.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/crypto/qat/qat_common/qat_algs.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/crypto/qat/qat_common/qat_algs.c b/drivers/crypto/qat/qat_common/qat_algs.c index 72753b8..d552dbc 100644 --- a/drivers/crypto/qat/qat_common/qat_algs.c +++ b/drivers/crypto/qat/qat_common/qat_algs.c @@ -828,6 +828,11 @@ static int qat_alg_aead_dec(struct aead_request *areq) struct icp_qat_fw_la_bulk_req *msg; int digst_size = crypto_aead_authsize(aead_tfm); int ret, ctr = 0; + u32 cipher_len; + + cipher_len = areq->cryptlen - digst_size; + if (cipher_len % AES_BLOCK_SIZE != 0) + return -EINVAL; ret = qat_alg_sgl_to_bufl(ctx->inst, areq->src, areq->dst, qat_req); if (unlikely(ret)) @@ -842,7 +847,7 @@ static int qat_alg_aead_dec(struct aead_request *areq) qat_req->req.comn_mid.src_data_addr = qat_req->buf.blp; qat_req->req.comn_mid.dest_data_addr = qat_req->buf.bloutp; cipher_param = (void *)&qat_req->req.serv_specif_rqpars; - cipher_param->cipher_length = areq->cryptlen - digst_size; + cipher_param->cipher_length = cipher_len; cipher_param->cipher_offset = areq->assoclen; memcpy(cipher_param->u.cipher_IV_array, areq->iv, AES_BLOCK_SIZE); auth_param = (void *)((u8 *)cipher_param + sizeof(*cipher_param)); @@ -871,6 +876,9 @@ static int qat_alg_aead_enc(struct aead_request *areq) u8 *iv = areq->iv; int ret, ctr = 0; + if (areq->cryptlen % AES_BLOCK_SIZE != 0) + return -EINVAL; + ret = qat_alg_sgl_to_bufl(ctx->inst, areq->src, areq->dst, qat_req); if (unlikely(ret)) return ret;

4 years, 3 months

1
0
0 0

[tip: perf/urgent] crypto: bcm - Verify GCM/CCM key length in setkey

by tip-bot2 for Herbert Xu

The following commit has been merged into the perf/urgent branch of tip: Commit-ID: a745dda98d8a4e9946f2aca751a5b0a3cc71f474 Gitweb: https://git.kernel.org/tip/a745dda98d8a4e9946f2aca751a5b0a3cc71f474 Author: Herbert Xu <herbert(a)gondor.apana.org.au> AuthorDate: Fri, 02 Oct 2020 17:55:22 +10:00 Committer: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> CommitterDate: Sat, 17 Oct 2020 08:31:22 +02:00 crypto: bcm - Verify GCM/CCM key length in setkey commit 10a2f0b311094ffd45463a529a410a51ca025f27 upstream. The setkey function for GCM/CCM algorithms didn't verify the key length before copying the key and subtracting the salt length. This patch delays the copying of the key til after the verification has been done. It also adds checks on the key length to ensure that it's at least as long as the salt. Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver") Cc: <stable(a)vger.kernel.org> Reported-by: kiyin(尹亮) <kiyin(a)tencent.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/crypto/bcm/cipher.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/drivers/crypto/bcm/cipher.c b/drivers/crypto/bcm/cipher.c index 8a7fa1a..ba25d26 100644 --- a/drivers/crypto/bcm/cipher.c +++ b/drivers/crypto/bcm/cipher.c @@ -2930,7 +2930,6 @@ static int aead_gcm_ccm_setkey(struct crypto_aead *cipher, ctx->enckeylen = keylen; ctx->authkeylen = 0; - memcpy(ctx->enckey, key, ctx->enckeylen); switch (ctx->enckeylen) { case AES_KEYSIZE_128: @@ -2946,6 +2945,8 @@ static int aead_gcm_ccm_setkey(struct crypto_aead *cipher, goto badkey; } + memcpy(ctx->enckey, key, ctx->enckeylen); + flow_log(" enckeylen:%u authkeylen:%u\n", ctx->enckeylen, ctx->authkeylen); flow_dump(" enc: ", ctx->enckey, ctx->enckeylen); @@ -3000,6 +3001,10 @@ static int aead_gcm_esp_setkey(struct crypto_aead *cipher, struct iproc_ctx_s *ctx = crypto_aead_ctx(cipher); flow_log("%s\n", __func__); + + if (keylen < GCM_ESP_SALT_SIZE) + return -EINVAL; + ctx->salt_len = GCM_ESP_SALT_SIZE; ctx->salt_offset = GCM_ESP_SALT_OFFSET; memcpy(ctx->salt, key + keylen - GCM_ESP_SALT_SIZE, GCM_ESP_SALT_SIZE); @@ -3028,6 +3033,10 @@ static int rfc4543_gcm_esp_setkey(struct crypto_aead *cipher, struct iproc_ctx_s *ctx = crypto_aead_ctx(cipher); flow_log("%s\n", __func__); + + if (keylen < GCM_ESP_SALT_SIZE) + return -EINVAL; + ctx->salt_len = GCM_ESP_SALT_SIZE; ctx->salt_offset = GCM_ESP_SALT_OFFSET; memcpy(ctx->salt, key + keylen - GCM_ESP_SALT_SIZE, GCM_ESP_SALT_SIZE); @@ -3057,6 +3066,10 @@ static int aead_ccm_esp_setkey(struct crypto_aead *cipher, struct iproc_ctx_s *ctx = crypto_aead_ctx(cipher); flow_log("%s\n", __func__); + + if (keylen < CCM_ESP_SALT_SIZE) + return -EINVAL; + ctx->salt_len = CCM_ESP_SALT_SIZE; ctx->salt_offset = CCM_ESP_SALT_OFFSET; memcpy(ctx->salt, key + keylen - CCM_ESP_SALT_SIZE, CCM_ESP_SALT_SIZE);

4 years, 3 months

1
0
0 0

[PATCH 0/2] fix parsing of reboot= cmdline

by Matteo Croce

From: Matteo Croce <mcroce(a)microsoft.com> The parsing of the reboot= cmdline has two major errors: - a missing bound check can crash the system on reboot - parsing of the cpu number only works if specified last Fix both, along with a small code refactor. Matteo Croce (2): reboot: fix overflow parsing reboot cpu number reboot: fix parsing of reboot cpu number kernel/reboot.c | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) -- 2.26.2

4 years, 3 months

4
9
0 0

[patch V2 01/13] USB: sisusbvga: Make console support depend on BROKEN

by Thomas Gleixner

The console part of sisusbvga is broken vs. printk(). It uses in_atomic() to detect contexts in which it cannot sleep despite the big fat comment in preempt.h which says: Do not use in_atomic() in driver code. in_atomic() does not work on kernels with CONFIG_PREEMPT_COUNT=n which means that spin/rw_lock held regions are not detected by it. There is no way to make this work by handing context information through to the driver and this only can be solved once the core printk infrastructure supports sleepable console drivers. Make it depend on BROKEN for now. Fixes: 1bbb4f2035d9 ("[PATCH] USB: sisusb[vga] update") Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Thomas Winischhofer <thomas(a)winischhofer.net> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: linux-usb(a)vger.kernel.org Cc: stable(a)vger.kernel.org --- drivers/usb/misc/sisusbvga/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/usb/misc/sisusbvga/Kconfig +++ b/drivers/usb/misc/sisusbvga/Kconfig @@ -16,7 +16,7 @@ config USB_SISUSBVGA config USB_SISUSBVGA_CON bool "Text console and mode switching support" if USB_SISUSBVGA - depends on VT + depends on VT && BROKEN select FONT_8x16 help Say Y here if you want a VGA text console via the USB dongle or

4 years, 3 months

1
0
0 0

[PATCH v2 1/2] vt: keyboard, simplify vt_kdgkbsent

by Jiri Slaby

Use 'strlen' of the string, add one for NUL terminator and simply do 'copy_to_user' instead of the explicit 'for' loop. This makes the KDGKBSENT case more compact. The only thing we need to take care about is NULL 'func_table[i]'. Use an empty string in that case. The original check for overflow could never trigger as the func_buf strings are always shorter or equal to 'struct kbsentry's. Signed-off-by: Jiri Slaby <jslaby(a)suse.cz> Cc: <stable(a)vger.kernel.org> --- [v2] Removed the need for "reorder user buffer handling in vt_do_kdgkb_ioctl" patch. drivers/tty/vt/keyboard.c | 28 +++++++++------------------- 1 file changed, 9 insertions(+), 19 deletions(-) diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c index 0db53b5b3acf..7bfa95c3252c 100644 --- a/drivers/tty/vt/keyboard.c +++ b/drivers/tty/vt/keyboard.c @@ -1995,9 +1995,7 @@ int vt_do_kdsk_ioctl(int cmd, struct kbentry __user *user_kbe, int perm, int vt_do_kdgkb_ioctl(int cmd, struct kbsentry __user *user_kdgkb, int perm) { struct kbsentry *kbs; - char *p; u_char *q; - u_char __user *up; int sz, fnw_sz; int delta; char *first_free, *fj, *fnw; @@ -2023,23 +2021,15 @@ int vt_do_kdgkb_ioctl(int cmd, struct kbsentry __user *user_kdgkb, int perm) i = array_index_nospec(kbs->kb_func, MAX_NR_FUNC); switch (cmd) { - case KDGKBSENT: - sz = sizeof(kbs->kb_string) - 1; /* sz should have been - a struct member */ - up = user_kdgkb->kb_string; - p = func_table[i]; - if(p) - for ( ; *p && sz; p++, sz--) - if (put_user(*p, up++)) { - ret = -EFAULT; - goto reterr; - } - if (put_user('\0', up)) { - ret = -EFAULT; - goto reterr; - } - kfree(kbs); - return ((p && *p) ? -EOVERFLOW : 0); + case KDGKBSENT: { + /* size should have been a struct member */ + unsigned char *from = func_table[i] ? : ""; + + ret = copy_to_user(user_kdgkb->kb_string, from, + strlen(from) + 1) ? -EFAULT : 0; + + goto reterr; + } case KDSKBSENT: if (!perm) { ret = -EPERM; -- 2.28.0

4 years, 3 months

1
1
0 0

[PATCH] drm/i915: Rate limit 'Fault errors' message

by Stefan Fritsch

If linux is running as a guest and the host is doing igd pass-through with VT-d enabled, this message is logged dozens of times per second. Cc: stable(a)vger.kernel.org Signed-off-by: Stefan Fritsch <sf(a)sfritsch.de> --- The i915 driver should also detect VT-d in this case, but that is a different issue. I have sent a separate mail with subject 'Detecting Vt-d when running as guest os'. drivers/gpu/drm/i915/i915_irq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 759f523c6a6b..29096634e697 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -2337,7 +2337,7 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, u32 master_ctl) fault_errors = iir & gen8_de_pipe_fault_mask(dev_priv); if (fault_errors) - drm_err(&dev_priv->drm, + drm_err_ratelimited(&dev_priv->drm, "Fault errors on pipe %c: 0x%08x\n", pipe_name(pipe), fault_errors); -- 2.28.0

4 years, 3 months

2
2
0 0

Re: [PATCH v2] HID: i2c-hid: add polling mode based on connected GPIO chip's pin status

by Coiby Xu

On Sun, Oct 18, 2020 at 12:23:14PM +0000, Barnabás Pőcze wrote: >> [...] >> > > > > > +static int i2c_hid_polling_thread(void *i2c_hid) >> > > > > > +{ >> > > > > > >> > > > > > - struct i2c_hid *ihid = i2c_hid; >> > > > > > - struct i2c_client *client = ihid->client; >> > > > > > - unsigned int polling_interval_idle; >> > > > > > - >> > > > > > - while (1) { >> > > > > > - /* >> > > > > > >> > > > > > >> > > > > > - * re-calculate polling_interval_idle >> > > > > > >> > > > > > >> > > > > > - * so the module parameters polling_interval_idle_ms can be >> > > > > > >> > > > > > >> > > > > > - * changed dynamically through sysfs as polling_interval_active_us >> > > > > > >> > > > > > >> > > > > > - */ >> > > > > > >> > > > > > >> > > > > > - polling_interval_idle = polling_interval_idle_ms * 1000; >> > > > > > >> > > > > > >> > > > > > - if (test_bit(I2C_HID_READ_PENDING, &ihid->flags)) >> > > > > > >> > > > > > >> > > > > > - usleep_range(50000, 100000); >> > > > > > >> > > > > > >> > > > > > - >> > > > > > - if (kthread_should_stop()) >> > > > > > >> > > > > > >> > > > > > - break; >> > > > > > >> > > > > > >> > > > > > - >> > > > > > - while (interrupt_line_active(client)) { >> > > > > > >> > > > > > >> > > > > >> > > > > I realize it's quite unlikely, but can't this be a endless loop if data is coming >> > > > > in at a high enough rate? Maybe the maximum number of iterations could be limited here? >> > > > >> > > > If we find HID reports are constantly read and send to front-end >> > > > application like libinput, won't it help expose the problem of the I2C >> > > > HiD device? >> > > > >> > > > > >> > > >> > > I'm not sure I completely understand your point. The reason why I wrote what I wrote >> > > is that this kthread could potentially could go on forever (since `kthread_should_stop()` >> > > is not checked in the inner while loop) if the data is supplied at a high enough rate. >> > > That's why I said, to avoid this problem, only allow a certain number of iterations >> > > for the inner loop, to guarantee that the kthread can stop in any case. >> > >> > I mean if "data is supplied at a high enough rate" does happen, this is >> > an abnormal case and indicates a bug. So we shouldn't cover it up. We >> > expect the user to report it to us. >> > >> > > >> >> I agree in principle, but if this abnormal case ever occurs, that'll prevent >> this module from being unloaded since `kthread_stop()` will hang because the >> thread is "stuck" in the inner loop, never checking `kthread_should_stop()`. >> That's why I think it makes sense to only allow a certain number of operations >> for the inner loop, and maybe show a warning if that's exceeded: >> >> for (i = 0; i < max_iter && interrupt_line_active(...); i++) { >> .... >> } >> >> WARN_ON[CE](i == max_iter[, "data is coming in at an unreasonably high rate"]); >> > >I now realize that WARN_ON[CE] is probably not the best fit here, `hid_warn()` is possibly better. > Thank you for the suggestion! > >> or something like this, where `max_iter` could possibly be some value dependent on >> `polling_interval_active_us`, or even just a constant. >> [...] > > >Regards, >Barnabás Pőcze -- Best regards, Coiby

4 years, 3 months

1
0
0 0

Re: [PATCH v2] HID: i2c-hid: add polling mode based on connected GPIO chip's pin status

by Coiby Xu

On Sat, Oct 17, 2020 at 02:58:13PM +0000, Barnabás Pőcze wrote: >> [...] >> >> >> +static int get_gpio_pin_state(struct irq_desc *irq_desc) >> >> >> +{ >> >> >> + struct gpio_chip *gc = irq_data_get_irq_chip_data(&irq_desc->irq_data); >> >> >> + >> >> >> + return gc->get(gc, irq_desc->irq_data.hwirq); >> >> >> +} >> >> >> + >> >> >> +static bool interrupt_line_active(struct i2c_client *client) >> >> >> +{ >> >> >> + unsigned long trigger_type = irq_get_trigger_type(client->irq); >> >> >> + struct irq_desc *irq_desc = irq_to_desc(client->irq); >> >> >> + >> >> >> + /* >> >> >> + * According to Windows Precsiontion Touchpad's specs >> >> >> + * https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelin…, >> >> >> + * GPIO Interrupt Assertion Leve could be either ActiveLow or >> >> >> + * ActiveHigh. >> >> >> + */ >> >> >> + if (trigger_type & IRQF_TRIGGER_LOW) >> >> >> + return !get_gpio_pin_state(irq_desc); >> >> >> + >> >> >> + return get_gpio_pin_state(irq_desc); >> >> >> +} >> >> > >> >> >Excuse my ignorance, but I think some kind of error handling regarding the return >> >> >value of `get_gpio_pin_state()` should be present here. >> >> > >> >> What kind of errors would you expect? It seems (struct gpio_chip *)->get >> >> only return 0 or 1. >> >> > >> > >> >I read the code of a couple gpio chips and - I may be wrong, but - it seems they >> >can return an arbitrary errno. >> > >> I thought all GPIO chip return 0 or 1 since !!val is returned. I find >> an example which could return negative value, >> > >Yes, when a function returns `int`, there is a very high chance that the return >value may be an errno. > > >> > >> >> >> + >> >> >> +static int i2c_hid_polling_thread(void *i2c_hid) >> >> >> +{ >> >> >> + struct i2c_hid *ihid = i2c_hid; >> >> >> + struct i2c_client *client = ihid->client; >> >> >> + unsigned int polling_interval_idle; >> >> >> + >> >> >> + while (1) { >> >> >> + /* >> >> >> + * re-calculate polling_interval_idle >> >> >> + * so the module parameters polling_interval_idle_ms can be >> >> >> + * changed dynamically through sysfs as polling_interval_active_us >> >> >> + */ >> >> >> + polling_interval_idle = polling_interval_idle_ms * 1000; >> >> >> + if (test_bit(I2C_HID_READ_PENDING, &ihid->flags)) >> >> >> + usleep_range(50000, 100000); >> >> >> + >> >> >> + if (kthread_should_stop()) >> >> >> + break; >> >> >> + >> >> >> + while (interrupt_line_active(client)) { >> >> > >> >> >I realize it's quite unlikely, but can't this be a endless loop if data is coming >> >> >in at a high enough rate? Maybe the maximum number of iterations could be limited here? >> >> > >> >> If we find HID reports are constantly read and send to front-end >> >> application like libinput, won't it help expose the problem of the I2C >> >> HiD device? >> >> > >> > >> >I'm not sure I completely understand your point. The reason why I wrote what I wrote >> >is that this kthread could potentially could go on forever (since `kthread_should_stop()` >> >is not checked in the inner while loop) if the data is supplied at a high enough rate. >> >That's why I said, to avoid this problem, only allow a certain number of iterations >> >for the inner loop, to guarantee that the kthread can stop in any case. >> > >> I mean if "data is supplied at a high enough rate" does happen, this is >> an abnormal case and indicates a bug. So we shouldn't cover it up. We >> expect the user to report it to us. >> > > >I agree in principle, but if this abnormal case ever occurs, that'll prevent >this module from being unloaded since `kthread_stop()` will hang because the >thread is "stuck" in the inner loop, never checking `kthread_should_stop()`. >That's why I think it makes sense to only allow a certain number of operations >for the inner loop, and maybe show a warning if that's exceeded: > > for (i = 0; i < max_iter && interrupt_line_active(...); i++) { > .... > } > > WARN_ON[CE](i == max_iter[, "data is coming in at an unreasonably high rate"]); > >or something like this, where `max_iter` could possibly be some value dependent on >`polling_interval_active_us`, or even just a constant. > Thank you for suggesting this approach! It seems it would add a bit of complexity to detect this situation which could introduce other bugs. I did a experiment of creating a kthread that will loop forever and found the rebooting process wasn't stalled. I don't expect user to load&unload this module. So the end user could not notice this problem so my rationale is invalid. Thus I would be prefer to check `kthread_should_stop()` in the inner while loop instead. > >> >> >> + i2c_hid_get_input(ihid); >> >> >> + usleep_range(polling_interval_active_us, >> >> >> + polling_interval_active_us + 100); >> >> >> + } >> >> >> + >> >> >> + usleep_range(polling_interval_idle, >> >> >> + polling_interval_idle + 1000); >> >> >> + } >> >> >> + >> >> >> + do_exit(0); >> >> >> + return 0; >> >> >> +} >> [...] >> Thank you for offering your understandings on this patch. When I'm going >> to submit next version, I will add a "Signed-off-by" tag with your name >> and email, does it look good to you? >> [...] > >I'm not sure if that follows proper procedures. > > "The sign-off is a simple line at the end of the explanation for the patch, which > certifies that you wrote it or otherwise have the right to pass it on as an > open-source patch."[1] > >I'm not the author, nor co-author, nor am I going to pass this patch on, so I don't >think that's appropriate. > >Furthermore, please note that > > "[...] you may optionally add a Cc: tag to the patch. **This is the only tag which > might be added without an explicit action by the person it names** - but it should > indicate that this person was copied on the patch."[2] > (emphasis mine) > You have been directly contributing to this patch because several improvements of next version are from you. I experienced a similar situation when submitting patches for QEMU. The only difference is that the feedbacks on the QEMU patches were also given in the format of patch. Or do you think a reviewed-by tag from you after you think the next version is of production quality is a better way to credit you? > >Regards, >Barnabás Pőcze > > >[1]: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign… >[2]: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when… -- Best regards, Coiby

4 years, 3 months

1
0
0 0

[PATCH AUTOSEL 4.4 01/33] media: firewire: fix memory leak

by Sasha Levin

From: Pavel Machek <pavel(a)ucw.cz> [ Upstream commit b28e32798c78a346788d412f1958f36bb760ec03 ] Fix memory leak in node_probe. Signed-off-by: Pavel Machek (CIP) <pavel(a)denx.de> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/media/firewire/firedtv-fw.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/media/firewire/firedtv-fw.c b/drivers/media/firewire/firedtv-fw.c index 5d634706a7eaa..382f290c3f4d5 100644 --- a/drivers/media/firewire/firedtv-fw.c +++ b/drivers/media/firewire/firedtv-fw.c @@ -271,8 +271,10 @@ static int node_probe(struct fw_unit *unit, const struct ieee1394_device_id *id) name_len = fw_csr_string(unit->directory, CSR_MODEL, name, sizeof(name)); - if (name_len < 0) - return name_len; + if (name_len < 0) { + err = name_len; + goto fail_free; + } for (i = ARRAY_SIZE(model_names); --i; ) if (strlen(model_names[i]) <= name_len && strncmp(name, model_names[i], name_len) == 0) -- 2.25.1

4 years, 3 months

1
32
0 0

[PATCH AUTOSEL 4.9 01/41] crypto: ccp - fix error handling

by Sasha Levin

From: Pavel Machek <pavel(a)denx.de> [ Upstream commit e356c49c6cf0db3f00e1558749170bd56e47652d ] Fix resource leak in error handling. Signed-off-by: Pavel Machek (CIP) <pavel(a)denx.de> Acked-by: John Allen <john.allen(a)amd.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/crypto/ccp/ccp-ops.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/ccp/ccp-ops.c b/drivers/crypto/ccp/ccp-ops.c index c3f13d6505e15..0aa18c1164bfb 100644 --- a/drivers/crypto/ccp/ccp-ops.c +++ b/drivers/crypto/ccp/ccp-ops.c @@ -1195,7 +1195,7 @@ static int ccp_run_sha_cmd(struct ccp_cmd_queue *cmd_q, struct ccp_cmd *cmd) break; default: ret = -EINVAL; - goto e_ctx; + goto e_data; } } else { /* Stash the context */ -- 2.25.1

4 years, 3 months

1
40
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2020