linux-stable.git/drivers/staging/rtl8192e, branch linux-5.11.y Linux kernel stable tree staging: rtl8192e: Change state information from u16 to u8 2021-04-07T13:02:35+00:00 Atul Gopinathan atulgopinathan@gmail.com 2021-03-23T11:34:14+00:00 b5fab3adcf0027a1a5e715a9f62c021192bdee62 commit e78836ae76d20f38eed8c8c67f21db97529949da upstream. The "u16 CcxRmState[2];" array field in struct "rtllib_network" has 4 bytes in total while the operations performed on this array through-out the code base are only 2 bytes. The "CcxRmState" field is fed only 2 bytes of data using memcpy(): (In rtllib_rx.c:1972) memcpy(network->CcxRmState, &info_element->data[4], 2) With "info_element->data[]" being a u8 array, if 2 bytes are written into "CcxRmState" (whose one element is u16 size), then the 2 u8 elements from "data[]" gets squashed and written into the first element ("CcxRmState[0]") while the second element ("CcxRmState[1]") is never fed with any data. Same in file rtllib_rx.c:2522: memcpy(dst->CcxRmState, src->CcxRmState, 2); The above line duplicates "src" data to "dst" but only writes 2 bytes (and not 4, which is the actual size). Again, only 1st element gets the value while the 2nd element remains uninitialized. This later makes operations done with CcxRmState unpredictable in the following lines as the 1st element is having a squashed number while the 2nd element is having an uninitialized random number. rtllib_rx.c:1973: if (network->CcxRmState[0] != 0) rtllib_rx.c:1977: network->MBssidMask = network->CcxRmState[1] & 0x07; network->MBssidMask is also of type u8 and not u16. Fix this by changing the type of "CcxRmState" from u16 to u8 so that the data written into this array and read from it make sense and are not random values. NOTE: The wrong initialization of "CcxRmState" can be seen in the following commit: commit ecdfa44610fa ("Staging: add Realtek 8192 PCI wireless driver") The above commit created a file `rtl8192e/ieee80211.h` which used to have the faulty line. The file has been deleted (or possibly renamed) with the contents copied in to a new file `rtl8192e/rtllib.h` along with additional code in the commit 94a799425eee (tagged in Fixes). Fixes: 94a799425eee ("From: wlanfae <wlanfae@realtek.com> [PATCH 1/8] rtl8192e: Import new version of driver from realtek") Cc: stable@vger.kernel.org Signed-off-by: Atul Gopinathan <atulgopinathan@gmail.com> Link: https://lore.kernel.org/r/20210323113413.29179-2-atulgopinathan@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit e78836ae76d20f38eed8c8c67f21db97529949da upstream.

The "u16 CcxRmState[2];" array field in struct "rtllib_network" has 4
bytes in total while the operations performed on this array through-out
the code base are only 2 bytes.

The "CcxRmState" field is fed only 2 bytes of data using memcpy():

(In rtllib_rx.c:1972)
	memcpy(network->CcxRmState, &info_element->data[4], 2)

With "info_element->data[]" being a u8 array, if 2 bytes are written
into "CcxRmState" (whose one element is u16 size), then the 2 u8
elements from "data[]" gets squashed and written into the first element
("CcxRmState[0]") while the second element ("CcxRmState[1]") is never
fed with any data.

Same in file rtllib_rx.c:2522:
	 memcpy(dst->CcxRmState, src->CcxRmState, 2);

The above line duplicates "src" data to "dst" but only writes 2 bytes
(and not 4, which is the actual size). Again, only 1st element gets the
value while the 2nd element remains uninitialized.

This later makes operations done with CcxRmState unpredictable in the
following lines as the 1st element is having a squashed number while the
2nd element is having an uninitialized random number.

rtllib_rx.c:1973:    if (network->CcxRmState[0] != 0)
rtllib_rx.c:1977:    network->MBssidMask = network->CcxRmState[1] & 0x07;

network->MBssidMask is also of type u8 and not u16.

Fix this by changing the type of "CcxRmState" from u16 to u8 so that the
data written into this array and read from it make sense and are not
random values.

NOTE: The wrong initialization of "CcxRmState" can be seen in the
following commit:

commit ecdfa44610fa ("Staging: add Realtek 8192 PCI wireless driver")

The above commit created a file `rtl8192e/ieee80211.h` which used to
have the faulty line. The file has been deleted (or possibly renamed)
with the contents copied in to a new file `rtl8192e/rtllib.h` along with
additional code in the commit 94a799425eee (tagged in Fixes).

Fixes: 94a799425eee ("From: wlanfae <wlanfae@realtek.com> [PATCH 1/8] rtl8192e: Import new version of driver from realtek")
Cc: stable@vger.kernel.org
Signed-off-by: Atul Gopinathan <atulgopinathan@gmail.com>
Link: https://lore.kernel.org/r/20210323113413.29179-2-atulgopinathan@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: rtl8192e: Fix incorrect source in memcpy() 2021-04-07T13:02:35+00:00 Atul Gopinathan atulgopinathan@gmail.com 2021-03-23T11:34:12+00:00 c14876c9324a942bc5ba5ea58cdb92521b646b5f commit 72ad25fbbb78930f892b191637359ab5b94b3190 upstream. The variable "info_element" is of the following type: struct rtllib_info_element *info_element defined in drivers/staging/rtl8192e/rtllib.h: struct rtllib_info_element { u8 id; u8 len; u8 data[]; } __packed; The "len" field defines the size of the "data[]" array. The code is supposed to check if "info_element->len" is greater than 4 and later equal to 6. If this is satisfied then, the last two bytes (the 4th and 5th element of u8 "data[]" array) are copied into "network->CcxRmState". Right now the code uses "memcpy()" with the source as "&info_element[4]" which would copy in wrong and unintended information. The struct "rtllib_info_element" has a size of 2 bytes for "id" and "len", therefore indexing will be done in interval of 2 bytes. So, "info_element[4]" would point to data which is beyond the memory allocated for this pointer (that is, at x+8, while "info_element" has been allocated only from x to x+7 (2 + 6 => 8 bytes)). This patch rectifies this error by using "&info_element->data[4]" which correctly copies the last two bytes of "data[]". NOTE: The faulty line of code came from the following commit: commit ecdfa44610fa ("Staging: add Realtek 8192 PCI wireless driver") The above commit created the file `rtl8192e/ieee80211/ieee80211_rx.c` which had the faulty line of code. This file has been deleted (or possibly renamed) with the contents copied in to a new file `rtl8192e/rtllib_rx.c` along with additional code in the commit 94a799425eee (tagged in Fixes). Fixes: 94a799425eee ("From: wlanfae <wlanfae@realtek.com> [PATCH 1/8] rtl8192e: Import new version of driver from realtek") Cc: stable@vger.kernel.org Signed-off-by: Atul Gopinathan <atulgopinathan@gmail.com> Link: https://lore.kernel.org/r/20210323113413.29179-1-atulgopinathan@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 72ad25fbbb78930f892b191637359ab5b94b3190 upstream.

The variable "info_element" is of the following type:

	struct rtllib_info_element *info_element

defined in drivers/staging/rtl8192e/rtllib.h:

	struct rtllib_info_element {
		u8 id;
		u8 len;
		u8 data[];
	} __packed;

The "len" field defines the size of the "data[]" array. The code is
supposed to check if "info_element->len" is greater than 4 and later
equal to 6. If this is satisfied then, the last two bytes (the 4th and
5th element of u8 "data[]" array) are copied into "network->CcxRmState".

Right now the code uses "memcpy()" with the source as "&info_element[4]"
which would copy in wrong and unintended information. The struct
"rtllib_info_element" has a size of 2 bytes for "id" and "len",
therefore indexing will be done in interval of 2 bytes. So,
"info_element[4]" would point to data which is beyond the memory
allocated for this pointer (that is, at x+8, while "info_element" has
been allocated only from x to x+7 (2 + 6 => 8 bytes)).

This patch rectifies this error by using "&info_element->data[4]" which
correctly copies the last two bytes of "data[]".

NOTE: The faulty line of code came from the following commit:

commit ecdfa44610fa ("Staging: add Realtek 8192 PCI wireless driver")

The above commit created the file `rtl8192e/ieee80211/ieee80211_rx.c`
which had the faulty line of code. This file has been deleted (or
possibly renamed) with the contents copied in to a new file
`rtl8192e/rtllib_rx.c` along with additional code in the commit
94a799425eee (tagged in Fixes).

Fixes: 94a799425eee ("From: wlanfae <wlanfae@realtek.com> [PATCH 1/8] rtl8192e: Import new version of driver from realtek")
Cc: stable@vger.kernel.org
Signed-off-by: Atul Gopinathan <atulgopinathan@gmail.com>
Link: https://lore.kernel.org/r/20210323113413.29179-1-atulgopinathan@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: rtl8192e: fix kconfig dependency on CRYPTO 2021-03-30T12:30:10+00:00 Julian Braha julianbraha@gmail.com 2021-02-22T18:06:07+00:00 3f88406e5b5b152b6e8aca284b19a2a51cc1d5a7 [ Upstream commit 7c36194558cf49a86a53b5f60db8046c5e3013ae ] When RTLLIB_CRYPTO_TKIP is enabled and CRYPTO is disabled, Kbuild gives the following warning: WARNING: unmet direct dependencies detected for CRYPTO_MICHAEL_MIC Depends on [n]: CRYPTO [=n] Selected by [m]: - RTLLIB_CRYPTO_TKIP [=m] && STAGING [=y] && RTLLIB [=m] WARNING: unmet direct dependencies detected for CRYPTO_LIB_ARC4 Depends on [n]: CRYPTO [=n] Selected by [m]: - RTLLIB_CRYPTO_TKIP [=m] && STAGING [=y] && RTLLIB [=m] - RTLLIB_CRYPTO_WEP [=m] && STAGING [=y] && RTLLIB [=m] This is because RTLLIB_CRYPTO_TKIP selects CRYPTO_MICHAEL_MIC and CRYPTO_LIB_ARC4, without depending on or selecting CRYPTO, despite those config options being subordinate to CRYPTO. Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Julian Braha <julianbraha@gmail.com> Link: https://lore.kernel.org/r/20210222180607.399753-1-julianbraha@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 7c36194558cf49a86a53b5f60db8046c5e3013ae ]

When RTLLIB_CRYPTO_TKIP is enabled and CRYPTO is disabled,
Kbuild gives the following warning:

WARNING: unmet direct dependencies detected for CRYPTO_MICHAEL_MIC
  Depends on [n]: CRYPTO [=n]
  Selected by [m]:
  - RTLLIB_CRYPTO_TKIP [=m] && STAGING [=y] && RTLLIB [=m]

WARNING: unmet direct dependencies detected for CRYPTO_LIB_ARC4
  Depends on [n]: CRYPTO [=n]
  Selected by [m]:
  - RTLLIB_CRYPTO_TKIP [=m] && STAGING [=y] && RTLLIB [=m]
  - RTLLIB_CRYPTO_WEP [=m] && STAGING [=y] && RTLLIB [=m]

This is because RTLLIB_CRYPTO_TKIP selects CRYPTO_MICHAEL_MIC and
CRYPTO_LIB_ARC4, without depending on or selecting CRYPTO,
despite those config options being subordinate to CRYPTO.

Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Link: https://lore.kernel.org/r/20210222180607.399753-1-julianbraha@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
staging: rtl8192e: Fix possible buffer overflow in _rtl92e_wx_set_scan 2021-03-17T16:11:40+00:00 Lee Gibson leegib@gmail.com 2021-02-26T14:51:57+00:00 3ff08f7339b7ca8d639fbc9d750a70a09684d62b commit 8687bf9ef9551bcf93897e33364d121667b1aadf upstream. Function _rtl92e_wx_set_scan calls memcpy without checking the length. A user could control that length and trigger a buffer overflow. Fix by checking the length is within the maximum allowed size. Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Lee Gibson <leegib@gmail.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210226145157.424065-1-leegib@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 8687bf9ef9551bcf93897e33364d121667b1aadf upstream.

Function _rtl92e_wx_set_scan calls memcpy without checking the length.
A user could control that length and trigger a buffer overflow.
Fix by checking the length is within the maximum allowed size.

Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Lee Gibson <leegib@gmail.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210226145157.424065-1-leegib@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: rtl8192e: Braces should be used on all arms of statement 2020-11-13T14:34:07+00:00 Eduard Vintila eduard.vintila47@gmail.com 2020-11-09T20:20:16+00:00 8b5b1b81935d88673e23ddb633f02dc6c842829b Fixed a coding style issue by adding braces on all arms of an "if" statement. Signed-off-by: Eduard Vintila <eduard.vintila47@gmail.com> Link: https://lore.kernel.org/r/20201109202016.79329-1-eduard.vintila47@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Fixed a coding style issue by adding braces on all arms of an "if"
statement.

Signed-off-by: Eduard Vintila <eduard.vintila47@gmail.com>
Link: https://lore.kernel.org/r/20201109202016.79329-1-eduard.vintila47@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mm: remove kzfree() compatibility definition 2020-10-25T18:39:02+00:00 Eric Biggers ebiggers@google.com 2020-10-23T23:27:16+00:00 23224e45004ed84c8466fd1e8e5860f541187029 Commit 453431a54934 ("mm, treewide: rename kzfree() to kfree_sensitive()") renamed kzfree() to kfree_sensitive(), but it left a compatibility definition of kzfree() to avoid being too disruptive. Since then a few more instances of kzfree() have slipped in. Just get rid of them and remove the compatibility definition once and for all. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
Commit 453431a54934 ("mm, treewide: rename kzfree() to
kfree_sensitive()") renamed kzfree() to kfree_sensitive(),
but it left a compatibility definition of kzfree() to avoid
being too disruptive.

Since then a few more instances of kzfree() have slipped in.

Just get rid of them and remove the compatibility definition
once and for all.

Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge tag 'staging-5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging 2020-10-15T16:46:23+00:00 Linus Torvalds torvalds@linux-foundation.org 2020-10-15T16:46:23+00:00 ade7afe3e606f9f6ff0e6deefce140157f75540b Pull staging / IIO driver updates from Greg KH: "Here is the large set of staging and IIO driver updates for 5.10-rc1. Included in here are: - new IIO drivers - new IIO driver frameworks - various IIO driver fixes and updates - IIO device tree conversions to yaml - so many minor staging driver coding style cleanups - most cdev driver moved out of staging - no staging drivers added or removed Full details are in the shortlog. All of these have been in linux-next for a while with no reported issues" * tag 'staging-5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (476 commits) staging: comedi: check validity of wMaxPacketSize of usb endpoints found staging: wfx: improve robustness of wfx_get_hw_rate() staging: wfx: drop unicode characters from strings staging: wfx: gpiod_get_value() can return an error staging: wfx: increase robustness of hif_generic_confirm() staging: wfx: wfx_init_common() returns NULL on error staging: wfx: standardize the error when vif does not exist staging: wfx: check memory allocation staging: wfx: improve error handling of hif_join() staging: dpaa2-switch: add a dpaa2_switch prefix to all functions in ethsw.c staging: dpaa2-switch: add a dpaa2_switch_ prefix to all functions in ethsw-ethtool.c staging: rtl8188eu: Fix long lines dt-bindings: staging: wfx: silabs,wfx yaml conversion staging: wfx: update copyrights dates staging: wfx: fix QoS priority for slow buses staging: wfx: fix BA sessions for older firmwares staging: wfx: remove remaining code of 'secure link' feature staging: wfx: fix handling of MMIC error staging: vchiq: Fix list_for_each exit tests staging: greybus: use __force when assigning __u8 value to snd_ctl_elem_type_t ... 
Pull staging / IIO driver updates from Greg KH:
 "Here is the large set of staging and IIO driver updates for 5.10-rc1.

  Included in here are:

   - new IIO drivers

   - new IIO driver frameworks

   - various IIO driver fixes and updates

   - IIO device tree conversions to yaml

   - so many minor staging driver coding style cleanups

   - most cdev driver moved out of staging

   - no staging drivers added or removed

  Full details are in the shortlog.

  All of these have been in linux-next for a while with no reported
  issues"

* tag 'staging-5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (476 commits)
  staging: comedi: check validity of wMaxPacketSize of usb endpoints found
  staging: wfx: improve robustness of wfx_get_hw_rate()
  staging: wfx: drop unicode characters from strings
  staging: wfx: gpiod_get_value() can return an error
  staging: wfx: increase robustness of hif_generic_confirm()
  staging: wfx: wfx_init_common() returns NULL on error
  staging: wfx: standardize the error when vif does not exist
  staging: wfx: check memory allocation
  staging: wfx: improve error handling of hif_join()
  staging: dpaa2-switch: add a dpaa2_switch prefix to all functions in ethsw.c
  staging: dpaa2-switch: add a dpaa2_switch_ prefix to all functions in ethsw-ethtool.c
  staging: rtl8188eu: Fix long lines
  dt-bindings: staging: wfx: silabs,wfx yaml conversion
  staging: wfx: update copyrights dates
  staging: wfx: fix QoS priority for slow buses
  staging: wfx: fix BA sessions for older firmwares
  staging: wfx: remove remaining code of 'secure link' feature
  staging: wfx: fix handling of MMIC error
  staging: vchiq: Fix list_for_each exit tests
  staging: greybus: use __force when assigning __u8 value to snd_ctl_elem_type_t
  ...
Revert "staging: rtl8192e: fix kconfig dependency warning for RTLLIB_CRYPTO_WEP" 2020-09-20T14:00:19+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2020-09-20T14:00:19+00:00 93b61540dfa56b2385ec188a29615e062cd571be This reverts commit 02c4260713d62eff0875ca4a47019cd56371ffa7 as it conflicts with a change and fix coming in through the crypto tree as reported by Stephen and Herbert. Cc: Necip Fazil Yildiran <fazilyildiran@gmail.com> Fixes: 02c4260713d6 ("staging: rtl8192e: fix kconfig dependency warning for RTLLIB_CRYPTO_WEP") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reported-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This reverts commit 02c4260713d62eff0875ca4a47019cd56371ffa7 as it
conflicts with a change and fix coming in through the crypto tree as
reported by Stephen and Herbert.

Cc: Necip Fazil Yildiran <fazilyildiran@gmail.com>
Fixes: 02c4260713d6 ("staging: rtl8192e: fix kconfig dependency warning for RTLLIB_CRYPTO_WEP")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reported-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert "staging: rtl8192e: fix kconfig dependency warning for RTLLIB_CRYPTO_TKIP" 2020-09-20T13:58:39+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2020-09-20T13:58:39+00:00 a0a94cc7b0bc05b7ec3cb13f062fde96476e3ccd This reverts commit 243d040a6e4ae95408e133269dd72be2ba03dd48 as it conflicts with a change and fix coming in through the crypto tree as reported by Stephen and Herbert. Cc: Necip Fazil Yildiran <fazilyildiran@gmail.com> Fixes: 243d040a6e4a ("staging: rtl8192e: fix kconfig dependency warning for RTLLIB_CRYPTO_TKIP") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reported-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This reverts commit 243d040a6e4ae95408e133269dd72be2ba03dd48 as it
conflicts with a change and fix coming in through the crypto tree as
reported by Stephen and Herbert.

Cc: Necip Fazil Yildiran <fazilyildiran@gmail.com>
Fixes: 243d040a6e4a ("staging: rtl8192e: fix kconfig dependency warning for RTLLIB_CRYPTO_TKIP")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reported-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: rtl8192e: fix kconfig dependency warning for RTLLIB_CRYPTO_WEP 2020-09-16T11:13:00+00:00 Necip Fazil Yildiran fazilyildiran@gmail.com 2020-09-15T09:42:10+00:00 02c4260713d62eff0875ca4a47019cd56371ffa7 When RTLLIB_CRYPTO_WEP is enabled and CRYPTO is disabled, it results in the following Kbuild warning: WARNING: unmet direct dependencies detected for CRYPTO_ARC4 Depends on [n]: CRYPTO [=n] Selected by [m]: - RTLLIB_CRYPTO_WEP [=m] && STAGING [=y] && RTLLIB [=m] The reason is that RTLLIB_CRYPTO_WEP selects CRYPTO_ARC4 without depending on or selecting CRYPTO while CRYPTO_ARC4 is subordinate to CRYPTO. Honor the kconfig menu hierarchy to remove kconfig dependency warnings. Fixes: e0e3daddad36 ("staging: r8192e: Fix possible error in configuration") Signed-off-by: Necip Fazil Yildiran <fazilyildiran@gmail.com> Link: https://lore.kernel.org/r/20200915094209.22664-1-fazilyildiran@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
When RTLLIB_CRYPTO_WEP is enabled and CRYPTO is disabled, it results in
the following Kbuild warning:

WARNING: unmet direct dependencies detected for CRYPTO_ARC4
  Depends on [n]: CRYPTO [=n]
  Selected by [m]:
  - RTLLIB_CRYPTO_WEP [=m] && STAGING [=y] && RTLLIB [=m]

The reason is that RTLLIB_CRYPTO_WEP selects CRYPTO_ARC4 without depending
on or selecting CRYPTO while CRYPTO_ARC4 is subordinate to CRYPTO.

Honor the kconfig menu hierarchy to remove kconfig dependency warnings.

Fixes: e0e3daddad36 ("staging: r8192e: Fix possible error in configuration")
Signed-off-by: Necip Fazil Yildiran <fazilyildiran@gmail.com>
Link: https://lore.kernel.org/r/20200915094209.22664-1-fazilyildiran@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>