| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CABXOdTcZWtoGzqqRWN4MWXh2se=rB=xtuMbSNe598-R0Mt=peg@mail.gmail.com>
Date: Tue, 7 Jun 2022 08:09:28 -0700
From: Guenter Roeck <groeck@...gle.com>
To: Martin Faltesek <mfaltesek@...gle.com>
Cc: Jakub Kicinski <kuba@...nel.org>, krzysztof.kozlowski@...aro.org,
christophe.ricard@...il.com,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
jordy@...ing.systems, Krzysztof Kozlowski <krzk@...nel.org>,
martin.faltesek@...il.com, netdev <netdev@...r.kernel.org>,
linux-nfc@...ts.01.org, sameo@...ux.intel.com,
William K Lin <wklin@...gle.com>, theflamefire89@...il.com,
"# v4 . 10+" <stable@...r.kernel.org>
Subject: Re: [PATCH net v3 3/3] nfc: st21nfca: fix incorrect sizing
calculations in EVT_TRANSACTION
On Mon, Jun 6, 2022 at 7:57 PM Martin Faltesek <mfaltesek@...gle.com> wrote:
>
> The transaction buffer is allocated by using the size of the packet buf,
> and subtracting two which seem intended to remove the two tags which are
> not present in the target structure. This calculation leads to under
> counting memory because of differences between the packet contents and the
> target structure. The aid_len field is a u8 in the packet, but a u32 in
> the structure, resulting in at least 3 bytes always being under counted.
> Further, the aid data is a variable length field in the packet, but fixed
> in the structure, so if this field is less than the max, the difference is
> added to the under counting.
>
> The last validation check for transaction->params_len is also incorrect
> since it employs the same accounting error.
>
> To fix, perform validation checks progressively to safely reach the
> next field, to determine the size of both buffers and verify both tags.
> Once all validation checks pass, allocate the buffer and copy the data.
> This eliminates freeing memory on the error path, as those checks are
> moved ahead of memory allocation.
>
> Fixes: 26fc6c7f02cb ("NFC: st21nfca: Add HCI transaction event support")
> Fixes: 4fbcc1a4cb20 ("nfc: st21nfca: Fix potential buffer overflows in EVT_TRANSACTION")
> Cc: stable@...r.kernel.org
> Signed-off-by: Martin Faltesek <mfaltesek@...gle.com>
Reviewed-by: Guenter Roeck <groeck@...omium.org>
> ---
> drivers/nfc/st21nfca/se.c | 60 +++++++++++++++++++--------------------
> 1 file changed, 30 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/nfc/st21nfca/se.c b/drivers/nfc/st21nfca/se.c
> index 8e1113ce139b..df8d27cf2956 100644
> --- a/drivers/nfc/st21nfca/se.c
> +++ b/drivers/nfc/st21nfca/se.c
> @@ -300,6 +300,8 @@ int st21nfca_connectivity_event_received(struct nfc_hci_dev *hdev, u8 host,
> int r = 0;
> struct device *dev = &hdev->ndev->dev;
> struct nfc_evt_transaction *transaction;
> + u32 aid_len;
> + u8 params_len;
>
> pr_debug("connectivity gate event: %x\n", event);
>
> @@ -308,50 +310,48 @@ int st21nfca_connectivity_event_received(struct nfc_hci_dev *hdev, u8 host,
> r = nfc_se_connectivity(hdev->ndev, host);
> break;
> case ST21NFCA_EVT_TRANSACTION:
> - /*
> - * According to specification etsi 102 622
> + /* According to specification etsi 102 622
> * 11.2.2.4 EVT_TRANSACTION Table 52
> * Description Tag Length
> * AID 81 5 to 16
> * PARAMETERS 82 0 to 255
> + *
> + * The key differences are aid storage length is variably sized
> + * in the packet, but fixed in nfc_evt_transaction, and that the aid_len
> + * is u8 in the packet, but u32 in the structure, and the tags in
> + * the packet are not included in nfc_evt_transaction.
> + *
> + * size in bytes: 1 1 5-16 1 1 0-255
> + * offset: 0 1 2 aid_len + 2 aid_len + 3 aid_len + 4
> + * member name: aid_tag(M) aid_len aid params_tag(M) params_len params
> + * example: 0x81 5-16 X 0x82 0-255 X
> */
> - if (skb->len < NFC_MIN_AID_LENGTH + 2 ||
> - skb->data[0] != NFC_EVT_TRANSACTION_AID_TAG)
> + if (skb->len < 2 || skb->data[0] != NFC_EVT_TRANSACTION_AID_TAG)
> return -EPROTO;
>
> - transaction = devm_kzalloc(dev, skb->len - 2, GFP_KERNEL);
> - if (!transaction)
> - return -ENOMEM;
> -
> - transaction->aid_len = skb->data[1];
> + aid_len = skb->data[1];
>
> - /* Checking if the length of the AID is valid */
> - if (transaction->aid_len > sizeof(transaction->aid)) {
> - devm_kfree(dev, transaction);
> - return -EINVAL;
> - }
> + if (skb->len < aid_len + 4 || aid_len > sizeof(transaction->aid))
> + return -EPROTO;
>
> - memcpy(transaction->aid, &skb->data[2],
> - transaction->aid_len);
> + params_len = skb->data[aid_len + 3];
>
> - /* Check next byte is PARAMETERS tag (82) */
> - if (skb->data[transaction->aid_len + 2] !=
> - NFC_EVT_TRANSACTION_PARAMS_TAG) {
> - devm_kfree(dev, transaction);
> + /* Verify PARAMETERS tag is (82), and final check that there is enough
> + * space in the packet to read everything.
> + */
> + if ((skb->data[aid_len + 2] != NFC_EVT_TRANSACTION_PARAMS_TAG) ||
> + (skb->len < aid_len + 4 + params_len))
> return -EPROTO;
> - }
>
> - transaction->params_len = skb->data[transaction->aid_len + 3];
> + transaction = devm_kzalloc(dev, sizeof(*transaction) + params_len, GFP_KERNEL);
> + if (!transaction)
> + return -ENOMEM;
>
> - /* Total size is allocated (skb->len - 2) minus fixed array members */
> - if (transaction->params_len > ((skb->len - 2) -
> - sizeof(struct nfc_evt_transaction))) {
> - devm_kfree(dev, transaction);
> - return -EINVAL;
> - }
> + transaction->aid_len = aid_len;
> + transaction->params_len = params_len;
>
> - memcpy(transaction->params, skb->data +
> - transaction->aid_len + 4, transaction->params_len);
> + memcpy(transaction->aid, &skb->data[2], aid_len);
> + memcpy(transaction->params, &skb->data[aid_len + 4], params_len);
>
> r = nfc_se_transaction(hdev->ndev, host, transaction);
> break;
> --
> 2.36.1.255.ge46751e96f-goog
>
Powered by blists - more mailing lists