From: Greg Kroah-Hartman Date: Mon, 24 Jun 2019 09:07:43 +0000 (+0800) Subject: 4.14-stable patches X-Git-Tag: v5.1.15~14 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=bb48b19a03e10e7b0fd445739231f6745f9836b8;p=thirdparty%2Fkernel%2Fstable-queue.git 4.14-stable patches added patches: bluetooth-align-minimum-encryption-key-size-for-le-and-br-edr-connections.patch bluetooth-fix-regression-with-minimum-encryption-key-size-alignment.patch cfg80211-fix-memory-leak-of-wiphy-device-name.patch mac80211-do-not-use-stack-memory-with-scatterlist-for-gmac.patch mac80211-drop-robust-management-frames-from-unknown-ta.patch mac80211-handle-deauthentication-disassociation-from-tdls-peer.patch smb3-retry-on-status_insufficient_resources-instead-of-failing-write.patch --- diff --git a/queue-4.14/bluetooth-align-minimum-encryption-key-size-for-le-and-br-edr-connections.patch b/queue-4.14/bluetooth-align-minimum-encryption-key-size-for-le-and-br-edr-connections.patch new file mode 100644 index 00000000000..ec46f474803 --- /dev/null +++ b/queue-4.14/bluetooth-align-minimum-encryption-key-size-for-le-and-br-edr-connections.patch @@ -0,0 +1,52 @@ +From d5bb334a8e171b262e48f378bd2096c0ea458265 Mon Sep 17 00:00:00 2001 +From: Marcel Holtmann +Date: Wed, 24 Apr 2019 22:19:17 +0200 +Subject: Bluetooth: Align minimum encryption key size for LE and BR/EDR connections + +From: Marcel Holtmann + +commit d5bb334a8e171b262e48f378bd2096c0ea458265 upstream. + +The minimum encryption key size for LE connections is 56 bits and to +align LE with BR/EDR, enforce 56 bits of minimum encryption key size for +BR/EDR connections as well. + +Signed-off-by: Marcel Holtmann +Signed-off-by: Johan Hedberg +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + include/net/bluetooth/hci_core.h | 3 +++ + net/bluetooth/hci_conn.c | 8 ++++++++ + 2 files changed, 11 insertions(+) + +--- a/include/net/bluetooth/hci_core.h ++++ b/include/net/bluetooth/hci_core.h +@@ -178,6 +178,9 @@ struct adv_info { + + #define HCI_MAX_SHORT_NAME_LENGTH 10 + ++/* Min encryption key size to match with SMP */ ++#define HCI_MIN_ENC_KEY_SIZE 7 ++ + /* Default LE RPA expiry time, 15 minutes */ + #define HCI_DEFAULT_RPA_TIMEOUT (15 * 60) + +--- a/net/bluetooth/hci_conn.c ++++ b/net/bluetooth/hci_conn.c +@@ -1165,6 +1165,14 @@ int hci_conn_check_link_mode(struct hci_ + !test_bit(HCI_CONN_ENCRYPT, &conn->flags)) + return 0; + ++ /* The minimum encryption key size needs to be enforced by the ++ * host stack before establishing any L2CAP connections. The ++ * specification in theory allows a minimum of 1, but to align ++ * BR/EDR and LE transports, a minimum of 7 is chosen. ++ */ ++ if (conn->enc_key_size < HCI_MIN_ENC_KEY_SIZE) ++ return 0; ++ + return 1; + } + diff --git a/queue-4.14/bluetooth-fix-regression-with-minimum-encryption-key-size-alignment.patch b/queue-4.14/bluetooth-fix-regression-with-minimum-encryption-key-size-alignment.patch new file mode 100644 index 00000000000..f681bb7537c --- /dev/null +++ b/queue-4.14/bluetooth-fix-regression-with-minimum-encryption-key-size-alignment.patch @@ -0,0 +1,148 @@ +From 693cd8ce3f882524a5d06f7800dd8492411877b3 Mon Sep 17 00:00:00 2001 +From: Marcel Holtmann +Date: Sat, 22 Jun 2019 15:47:01 +0200 +Subject: Bluetooth: Fix regression with minimum encryption key size alignment + +From: Marcel Holtmann + +commit 693cd8ce3f882524a5d06f7800dd8492411877b3 upstream. + +When trying to align the minimum encryption key size requirement for +Bluetooth connections, it turns out doing this in a central location in +the HCI connection handling code is not possible. + +Original Bluetooth version up to 2.0 used a security model where the +L2CAP service would enforce authentication and encryption. Starting +with Bluetooth 2.1 and Secure Simple Pairing that model has changed into +that the connection initiator is responsible for providing an encrypted +ACL link before any L2CAP communication can happen. + +Now connecting Bluetooth 2.1 or later devices with Bluetooth 2.0 and +before devices are causing a regression. The encryption key size check +needs to be moved out of the HCI connection handling into the L2CAP +channel setup. + +To achieve this, the current check inside hci_conn_security() has been +moved into l2cap_check_enc_key_size() helper function and then called +from four decisions point inside L2CAP to cover all combinations of +Secure Simple Pairing enabled devices and device using legacy pairing +and legacy service security model. + +Fixes: d5bb334a8e17 ("Bluetooth: Align minimum encryption key size for LE and BR/EDR connections") +Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203643 +Signed-off-by: Marcel Holtmann +Cc: stable@vger.kernel.org +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + net/bluetooth/hci_conn.c | 18 +++++++++--------- + net/bluetooth/l2cap_core.c | 33 ++++++++++++++++++++++++++++----- + 2 files changed, 37 insertions(+), 14 deletions(-) + +--- a/net/bluetooth/hci_conn.c ++++ b/net/bluetooth/hci_conn.c +@@ -1165,14 +1165,6 @@ int hci_conn_check_link_mode(struct hci_ + !test_bit(HCI_CONN_ENCRYPT, &conn->flags)) + return 0; + +- /* The minimum encryption key size needs to be enforced by the +- * host stack before establishing any L2CAP connections. The +- * specification in theory allows a minimum of 1, but to align +- * BR/EDR and LE transports, a minimum of 7 is chosen. +- */ +- if (conn->enc_key_size < HCI_MIN_ENC_KEY_SIZE) +- return 0; +- + return 1; + } + +@@ -1289,8 +1281,16 @@ auth: + return 0; + + encrypt: +- if (test_bit(HCI_CONN_ENCRYPT, &conn->flags)) ++ if (test_bit(HCI_CONN_ENCRYPT, &conn->flags)) { ++ /* Ensure that the encryption key size has been read, ++ * otherwise stall the upper layer responses. ++ */ ++ if (!conn->enc_key_size) ++ return 0; ++ ++ /* Nothing else needed, all requirements are met */ + return 1; ++ } + + hci_conn_encrypt(conn); + return 0; +--- a/net/bluetooth/l2cap_core.c ++++ b/net/bluetooth/l2cap_core.c +@@ -1340,6 +1340,21 @@ static void l2cap_request_info(struct l2 + sizeof(req), &req); + } + ++static bool l2cap_check_enc_key_size(struct hci_conn *hcon) ++{ ++ /* The minimum encryption key size needs to be enforced by the ++ * host stack before establishing any L2CAP connections. The ++ * specification in theory allows a minimum of 1, but to align ++ * BR/EDR and LE transports, a minimum of 7 is chosen. ++ * ++ * This check might also be called for unencrypted connections ++ * that have no key size requirements. Ensure that the link is ++ * actually encrypted before enforcing a key size. ++ */ ++ return (!test_bit(HCI_CONN_ENCRYPT, &hcon->flags) || ++ hcon->enc_key_size > HCI_MIN_ENC_KEY_SIZE); ++} ++ + static void l2cap_do_start(struct l2cap_chan *chan) + { + struct l2cap_conn *conn = chan->conn; +@@ -1357,9 +1372,14 @@ static void l2cap_do_start(struct l2cap_ + if (!(conn->info_state & L2CAP_INFO_FEAT_MASK_REQ_DONE)) + return; + +- if (l2cap_chan_check_security(chan, true) && +- __l2cap_no_conn_pending(chan)) ++ if (!l2cap_chan_check_security(chan, true) || ++ !__l2cap_no_conn_pending(chan)) ++ return; ++ ++ if (l2cap_check_enc_key_size(conn->hcon)) + l2cap_start_connection(chan); ++ else ++ __set_chan_timer(chan, L2CAP_DISC_TIMEOUT); + } + + static inline int l2cap_mode_supported(__u8 mode, __u32 feat_mask) +@@ -1438,7 +1458,10 @@ static void l2cap_conn_start(struct l2ca + continue; + } + +- l2cap_start_connection(chan); ++ if (l2cap_check_enc_key_size(conn->hcon)) ++ l2cap_start_connection(chan); ++ else ++ l2cap_chan_close(chan, ECONNREFUSED); + + } else if (chan->state == BT_CONNECT2) { + struct l2cap_conn_rsp rsp; +@@ -7455,7 +7478,7 @@ static void l2cap_security_cfm(struct hc + } + + if (chan->state == BT_CONNECT) { +- if (!status) ++ if (!status && l2cap_check_enc_key_size(hcon)) + l2cap_start_connection(chan); + else + __set_chan_timer(chan, L2CAP_DISC_TIMEOUT); +@@ -7464,7 +7487,7 @@ static void l2cap_security_cfm(struct hc + struct l2cap_conn_rsp rsp; + __u16 res, stat; + +- if (!status) { ++ if (!status && l2cap_check_enc_key_size(hcon)) { + if (test_bit(FLAG_DEFER_SETUP, &chan->flags)) { + res = L2CAP_CR_PEND; + stat = L2CAP_CS_AUTHOR_PEND; diff --git a/queue-4.14/cfg80211-fix-memory-leak-of-wiphy-device-name.patch b/queue-4.14/cfg80211-fix-memory-leak-of-wiphy-device-name.patch new file mode 100644 index 00000000000..595ceb8f06d --- /dev/null +++ b/queue-4.14/cfg80211-fix-memory-leak-of-wiphy-device-name.patch @@ -0,0 +1,35 @@ +From 4f488fbca2a86cc7714a128952eead92cac279ab Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Mon, 10 Jun 2019 13:02:19 -0700 +Subject: cfg80211: fix memory leak of wiphy device name + +From: Eric Biggers + +commit 4f488fbca2a86cc7714a128952eead92cac279ab upstream. + +In wiphy_new_nm(), if an error occurs after dev_set_name() and +device_initialize() have already been called, it's necessary to call +put_device() (via wiphy_free()) to avoid a memory leak. + +Reported-by: syzbot+7fddca22578bc67c3fe4@syzkaller.appspotmail.com +Fixes: 1f87f7d3a3b4 ("cfg80211: add rfkill support") +Cc: stable@vger.kernel.org +Signed-off-by: Eric Biggers +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman + +--- + net/wireless/core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/net/wireless/core.c ++++ b/net/wireless/core.c +@@ -498,7 +498,7 @@ use_default_name: + &rdev->rfkill_ops, rdev); + + if (!rdev->rfkill) { +- kfree(rdev); ++ wiphy_free(&rdev->wiphy); + return NULL; + } + diff --git a/queue-4.14/mac80211-do-not-use-stack-memory-with-scatterlist-for-gmac.patch b/queue-4.14/mac80211-do-not-use-stack-memory-with-scatterlist-for-gmac.patch new file mode 100644 index 00000000000..cfd9ffd557c --- /dev/null +++ b/queue-4.14/mac80211-do-not-use-stack-memory-with-scatterlist-for-gmac.patch @@ -0,0 +1,60 @@ +From a71fd9dac23613d96ba3c05619a8ef4fd6cdf9b9 Mon Sep 17 00:00:00 2001 +From: Jouni Malinen +Date: Tue, 28 May 2019 01:46:43 +0300 +Subject: mac80211: Do not use stack memory with scatterlist for GMAC + +From: Jouni Malinen + +commit a71fd9dac23613d96ba3c05619a8ef4fd6cdf9b9 upstream. + +ieee80211_aes_gmac() uses the mic argument directly in sg_set_buf() and +that does not allow use of stack memory (e.g., BUG_ON() is hit in +sg_set_buf() with CONFIG_DEBUG_SG). BIP GMAC TX side is fine for this +since it can use the skb data buffer, but the RX side was using a stack +variable for deriving the local MIC value to compare against the +received one. + +Fix this by allocating heap memory for the mic buffer. + +This was found with hwsim test case ap_cipher_bip_gmac_128 hitting that +BUG_ON() and kernel panic. + +Cc: stable@vger.kernel.org +Signed-off-by: Jouni Malinen +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman + +--- + net/mac80211/wpa.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/net/mac80211/wpa.c ++++ b/net/mac80211/wpa.c +@@ -1169,7 +1169,7 @@ ieee80211_crypto_aes_gmac_decrypt(struct + struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(skb); + struct ieee80211_key *key = rx->key; + struct ieee80211_mmie_16 *mmie; +- u8 aad[GMAC_AAD_LEN], mic[GMAC_MIC_LEN], ipn[6], nonce[GMAC_NONCE_LEN]; ++ u8 aad[GMAC_AAD_LEN], *mic, ipn[6], nonce[GMAC_NONCE_LEN]; + struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data; + + if (!ieee80211_is_mgmt(hdr->frame_control)) +@@ -1200,13 +1200,18 @@ ieee80211_crypto_aes_gmac_decrypt(struct + memcpy(nonce, hdr->addr2, ETH_ALEN); + memcpy(nonce + ETH_ALEN, ipn, 6); + ++ mic = kmalloc(GMAC_MIC_LEN, GFP_ATOMIC); ++ if (!mic) ++ return RX_DROP_UNUSABLE; + if (ieee80211_aes_gmac(key->u.aes_gmac.tfm, aad, nonce, + skb->data + 24, skb->len - 24, + mic) < 0 || + crypto_memneq(mic, mmie->mic, sizeof(mmie->mic))) { + key->u.aes_gmac.icverrors++; ++ kfree(mic); + return RX_DROP_UNUSABLE; + } ++ kfree(mic); + } + + memcpy(key->u.aes_gmac.rx_pn, ipn, 6); diff --git a/queue-4.14/mac80211-drop-robust-management-frames-from-unknown-ta.patch b/queue-4.14/mac80211-drop-robust-management-frames-from-unknown-ta.patch new file mode 100644 index 00000000000..5d53e41cb47 --- /dev/null +++ b/queue-4.14/mac80211-drop-robust-management-frames-from-unknown-ta.patch @@ -0,0 +1,32 @@ +From 588f7d39b3592a36fb7702ae3b8bdd9be4621e2f Mon Sep 17 00:00:00 2001 +From: Johannes Berg +Date: Wed, 13 Feb 2019 15:13:30 +0100 +Subject: mac80211: drop robust management frames from unknown TA + +From: Johannes Berg + +commit 588f7d39b3592a36fb7702ae3b8bdd9be4621e2f upstream. + +When receiving a robust management frame, drop it if we don't have +rx->sta since then we don't have a security association and thus +couldn't possibly validate the frame. + +Cc: stable@vger.kernel.org +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman + +--- + net/mac80211/rx.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/net/mac80211/rx.c ++++ b/net/mac80211/rx.c +@@ -3589,6 +3589,8 @@ static bool ieee80211_accept_frame(struc + case NL80211_IFTYPE_STATION: + if (!bssid && !sdata->u.mgd.use_4addr) + return false; ++ if (ieee80211_is_robust_mgmt_frame(skb) && !rx->sta) ++ return false; + if (multicast) + return true; + return ether_addr_equal(sdata->vif.addr, hdr->addr1); diff --git a/queue-4.14/mac80211-handle-deauthentication-disassociation-from-tdls-peer.patch b/queue-4.14/mac80211-handle-deauthentication-disassociation-from-tdls-peer.patch new file mode 100644 index 00000000000..365f2ee6a00 --- /dev/null +++ b/queue-4.14/mac80211-handle-deauthentication-disassociation-from-tdls-peer.patch @@ -0,0 +1,117 @@ +From 79c92ca42b5a3e0ea172ea2ce8df8e125af237da Mon Sep 17 00:00:00 2001 +From: Yu Wang +Date: Fri, 10 May 2019 17:04:52 +0800 +Subject: mac80211: handle deauthentication/disassociation from TDLS peer + +From: Yu Wang + +commit 79c92ca42b5a3e0ea172ea2ce8df8e125af237da upstream. + +When receiving a deauthentication/disassociation frame from a TDLS +peer, a station should not disconnect the current AP, but only +disable the current TDLS link if it's enabled. + +Without this change, a TDLS issue can be reproduced by following the +steps as below: + +1. STA-1 and STA-2 are connected to AP, bidirection traffic is running + between STA-1 and STA-2. +2. Set up TDLS link between STA-1 and STA-2, stay for a while, then + teardown TDLS link. +3. Repeat step #2 and monitor the connection between STA and AP. + +During the test, one STA may send a deauthentication/disassociation +frame to another, after TDLS teardown, with reason code 6/7, which +means: Class 2/3 frame received from nonassociated STA. + +On receive this frame, the receiver STA will disconnect the current +AP and then reconnect. It's not a expected behavior, purpose of this +frame should be disabling the TDLS link, not the link with AP. + +Cc: stable@vger.kernel.org +Signed-off-by: Yu Wang +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman + +--- + net/mac80211/ieee80211_i.h | 3 +++ + net/mac80211/mlme.c | 12 +++++++++++- + net/mac80211/tdls.c | 23 +++++++++++++++++++++++ + 3 files changed, 37 insertions(+), 1 deletion(-) + +--- a/net/mac80211/ieee80211_i.h ++++ b/net/mac80211/ieee80211_i.h +@@ -2150,6 +2150,9 @@ void ieee80211_tdls_cancel_channel_switc + const u8 *addr); + void ieee80211_teardown_tdls_peers(struct ieee80211_sub_if_data *sdata); + void ieee80211_tdls_chsw_work(struct work_struct *wk); ++void ieee80211_tdls_handle_disconnect(struct ieee80211_sub_if_data *sdata, ++ const u8 *peer, u16 reason); ++const char *ieee80211_get_reason_code_string(u16 reason_code); + + extern const struct ethtool_ops ieee80211_ethtool_ops; + +--- a/net/mac80211/mlme.c ++++ b/net/mac80211/mlme.c +@@ -2744,7 +2744,7 @@ static void ieee80211_rx_mgmt_auth(struc + #define case_WLAN(type) \ + case WLAN_REASON_##type: return #type + +-static const char *ieee80211_get_reason_code_string(u16 reason_code) ++const char *ieee80211_get_reason_code_string(u16 reason_code) + { + switch (reason_code) { + case_WLAN(UNSPECIFIED); +@@ -2809,6 +2809,11 @@ static void ieee80211_rx_mgmt_deauth(str + if (len < 24 + 2) + return; + ++ if (!ether_addr_equal(mgmt->bssid, mgmt->sa)) { ++ ieee80211_tdls_handle_disconnect(sdata, mgmt->sa, reason_code); ++ return; ++ } ++ + if (ifmgd->associated && + ether_addr_equal(mgmt->bssid, ifmgd->associated->bssid)) { + const u8 *bssid = ifmgd->associated->bssid; +@@ -2858,6 +2863,11 @@ static void ieee80211_rx_mgmt_disassoc(s + + reason_code = le16_to_cpu(mgmt->u.disassoc.reason_code); + ++ if (!ether_addr_equal(mgmt->bssid, mgmt->sa)) { ++ ieee80211_tdls_handle_disconnect(sdata, mgmt->sa, reason_code); ++ return; ++ } ++ + sdata_info(sdata, "disassociated from %pM (Reason: %u=%s)\n", + mgmt->sa, reason_code, + ieee80211_get_reason_code_string(reason_code)); +--- a/net/mac80211/tdls.c ++++ b/net/mac80211/tdls.c +@@ -1988,3 +1988,26 @@ void ieee80211_tdls_chsw_work(struct wor + } + rtnl_unlock(); + } ++ ++void ieee80211_tdls_handle_disconnect(struct ieee80211_sub_if_data *sdata, ++ const u8 *peer, u16 reason) ++{ ++ struct ieee80211_sta *sta; ++ ++ rcu_read_lock(); ++ sta = ieee80211_find_sta(&sdata->vif, peer); ++ if (!sta || !sta->tdls) { ++ rcu_read_unlock(); ++ return; ++ } ++ rcu_read_unlock(); ++ ++ tdls_dbg(sdata, "disconnected from TDLS peer %pM (Reason: %u=%s)\n", ++ peer, reason, ++ ieee80211_get_reason_code_string(reason)); ++ ++ ieee80211_tdls_oper_request(&sdata->vif, peer, ++ NL80211_TDLS_TEARDOWN, ++ WLAN_REASON_TDLS_TEARDOWN_UNREACHABLE, ++ GFP_ATOMIC); ++} diff --git a/queue-4.14/series b/queue-4.14/series index c8334f5080b..e7c38db10bd 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -42,3 +42,10 @@ can-purge-socket-error-queue-on-sock-destruct.patch powerpc-bpf-use-unsigned-division-instruction-for-64-bit-operations.patch arm-imx-cpuidle-imx6sx-restrict-the-sw2iso-increase-to-i.mx6sx.patch arm-dts-am57xx-idk-remove-support-for-voltage-switching-for-sd-card.patch +bluetooth-align-minimum-encryption-key-size-for-le-and-br-edr-connections.patch +bluetooth-fix-regression-with-minimum-encryption-key-size-alignment.patch +smb3-retry-on-status_insufficient_resources-instead-of-failing-write.patch +cfg80211-fix-memory-leak-of-wiphy-device-name.patch +mac80211-drop-robust-management-frames-from-unknown-ta.patch +mac80211-handle-deauthentication-disassociation-from-tdls-peer.patch +mac80211-do-not-use-stack-memory-with-scatterlist-for-gmac.patch diff --git a/queue-4.14/smb3-retry-on-status_insufficient_resources-instead-of-failing-write.patch b/queue-4.14/smb3-retry-on-status_insufficient_resources-instead-of-failing-write.patch new file mode 100644 index 00000000000..bfec22a9cd5 --- /dev/null +++ b/queue-4.14/smb3-retry-on-status_insufficient_resources-instead-of-failing-write.patch @@ -0,0 +1,37 @@ +From 8d526d62db907e786fd88948c75d1833d82bd80e Mon Sep 17 00:00:00 2001 +From: Steve French +Date: Mon, 17 Jun 2019 14:49:07 -0500 +Subject: SMB3: retry on STATUS_INSUFFICIENT_RESOURCES instead of failing write + +From: Steve French + +commit 8d526d62db907e786fd88948c75d1833d82bd80e upstream. + +Some servers such as Windows 10 will return STATUS_INSUFFICIENT_RESOURCES +as the number of simultaneous SMB3 requests grows (even though the client +has sufficient credits). Return EAGAIN on STATUS_INSUFFICIENT_RESOURCES +so that we can retry writes which fail with this status code. + +This (for example) fixes large file copies to Windows 10 on fast networks. + +Signed-off-by: Steve French +CC: Stable +Reviewed-by: Ronnie Sahlberg +Reviewed-by: Pavel Shilovsky +Signed-off-by: Greg Kroah-Hartman + +--- + fs/cifs/smb2maperror.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/cifs/smb2maperror.c ++++ b/fs/cifs/smb2maperror.c +@@ -456,7 +456,7 @@ static const struct status_to_posix_erro + {STATUS_FILE_INVALID, -EIO, "STATUS_FILE_INVALID"}, + {STATUS_ALLOTTED_SPACE_EXCEEDED, -EIO, + "STATUS_ALLOTTED_SPACE_EXCEEDED"}, +- {STATUS_INSUFFICIENT_RESOURCES, -EREMOTEIO, ++ {STATUS_INSUFFICIENT_RESOURCES, -EAGAIN, + "STATUS_INSUFFICIENT_RESOURCES"}, + {STATUS_DFS_EXIT_PATH_FOUND, -EIO, "STATUS_DFS_EXIT_PATH_FOUND"}, + {STATUS_DEVICE_DATA_ERROR, -EIO, "STATUS_DEVICE_DATA_ERROR"},