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: <b0f65aaa-37aa-378f-fbbf-57d107f29f5f@linaro.org> Date: Mon, 27 Feb 2023 11:08:54 +0100 From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org> To: Fedor Pchelkin <pchelkin@...ras.ru> Cc: "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Guenter Roeck <groeck@...gle.com>, Martin Faltesek <mfaltesek@...gle.com>, Duoming Zhou <duoming@....edu.cn>, Samuel Ortiz <sameo@...ux.intel.com>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, Alexey Khoroshilov <khoroshilov@...ras.ru>, lvc-project@...uxtesting.org, syzbot+df64c0a2e8d68e78a4fa@...kaller.appspotmail.com Subject: Re: [PATCH] nfc: fix memory leak of se_io context in nfc_genl_se_io On 25/02/2023 11:56, Fedor Pchelkin wrote: > The callback context for sending/receiving APDUs to/from the selected > secure element is allocated inside nfc_genl_se_io and supposed to be > eventually freed in se_io_cb callback function. However, there are several > error paths where the bwi_timer is not charged to call se_io_cb later, and > the cb_context is leaked. > > The patch proposes to free the cb_context explicitly on those error paths. Do not use "This commit/patch". https://elixir.bootlin.com/linux/v5.17.1/source/Documentation/process/submitting-patches.rst#L95 > > At the moment we can't simply check 'dev->ops->se_io()' return value as it > may be negative in both cases: when the timer was charged and was not. > > Fixes: 5ce3f32b5264 ("NFC: netlink: SE API implementation") > Reported-by: syzbot+df64c0a2e8d68e78a4fa@...kaller.appspotmail.com > Signed-off-by: Fedor Pchelkin <pchelkin@...ras.ru> > Signed-off-by: Alexey Khoroshilov <khoroshilov@...ras.ru> SoB order is a bit odd. Who is the author? > --- > drivers/nfc/st-nci/se.c | 6 ++++++ > drivers/nfc/st21nfca/se.c | 6 ++++++ > net/nfc/netlink.c | 4 ++++ > 3 files changed, 16 insertions(+) > > diff --git a/drivers/nfc/st-nci/se.c b/drivers/nfc/st-nci/se.c > index ec87dd21e054..b2f1ced8e6dd 100644 > --- a/drivers/nfc/st-nci/se.c > +++ b/drivers/nfc/st-nci/se.c > @@ -672,6 +672,12 @@ int st_nci_se_io(struct nci_dev *ndev, u32 se_idx, > ST_NCI_EVT_TRANSMIT_DATA, apdu, > apdu_length) nci_hci_send_event() should also free it in its error paths. nci_data_exchange_complete() as well? Who eventually frees it? These might be separate patches. > default: > + /* Need to free cb_context here as at the moment we can't > + * clearly indicate to the caller if the callback function > + * would be called (and free it) or not. In both cases a > + * negative value may be returned to the caller. > + */ > + kfree(cb_context); > return -ENODEV; > } > } > diff --git a/drivers/nfc/st21nfca/se.c b/drivers/nfc/st21nfca/se.c > index df8d27cf2956..dae288bebcb5 100644 > --- a/drivers/nfc/st21nfca/se.c > +++ b/drivers/nfc/st21nfca/se.c > @@ -236,6 +236,12 @@ int st21nfca_hci_se_io(struct nfc_hci_dev *hdev, u32 se_idx, > ST21NFCA_EVT_TRANSMIT_DATA, > apdu, apdu_length); > default: > + /* Need to free cb_context here as at the moment we can't > + * clearly indicate to the caller if the callback function > + * would be called (and free it) or not. In both cases a > + * negative value may be returned to the caller. > + */ > + kfree(cb_context); > return -ENODEV; > } > } > diff --git a/net/nfc/netlink.c b/net/nfc/netlink.c > index 1fc339084d89..348bf561bc9f 100644 > --- a/net/nfc/netlink.c > +++ b/net/nfc/netlink.c > @@ -1442,7 +1442,11 @@ static int nfc_se_io(struct nfc_dev *dev, u32 se_idx, > rc = dev->ops->se_io(dev, se_idx, apdu, > apdu_length, cb, cb_context); > > + device_unlock(&dev->dev); > + return rc; > + > error: > + kfree(cb_context); kfree could be after device_unlock. Although se_io() will free it with lock held, but error paths usually unwind everything in reverse order LIFO, so first unlock then kfree. > device_unlock(&dev->dev); > return rc; > } Best regards, Krzysztof
Powered by blists - more mailing lists