- Linux-stable-mirror - lists.linaro.org

[PATCH 1/3] X.509: unpack RSA signatureValue field from BIT STRING

by David Howells

From: Maciej S. Szmigiero <mail(a)maciej.szmigiero.name> The signatureValue field of a X.509 certificate is encoded as a BIT STRING. For RSA signatures this BIT STRING is of so-called primitive subtype, which contains a u8 prefix indicating a count of unused bits in the encoding. We have to strip this prefix from signature data, just as we already do for key data in x509_extract_key_data() function. This wasn't noticed earlier because this prefix byte is zero for RSA key sizes divisible by 8. Since BIT STRING is a big-endian encoding adding zero prefixes has no bearing on its value. The signature length, however was incorrect, which is a problem for RSA implementations that need it to be exactly correct (like AMD CCP). Signed-off-by: Maciej S. Szmigiero <mail(a)maciej.szmigiero.name> Fixes: c26fd69fa009 ("X.509: Add a crypto key parser for binary (DER) X.509 certificates") Cc: stable(a)vger.kernel.org Signed-off-by: David Howells <dhowells(a)redhat.com> --- crypto/asymmetric_keys/x509_cert_parser.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/crypto/asymmetric_keys/x509_cert_parser.c b/crypto/asymmetric_keys/x509_cert_parser.c index 7d81e6bb461a..b6cabac4b62b 100644 --- a/crypto/asymmetric_keys/x509_cert_parser.c +++ b/crypto/asymmetric_keys/x509_cert_parser.c @@ -249,6 +249,15 @@ int x509_note_signature(void *context, size_t hdrlen, return -EINVAL; } + if (strcmp(ctx->cert->sig->pkey_algo, "rsa") == 0) { + /* Discard the BIT STRING metadata */ + if (vlen < 1 || *(const u8 *)value != 0) + return -EBADMSG; + + value++; + vlen--; + } + ctx->cert->raw_sig = value; ctx->cert->raw_sig_size = vlen; return 0;

7 years, 4 months

1
0
0 0

[PATCH v2] sched/rt: fix call to cpufreq_update_util

by Vincent Guittot

With commit 8f111bc357aa ("cpufreq/schedutil: Rewrite CPUFREQ_RT support") schedutil governor uses rq->rt.rt_nr_running to detect whether a RT task is currently running on the CPU and to set frequency to max if necessary. cpufreq_update_util() is called in enqueue/dequeue_top_rt_rq() but rq->rt.rt_nr_running as not been updated yet when dequeue_top_rt_rq() is called so schedutil still considers that a RT task is running when the last task is dequeued. The update of rq->rt.rt_nr_running happens later in dequeue_rt_stack() Fixes: 8f111bc357aa ('cpufreq/schedutil: Rewrite CPUFREQ_RT support') Cc: <stable(a)vger.kernel.org> # v4.16+ Signed-off-by: Vincent Guittot <vincent.guittot(a)linaro.org> --- - v2: - remove blank line kernel/sched/rt.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c index 7aef6b4..a9f1119 100644 --- a/kernel/sched/rt.c +++ b/kernel/sched/rt.c @@ -1000,9 +1000,6 @@ dequeue_top_rt_rq(struct rt_rq *rt_rq) sub_nr_running(rq, rt_rq->rt_nr_running); rt_rq->rt_queued = 0; - - /* Kick cpufreq (see the comment in kernel/sched/sched.h). */ - cpufreq_update_util(rq, 0); } static void @@ -1288,6 +1285,9 @@ static void dequeue_rt_stack(struct sched_rt_entity *rt_se, unsigned int flags) if (on_rt_rq(rt_se)) __dequeue_rt_entity(rt_se, flags); } + + /* Kick cpufreq (see the comment in kernel/sched/sched.h). */ + cpufreq_update_util(rq_of_rt_rq(rt_rq_of_se(back)), 0); } static void enqueue_rt_entity(struct sched_rt_entity *rt_se, unsigned int flags) -- 2.7.4

7 years, 4 months

2
5
0 0

[PATCH 2/2] power: generic-adc-battery: check for duplicate properties copied from iio channels

by H. Nikolaus Schaller

If an iio channel defines a basic property, there are duplicate entries in /sys/class/power/*/uevent. So add a check to avoid duplicates. Since all channels may be duplicates, we have to modify the related error check. Signed-off-by: H. Nikolaus Schaller <hns(a)goldelico.com> Cc: stable(a)vger.kernel.org --- drivers/power/supply/generic-adc-battery.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/drivers/power/supply/generic-adc-battery.c b/drivers/power/supply/generic-adc-battery.c index 11f59275bff4..bc462d1ec963 100644 --- a/drivers/power/supply/generic-adc-battery.c +++ b/drivers/power/supply/generic-adc-battery.c @@ -244,6 +244,7 @@ static int gab_probe(struct platform_device *pdev) int ret = 0; int chan; int index = ARRAY_SIZE(gab_props); + bool any = false; adc_bat = devm_kzalloc(&pdev->dev, sizeof(*adc_bat), GFP_KERNEL); if (!adc_bat) { @@ -290,12 +291,22 @@ static int gab_probe(struct platform_device *pdev) adc_bat->channel[chan] = NULL; } else { /* copying properties for supported channels only */ - psy_desc->properties[index++] = gab_dyn_props[chan]; + int index2; + + for (index2 = 0; index2 < index; index2++) { + if (psy_desc->properties[index2] == + gab_dyn_props[chan]) + break; /* already known */ + } + if (index2 == index) /* really new */ + psy_desc->properties[index++] = + gab_dyn_props[chan]; + any = true; } } /* none of the channels are supported so let's bail out */ - if (index == ARRAY_SIZE(gab_props)) { + if (!any) { ret = -ENODEV; goto second_mem_fail; } -- 2.12.2

7 years, 4 months

1
0
0 0

[PATCH 1/2] power: generic-adc-battery: fix out-of-bounds write when copying channel properties

by H. Nikolaus Schaller

We did have sporadic problems in the pinctrl framework during boot where a pin group name unexpectedly became NULL leading to a NULL dereference in strcmp. Detailled analysis of the failing cases did reveal that there were two devm allocated objects close to each other. The second one was the affected group_desc in pinmux and the first one was the psy_desc->properties buffer of the gab driver. Review of the gab code showed that the address calculation for one memcpy() is wrong. It does properties + sizeof(type) * index but C is defined to do the index multiplication already for pointer + integer additions. Hence the factor was applied twice and the memcpy() does write outside of the properties buffer. Sometimes it happened to be the pinctrl and triggered the strcmp(NULL). Anyways, it is overkill to use a memcpy() here instead of a simple assignment, which is easier to read and has less risk for wrong address calculations. So we change code to a simple assignment. If we initialize the index to the first free location, we can even remove the local variable 'properties'. This bug seems to exist right from the beginning in 3.7-rc1 in commit e60fea794e6e ("power: battery: Generic battery driver using IIO") Signed-off-by: H. Nikolaus Schaller <hns(a)goldelico.com> Cc: stable(a)vger.kernel.org --- drivers/power/supply/generic-adc-battery.c | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/drivers/power/supply/generic-adc-battery.c b/drivers/power/supply/generic-adc-battery.c index 28dc056eaafa..11f59275bff4 100644 --- a/drivers/power/supply/generic-adc-battery.c +++ b/drivers/power/supply/generic-adc-battery.c @@ -241,10 +241,9 @@ static int gab_probe(struct platform_device *pdev) struct power_supply_desc *psy_desc; struct power_supply_config psy_cfg = {}; struct gab_platform_data *pdata = pdev->dev.platform_data; - enum power_supply_property *properties; int ret = 0; int chan; - int index = 0; + int index = ARRAY_SIZE(gab_props); adc_bat = devm_kzalloc(&pdev->dev, sizeof(*adc_bat), GFP_KERNEL); if (!adc_bat) { @@ -278,8 +277,6 @@ static int gab_probe(struct platform_device *pdev) } memcpy(psy_desc->properties, gab_props, sizeof(gab_props)); - properties = (enum power_supply_property *) - ((char *)psy_desc->properties + sizeof(gab_props)); /* * getting channel from iio and copying the battery properties @@ -293,15 +290,12 @@ static int gab_probe(struct platform_device *pdev) adc_bat->channel[chan] = NULL; } else { /* copying properties for supported channels only */ - memcpy(properties + sizeof(*(psy_desc->properties)) * index, - &gab_dyn_props[chan], - sizeof(gab_dyn_props[chan])); - index++; + psy_desc->properties[index++] = gab_dyn_props[chan]; } } /* none of the channels are supported so let's bail out */ - if (index == 0) { + if (index == ARRAY_SIZE(gab_props)) { ret = -ENODEV; goto second_mem_fail; } @@ -312,7 +306,7 @@ static int gab_probe(struct platform_device *pdev) * as come channels may be not be supported by the device.So * we need to take care of that. */ - psy_desc->num_properties = ARRAY_SIZE(gab_props) + index; + psy_desc->num_properties = index; adc_bat->psy = power_supply_register(&pdev->dev, psy_desc, &psy_cfg); if (IS_ERR(adc_bat->psy)) { -- 2.12.2

7 years, 4 months

1
0
0 0

[PATCH V2 2/2] ata: Fix ZBC_OUT all bit handling

by Damien Le Moal

If the ALL bit is set in the ZBC_OUT command, the command zone ID field (block) should be ignored. Reported-by: David Butterfield <david.butterfield(a)wdc.com> Signed-off-by: Damien Le Moal <damien.lemoal(a)wdc.com> Cc: stable(a)vger.kernel.org --- drivers/ata/libata-scsi.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c index a5543751f446..aad1b01447de 100644 --- a/drivers/ata/libata-scsi.c +++ b/drivers/ata/libata-scsi.c @@ -3805,7 +3805,14 @@ static unsigned int ata_scsi_zbc_out_xlat(struct ata_queued_cmd *qc) */ goto invalid_param_len; } - if (block >= dev->n_sectors) { + + all = cdb[14] & 0x1; + if (all) { + /* + * Ignore the block address (zone ID) as defined by ZBC. + */ + block = 0; + } else if (block >= dev->n_sectors) { /* * Block must be a valid zone ID (a zone start LBA). */ @@ -3813,8 +3820,6 @@ static unsigned int ata_scsi_zbc_out_xlat(struct ata_queued_cmd *qc) goto invalid_fld; } - all = cdb[14] & 0x1; - if (ata_ncq_enabled(qc->dev) && ata_fpdma_zac_mgmt_out_supported(qc->dev)) { tf->protocol = ATA_PROT_NCQ_NODATA; -- 2.17.1

7 years, 4 months

1
0
0 0

[PATCH V2 1/2] ata: Fix ZBC_OUT command block check

by Damien Le Moal

The block (LBA) specified must not exceed the last addressable LBA, which is dev->nr_sectors - 1. So fix the correct check is "if (block >= dev->n_sectors)" and not "if (block > dev->n_sectords)". Additionally, the asc/ascq to return for an LBA that is not a zone start LBA should be ILLEGAL REQUEST, regardless if the bad LBA is out of range. Reported-by: David Butterfield <david.butterfield(a)wdc.com> Signed-off-by: Damien Le Moal <damien.lemoal(a)wdc.com> Cc: stable(a)vger.kernel.org --- drivers/ata/libata-scsi.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c index 6a91d04351d9..a5543751f446 100644 --- a/drivers/ata/libata-scsi.c +++ b/drivers/ata/libata-scsi.c @@ -3805,8 +3805,13 @@ static unsigned int ata_scsi_zbc_out_xlat(struct ata_queued_cmd *qc) */ goto invalid_param_len; } - if (block > dev->n_sectors) - goto out_of_range; + if (block >= dev->n_sectors) { + /* + * Block must be a valid zone ID (a zone start LBA). + */ + fp = 2; + goto invalid_fld; + } all = cdb[14] & 0x1; @@ -3837,10 +3842,6 @@ static unsigned int ata_scsi_zbc_out_xlat(struct ata_queued_cmd *qc) invalid_fld: ata_scsi_set_invalid_field(qc->dev, scmd, fp, 0xff); return 1; - out_of_range: - /* "Logical Block Address out of range" */ - ata_scsi_set_sense(qc->dev, scmd, ILLEGAL_REQUEST, 0x21, 0x00); - return 1; invalid_param_len: /* "Parameter list length error" */ ata_scsi_set_sense(qc->dev, scmd, ILLEGAL_REQUEST, 0x1a, 0x0); -- 2.17.1

7 years, 4 months

1
0
0 0

[PATCH 0/2] ZBC_OUT command translation fixes

by Damien Le Moal

Tejun, These two patches fix problems with the checks of the ZBC_OUT command fields prior to its translation to ZAC MANAGEMENT OUT. The first patch fixes an incorrect out-of-range check and changes the returned asc/ascq to the ZBC defined INVALID FIELD IN CDB instead of (the more natural but incorrect) LBA OUT OF RANGE. The second patch disables the ZBC_OUT command block address check if the ALL bit is set, as defined by the ZBC specifications. Thank you for considering these patches for inclusion in 4.18 fixes (and CC stable). Damien Le Moal (2): ata: Fix ZBC_OUT command block check ata: Fix ZBC_OUT all bit handling drivers/ata/libata-scsi.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) -- 2.17.1

7 years, 4 months

2
4
0 0

Re: make a confirm for [usb: dwc3: gadget: skip Set/Clear Halt when invalid]

by liangshengjun

Hi balbi, Thanks for reponse. Now I fixed this case without check STALL status when clear-Halt request. BDW, I have meet other case: Run dwc3 for uvc function, the uvc video show video overlapping when windows 7 restart camera app. I debug the dwc3 drivers ,found : 1. when camera app close, the dwc3 ep_dequeue is call. Then giveback request with status: -ECONNRESET to uvc function layer. dep->trb_dequeue keep stable 2.when camera app reopen ,the dwc3 ep_queue is call. Then kick a transfer, fetch a new trb to dwc3 core. dep->trb_enqueue increment. 3.when one trb tranfter complete, handle event process function fetch one frb by current dep->trb_dequeue, and uvc function would get one request complete giveback, which have been dequeue. But in fact, current dep->trb_dequeue pointer buffer is "old", because stp1 have been dequeue it. Current dwc3 drivers: the correct enqueue req process is " ep enqueue > fetch a new trb by trb_enqueue > increase trb_enqueue > pack trb to dwc3 core", Right? For dequeue request process, now is " ep dequeue > stop started_list request > giveback request with -ECONNRESET status" Right ? To avoid getting a older request which has been dequeued, I think dequeue process necessary sync the trb_dequeue to trb_enqueue. Right ? Liang Shengjun -----邮件原件----- 发件人: Felipe Balbi [mailto:felipe.balbi@linux.intel.com] 发送时间: 2018年6月25日 15:48 收件人: Alan Stern <stern(a)rowland.harvard.edu> 抄送: liangshengjun <liangshengjun(a)hisilicon.com>; stable(a)vger.kernel.org; linux-usb(a)vger.kernel.org 主题: Re: make a confirm for [usb: dwc3: gadget: skip Set/Clear Halt when invalid] Hi, Alan Stern <stern(a)rowland.harvard.edu> writes: >> that patch is not 100% correct. You can revert it in your tree. I >> added that because of a problem I found when running adb against macOS. >> >> It's actually okay to send Clear Halt at any time, but for some >> reason >> dwc3 was hanging when running adb against macOS. > > Note: According to the USB spec it's okay to send Clear-Halt at any > time. But there are plenty of devices that get upset if they receive > this message when the endpoint isn't actually halted. right. The weird thing here is that dwc3 has never suffered from this until we ran ADB against macOS. That was the only way to get any problems. Without clear halt, though, we have no means for syncing data toggle. -- balbi

7 years, 4 months

2
2
0 0

v4.9.110 build: 0 failures 0 warnings (v4.9.110)

by Build bot for Mark Brown

Tree/Branch: v4.9.110 Git describe: v4.9.110 Commit: c806e08569 Linux 4.9.110 Build Time: 83 min 42 sec Passed: 11 / 11 (100.00 %) Failed: 0 / 11 ( 0.00 %) Errors: 0 Warnings: 0 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): ------------------------------------------------------------------------------- =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: arm64-allnoconfig arm64-allmodconfig arm-multi_v5_defconfig arm-multi_v7_defconfig x86_64-defconfig arm-allmodconfig arm-allnoconfig x86_64-allnoconfig arm-multi_v4t_defconfig x86_64-allmodconfig arm64-defconfig close failed in file object destructor: sys.excepthook is missing lost sys.stderr

7 years, 4 months

1
0
0 0

Remove fpu lazy mode deadcode from 4.4.y

by Daniel Sangorrin

Hello Greg, #Forgot to add --compose Following up on our discussion during the review of kernel 4.4.138-stable, I have backported a few patches that remove the remaining FPU lazy mode deadcode from 4.4.y and 4.9.y. To avoid confusion I will send the explanation on separate e-mails: Patches for 4.4.y: [PATCH 1/4] KVM: x86: remove eager_fpu field of struct kvm_vcpu_arch - This is a git cherry-pick of 5a5fbdc0e3f1 ("KVM: x86: remove eager_fpu field of struct kvm_vcpu_arch"). It applies cleanly and is required for the next patch not to cause conflicts on arch/x86/kvm/cpuid.c [PATCH 2/4] x86/fpu: Remove use_eager_fpu() - The main conflict ocurred on fpu/core.c because commit bf15a8cf8d14 ("x86/fpu/xstate: Rename 'xstate_size' to 'fpu_kernel_xstate_size', to distinguish it from 'fpu_user_xstate_size'") is not on 4.4.y. That commit renames xstate_size to fpu_kernel_xstate_size but it also has its conflicts so I decided just to fix the conflict manually/ [PATCH 3/4] x86/fpu: Remove struct fpu::counter - caused one conflict because 4.4.y does not have commit d1898b733619 ("x86/fpu: Add tracepoints to dump FPU state at key points") I fixed it manually. [PATCH 4/4] x86/fpu: Finish excising 'eagerfpu' - caused a small conflict because 'nopku' is not in 4.4.y - sorry my editor might have removed a couple of trailing spaces automatically to Documentation/kernel-paramters.txt - cause one conflict in these files because they didn't exist arch/x86/include/asm/cpufeatures.h arch/x86/mm/pkeys.c tools/arch/x86/include/asm/cpufeatures.h - Instead I removed the X86_FEATURE_EAGER_FPU definition from arch/x86/include/asm/cpufeature.h Best regards, Daniel Sangorrin PS: Used git send-email --to stable(a)vger.kernel.org --cc-cmd="./scripts/get_maintainer.pl --norolestats" 2197a44..HEAD but it doesn't seem to work sorry...humm

7 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror