From: Greg Kroah-Hartman Date: Fri, 5 Apr 2024 07:27:42 +0000 (+0200) Subject: 6.1-stable patches X-Git-Tag: v5.15.154~112 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=2c86f9663f643695c41152acfb536cc8d626a7fc;p=thirdparty%2Fkernel%2Fstable-queue.git 6.1-stable patches added patches: arm64-dts-qcom-sc7180-trogdor-mark-bluetooth-address-as-broken.patch bluetooth-add-quirk-for-broken-address-properties.patch bluetooth-fix-toctou-in-hci-debugfs-implementation.patch bluetooth-hci_event-set-the-conn-encrypted-before-conn-establishes.patch bluetooth-qca-fix-device-address-endianness.patch kvm-arm64-fix-host-programmed-guest-events-in-nvhe.patch net-rds-fix-possible-cp-null-dereference.patch net-usb-ax88179_178a-avoid-the-interface-always-configured-as-random-address.patch r8169-fix-issue-caused-by-buggy-bios-on-certain-boards-with-rtl8168d.patch revert-bluetooth-hci_qca-set-bda-quirk-bit-if-fwnode-exists-in-dt.patch vsock-virtio-fix-packet-delivery-to-tap-device.patch x86-cpufeatures-add-cpuid_lnx_5-to-track-recently-added-linux-defined-word.patch xen-netfront-add-missing-skb_mark_for_recycle.patch --- diff --git a/queue-6.1/arm64-dts-qcom-sc7180-trogdor-mark-bluetooth-address-as-broken.patch b/queue-6.1/arm64-dts-qcom-sc7180-trogdor-mark-bluetooth-address-as-broken.patch new file mode 100644 index 00000000000..4f13dca56f6 --- /dev/null +++ b/queue-6.1/arm64-dts-qcom-sc7180-trogdor-mark-bluetooth-address-as-broken.patch @@ -0,0 +1,50 @@ +From e12e28009e584c8f8363439f6a928ec86278a106 Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Wed, 20 Mar 2024 08:55:52 +0100 +Subject: arm64: dts: qcom: sc7180-trogdor: mark bluetooth address as broken + +From: Johan Hovold + +commit e12e28009e584c8f8363439f6a928ec86278a106 upstream. + +Several Qualcomm Bluetooth controllers lack persistent storage for the +device address and instead one can be provided by the boot firmware +using the 'local-bd-address' devicetree property. + +The Bluetooth bindings clearly states that the address should be +specified in little-endian order, but due to a long-standing bug in the +Qualcomm driver which reversed the address some boot firmware has been +providing the address in big-endian order instead. + +The boot firmware in SC7180 Trogdor Chromebooks is known to be affected +so mark the 'local-bd-address' property as broken to maintain backwards +compatibility with older firmware when fixing the underlying driver bug. + +Note that ChromeOS always updates the kernel and devicetree in lockstep +so that there is no need to handle backwards compatibility with older +devicetrees. + +Fixes: 7ec3e67307f8 ("arm64: dts: qcom: sc7180-trogdor: add initial trogdor and lazor dt") +Cc: stable@vger.kernel.org # 5.10 +Cc: Rob Clark +Reviewed-by: Douglas Anderson +Signed-off-by: Johan Hovold +Acked-by: Bjorn Andersson +Reviewed-by: Bjorn Andersson +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi ++++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi +@@ -923,6 +923,8 @@ ap_spi_fp: &spi10 { + vddrf-supply = <&pp1300_l2c>; + vddch0-supply = <&pp3300_l10c>; + max-speed = <3200000>; ++ ++ qcom,local-bd-address-broken; + }; + }; + diff --git a/queue-6.1/bluetooth-add-quirk-for-broken-address-properties.patch b/queue-6.1/bluetooth-add-quirk-for-broken-address-properties.patch new file mode 100644 index 00000000000..c28b3a2951b --- /dev/null +++ b/queue-6.1/bluetooth-add-quirk-for-broken-address-properties.patch @@ -0,0 +1,65 @@ +From 39646f29b100566451d37abc4cc8cdd583756dfe Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Wed, 20 Mar 2024 08:55:53 +0100 +Subject: Bluetooth: add quirk for broken address properties + +From: Johan Hovold + +commit 39646f29b100566451d37abc4cc8cdd583756dfe upstream. + +Some Bluetooth controllers lack persistent storage for the device +address and instead one can be provided by the boot firmware using the +'local-bd-address' devicetree property. + +The Bluetooth devicetree bindings clearly states that the address should +be specified in little-endian order, but due to a long-standing bug in +the Qualcomm driver which reversed the address some boot firmware has +been providing the address in big-endian order instead. + +Add a new quirk that can be set on platforms with broken firmware and +use it to reverse the address when parsing the property so that the +underlying driver bug can be fixed. + +Fixes: 5c0a1001c8be ("Bluetooth: hci_qca: Add helper to set device address") +Cc: stable@vger.kernel.org # 5.1 +Reviewed-by: Douglas Anderson +Signed-off-by: Johan Hovold +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Greg Kroah-Hartman +--- + include/net/bluetooth/hci.h | 9 +++++++++ + net/bluetooth/hci_sync.c | 5 ++++- + 2 files changed, 13 insertions(+), 1 deletion(-) + +--- a/include/net/bluetooth/hci.h ++++ b/include/net/bluetooth/hci.h +@@ -175,6 +175,15 @@ enum { + */ + HCI_QUIRK_USE_BDADDR_PROPERTY, + ++ /* When this quirk is set, the Bluetooth Device Address provided by ++ * the 'local-bd-address' fwnode property is incorrectly specified in ++ * big-endian order. ++ * ++ * This quirk can be set before hci_register_dev is called or ++ * during the hdev->setup vendor callback. ++ */ ++ HCI_QUIRK_BDADDR_PROPERTY_BROKEN, ++ + /* When this quirk is set, the duplicate filtering during + * scanning is based on Bluetooth devices addresses. To allow + * RSSI based updates, restart scanning if needed. +--- a/net/bluetooth/hci_sync.c ++++ b/net/bluetooth/hci_sync.c +@@ -3293,7 +3293,10 @@ static void hci_dev_get_bd_addr_from_pro + if (ret < 0 || !bacmp(&ba, BDADDR_ANY)) + return; + +- bacpy(&hdev->public_addr, &ba); ++ if (test_bit(HCI_QUIRK_BDADDR_PROPERTY_BROKEN, &hdev->quirks)) ++ baswap(&hdev->public_addr, &ba); ++ else ++ bacpy(&hdev->public_addr, &ba); + } + + struct hci_init_stage { diff --git a/queue-6.1/bluetooth-fix-toctou-in-hci-debugfs-implementation.patch b/queue-6.1/bluetooth-fix-toctou-in-hci-debugfs-implementation.patch new file mode 100644 index 00000000000..c37f27c72f9 --- /dev/null +++ b/queue-6.1/bluetooth-fix-toctou-in-hci-debugfs-implementation.patch @@ -0,0 +1,192 @@ +From 7835fcfd132eb88b87e8eb901f88436f63ab60f7 Mon Sep 17 00:00:00 2001 +From: Bastien Nocera +Date: Wed, 27 Mar 2024 15:24:56 +0100 +Subject: Bluetooth: Fix TOCTOU in HCI debugfs implementation + +From: Bastien Nocera + +commit 7835fcfd132eb88b87e8eb901f88436f63ab60f7 upstream. + +struct hci_dev members conn_info_max_age, conn_info_min_age, +le_conn_max_interval, le_conn_min_interval, le_adv_max_interval, +and le_adv_min_interval can be modified from the HCI core code, as well +through debugfs. + +The debugfs implementation, that's only available to privileged users, +will check for boundaries, making sure that the minimum value being set +is strictly above the maximum value that already exists, and vice-versa. + +However, as both minimum and maximum values can be changed concurrently +to us modifying them, we need to make sure that the value we check is +the value we end up using. + +For example, with ->conn_info_max_age set to 10, conn_info_min_age_set() +gets called from vfs handlers to set conn_info_min_age to 8. + +In conn_info_min_age_set(), this goes through: + if (val == 0 || val > hdev->conn_info_max_age) + return -EINVAL; + +Concurrently, conn_info_max_age_set() gets called to set to set the +conn_info_max_age to 7: + if (val == 0 || val > hdev->conn_info_max_age) + return -EINVAL; +That check will also pass because we used the old value (10) for +conn_info_max_age. + +After those checks that both passed, the struct hci_dev access +is mutex-locked, disabling concurrent access, but that does not matter +because the invalid value checks both passed, and we'll end up with +conn_info_min_age = 8 and conn_info_max_age = 7 + +To fix this problem, we need to lock the structure access before so the +check and assignment are not interrupted. + +This fix was originally devised by the BassCheck[1] team, and +considered the problem to be an atomicity one. This isn't the case as +there aren't any concerns about the variable changing while we check it, +but rather after we check it parallel to another change. + +This patch fixes CVE-2024-24858 and CVE-2024-24857. + +[1] https://sites.google.com/view/basscheck/ + +Co-developed-by: Gui-Dong Han <2045gemini@gmail.com> +Signed-off-by: Gui-Dong Han <2045gemini@gmail.com> +Link: https://lore.kernel.org/linux-bluetooth/20231222161317.6255-1-2045gemini@gmail.com/ +Link: https://nvd.nist.gov/vuln/detail/CVE-2024-24858 +Link: https://lore.kernel.org/linux-bluetooth/20231222162931.6553-1-2045gemini@gmail.com/ +Link: https://lore.kernel.org/linux-bluetooth/20231222162310.6461-1-2045gemini@gmail.com/ +Link: https://nvd.nist.gov/vuln/detail/CVE-2024-24857 +Fixes: 31ad169148df ("Bluetooth: Add conn info lifetime parameters to debugfs") +Fixes: 729a1051da6f ("Bluetooth: Expose default LE advertising interval via debugfs") +Fixes: 71c3b60ec6d2 ("Bluetooth: Move BR/EDR debugfs file creation into hci_debugfs.c") +Signed-off-by: Bastien Nocera +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Greg Kroah-Hartman +--- + net/bluetooth/hci_debugfs.c | 48 +++++++++++++++++++++++++++++--------------- + 1 file changed, 32 insertions(+), 16 deletions(-) + +--- a/net/bluetooth/hci_debugfs.c ++++ b/net/bluetooth/hci_debugfs.c +@@ -217,10 +217,12 @@ static int conn_info_min_age_set(void *d + { + struct hci_dev *hdev = data; + +- if (val == 0 || val > hdev->conn_info_max_age) ++ hci_dev_lock(hdev); ++ if (val == 0 || val > hdev->conn_info_max_age) { ++ hci_dev_unlock(hdev); + return -EINVAL; ++ } + +- hci_dev_lock(hdev); + hdev->conn_info_min_age = val; + hci_dev_unlock(hdev); + +@@ -245,10 +247,12 @@ static int conn_info_max_age_set(void *d + { + struct hci_dev *hdev = data; + +- if (val == 0 || val < hdev->conn_info_min_age) ++ hci_dev_lock(hdev); ++ if (val == 0 || val < hdev->conn_info_min_age) { ++ hci_dev_unlock(hdev); + return -EINVAL; ++ } + +- hci_dev_lock(hdev); + hdev->conn_info_max_age = val; + hci_dev_unlock(hdev); + +@@ -566,10 +570,12 @@ static int sniff_min_interval_set(void * + { + struct hci_dev *hdev = data; + +- if (val == 0 || val % 2 || val > hdev->sniff_max_interval) ++ hci_dev_lock(hdev); ++ if (val == 0 || val % 2 || val > hdev->sniff_max_interval) { ++ hci_dev_unlock(hdev); + return -EINVAL; ++ } + +- hci_dev_lock(hdev); + hdev->sniff_min_interval = val; + hci_dev_unlock(hdev); + +@@ -594,10 +600,12 @@ static int sniff_max_interval_set(void * + { + struct hci_dev *hdev = data; + +- if (val == 0 || val % 2 || val < hdev->sniff_min_interval) ++ hci_dev_lock(hdev); ++ if (val == 0 || val % 2 || val < hdev->sniff_min_interval) { ++ hci_dev_unlock(hdev); + return -EINVAL; ++ } + +- hci_dev_lock(hdev); + hdev->sniff_max_interval = val; + hci_dev_unlock(hdev); + +@@ -849,10 +857,12 @@ static int conn_min_interval_set(void *d + { + struct hci_dev *hdev = data; + +- if (val < 0x0006 || val > 0x0c80 || val > hdev->le_conn_max_interval) ++ hci_dev_lock(hdev); ++ if (val < 0x0006 || val > 0x0c80 || val > hdev->le_conn_max_interval) { ++ hci_dev_unlock(hdev); + return -EINVAL; ++ } + +- hci_dev_lock(hdev); + hdev->le_conn_min_interval = val; + hci_dev_unlock(hdev); + +@@ -877,10 +887,12 @@ static int conn_max_interval_set(void *d + { + struct hci_dev *hdev = data; + +- if (val < 0x0006 || val > 0x0c80 || val < hdev->le_conn_min_interval) ++ hci_dev_lock(hdev); ++ if (val < 0x0006 || val > 0x0c80 || val < hdev->le_conn_min_interval) { ++ hci_dev_unlock(hdev); + return -EINVAL; ++ } + +- hci_dev_lock(hdev); + hdev->le_conn_max_interval = val; + hci_dev_unlock(hdev); + +@@ -989,10 +1001,12 @@ static int adv_min_interval_set(void *da + { + struct hci_dev *hdev = data; + +- if (val < 0x0020 || val > 0x4000 || val > hdev->le_adv_max_interval) ++ hci_dev_lock(hdev); ++ if (val < 0x0020 || val > 0x4000 || val > hdev->le_adv_max_interval) { ++ hci_dev_unlock(hdev); + return -EINVAL; ++ } + +- hci_dev_lock(hdev); + hdev->le_adv_min_interval = val; + hci_dev_unlock(hdev); + +@@ -1017,10 +1031,12 @@ static int adv_max_interval_set(void *da + { + struct hci_dev *hdev = data; + +- if (val < 0x0020 || val > 0x4000 || val < hdev->le_adv_min_interval) ++ hci_dev_lock(hdev); ++ if (val < 0x0020 || val > 0x4000 || val < hdev->le_adv_min_interval) { ++ hci_dev_unlock(hdev); + return -EINVAL; ++ } + +- hci_dev_lock(hdev); + hdev->le_adv_max_interval = val; + hci_dev_unlock(hdev); + diff --git a/queue-6.1/bluetooth-hci_event-set-the-conn-encrypted-before-conn-establishes.patch b/queue-6.1/bluetooth-hci_event-set-the-conn-encrypted-before-conn-establishes.patch new file mode 100644 index 00000000000..d1bf191425b --- /dev/null +++ b/queue-6.1/bluetooth-hci_event-set-the-conn-encrypted-before-conn-establishes.patch @@ -0,0 +1,108 @@ +From c569242cd49287d53b73a94233db40097d838535 Mon Sep 17 00:00:00 2001 +From: Hui Wang +Date: Wed, 27 Mar 2024 12:30:30 +0800 +Subject: Bluetooth: hci_event: set the conn encrypted before conn establishes + +From: Hui Wang + +commit c569242cd49287d53b73a94233db40097d838535 upstream. + +We have a BT headset (Lenovo Thinkplus XT99), the pairing and +connecting has no problem, once this headset is paired, bluez will +remember this device and will auto re-connect it whenever the device +is powered on. The auto re-connecting works well with Windows and +Android, but with Linux, it always fails. Through debugging, we found +at the rfcomm connection stage, the bluetooth stack reports +"Connection refused - security block (0x0003)". + +For this device, the re-connecting negotiation process is different +from other BT headsets, it sends the Link_KEY_REQUEST command before +the CONNECT_REQUEST completes, and it doesn't send ENCRYPT_CHANGE +command during the negotiation. When the device sends the "connect +complete" to hci, the ev->encr_mode is 1. + +So here in the conn_complete_evt(), if ev->encr_mode is 1, link type +is ACL and HCI_CONN_ENCRYPT is not set, we set HCI_CONN_ENCRYPT to +this conn, and update conn->enc_key_size accordingly. + +After this change, this BT headset could re-connect with Linux +successfully. This is the btmon log after applying the patch, after +receiving the "Connect Complete" with "Encryption: Enabled", will send +the command to read encryption key size: +> HCI Event: Connect Request (0x04) plen 10 + Address: 8C:3C:AA:D8:11:67 (OUI 8C-3C-AA) + Class: 0x240404 + Major class: Audio/Video (headset, speaker, stereo, video, vcr) + Minor class: Wearable Headset Device + Rendering (Printing, Speaker) + Audio (Speaker, Microphone, Headset) + Link type: ACL (0x01) +... +> HCI Event: Link Key Request (0x17) plen 6 + Address: 8C:3C:AA:D8:11:67 (OUI 8C-3C-AA) +< HCI Command: Link Key Request Reply (0x01|0x000b) plen 22 + Address: 8C:3C:AA:D8:11:67 (OUI 8C-3C-AA) + Link key: ${32-hex-digits-key} +... +> HCI Event: Connect Complete (0x03) plen 11 + Status: Success (0x00) + Handle: 256 + Address: 8C:3C:AA:D8:11:67 (OUI 8C-3C-AA) + Link type: ACL (0x01) + Encryption: Enabled (0x01) +< HCI Command: Read Encryption Key... (0x05|0x0008) plen 2 + Handle: 256 +< ACL Data TX: Handle 256 flags 0x00 dlen 10 + L2CAP: Information Request (0x0a) ident 1 len 2 + Type: Extended features supported (0x0002) +> HCI Event: Command Complete (0x0e) plen 7 + Read Encryption Key Size (0x05|0x0008) ncmd 1 + Status: Success (0x00) + Handle: 256 + Key size: 16 + +Cc: stable@vger.kernel.org +Link: https://github.com/bluez/bluez/issues/704 +Reviewed-by: Paul Menzel +Reviewed-by: Luiz Augusto von Dentz +Signed-off-by: Hui Wang +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Greg Kroah-Hartman +--- + net/bluetooth/hci_event.c | 25 +++++++++++++++++++++++++ + 1 file changed, 25 insertions(+) + +--- a/net/bluetooth/hci_event.c ++++ b/net/bluetooth/hci_event.c +@@ -3234,6 +3234,31 @@ static void hci_conn_complete_evt(struct + if (test_bit(HCI_ENCRYPT, &hdev->flags)) + set_bit(HCI_CONN_ENCRYPT, &conn->flags); + ++ /* "Link key request" completed ahead of "connect request" completes */ ++ if (ev->encr_mode == 1 && !test_bit(HCI_CONN_ENCRYPT, &conn->flags) && ++ ev->link_type == ACL_LINK) { ++ struct link_key *key; ++ struct hci_cp_read_enc_key_size cp; ++ ++ key = hci_find_link_key(hdev, &ev->bdaddr); ++ if (key) { ++ set_bit(HCI_CONN_ENCRYPT, &conn->flags); ++ ++ if (!(hdev->commands[20] & 0x10)) { ++ conn->enc_key_size = HCI_LINK_KEY_SIZE; ++ } else { ++ cp.handle = cpu_to_le16(conn->handle); ++ if (hci_send_cmd(hdev, HCI_OP_READ_ENC_KEY_SIZE, ++ sizeof(cp), &cp)) { ++ bt_dev_err(hdev, "sending read key size failed"); ++ conn->enc_key_size = HCI_LINK_KEY_SIZE; ++ } ++ } ++ ++ hci_encrypt_cfm(conn, ev->status); ++ } ++ } ++ + /* Get remote features */ + if (conn->type == ACL_LINK) { + struct hci_cp_read_remote_features cp; diff --git a/queue-6.1/bluetooth-qca-fix-device-address-endianness.patch b/queue-6.1/bluetooth-qca-fix-device-address-endianness.patch new file mode 100644 index 00000000000..a096bf14320 --- /dev/null +++ b/queue-6.1/bluetooth-qca-fix-device-address-endianness.patch @@ -0,0 +1,108 @@ +From 77f45cca8bc55d00520a192f5a7715133591c83e Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Wed, 20 Mar 2024 08:55:54 +0100 +Subject: Bluetooth: qca: fix device-address endianness + +From: Johan Hovold + +commit 77f45cca8bc55d00520a192f5a7715133591c83e upstream. + +The WCN6855 firmware on the Lenovo ThinkPad X13s expects the Bluetooth +device address in big-endian order when setting it using the +EDL_WRITE_BD_ADDR_OPCODE command. + +Presumably, this is the case for all non-ROME devices which all use the +EDL_WRITE_BD_ADDR_OPCODE command for this (unlike the ROME devices which +use a different command and expect the address in little-endian order). + +Reverse the little-endian address before setting it to make sure that +the address can be configured using tools like btmgmt or using the +'local-bd-address' devicetree property. + +Note that this can potentially break systems with boot firmware which +has started relying on the broken behaviour and is incorrectly passing +the address via devicetree in big-endian order. + +The only device affected by this should be the WCN3991 used in some +Chromebooks. As ChromeOS updates the kernel and devicetree in lockstep, +the new 'qcom,local-bd-address-broken' property can be used to determine +if the firmware is buggy so that the underlying driver bug can be fixed +without breaking backwards compatibility. + +Set the HCI_QUIRK_BDADDR_PROPERTY_BROKEN quirk for such platforms so +that the address is reversed when parsing the address property. + +Fixes: 5c0a1001c8be ("Bluetooth: hci_qca: Add helper to set device address") +Cc: stable@vger.kernel.org # 5.1 +Cc: Balakrishna Godavarthi +Cc: Matthias Kaehlcke +Tested-by: Nikita Travkin # sc7180 +Reviewed-by: Douglas Anderson +Signed-off-by: Johan Hovold +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Greg Kroah-Hartman +--- + drivers/bluetooth/btqca.c | 8 ++++++-- + drivers/bluetooth/hci_qca.c | 10 ++++++++++ + 2 files changed, 16 insertions(+), 2 deletions(-) + +--- a/drivers/bluetooth/btqca.c ++++ b/drivers/bluetooth/btqca.c +@@ -758,11 +758,15 @@ EXPORT_SYMBOL_GPL(qca_uart_setup); + + int qca_set_bdaddr(struct hci_dev *hdev, const bdaddr_t *bdaddr) + { ++ bdaddr_t bdaddr_swapped; + struct sk_buff *skb; + int err; + +- skb = __hci_cmd_sync_ev(hdev, EDL_WRITE_BD_ADDR_OPCODE, 6, bdaddr, +- HCI_EV_VENDOR, HCI_INIT_TIMEOUT); ++ baswap(&bdaddr_swapped, bdaddr); ++ ++ skb = __hci_cmd_sync_ev(hdev, EDL_WRITE_BD_ADDR_OPCODE, 6, ++ &bdaddr_swapped, HCI_EV_VENDOR, ++ HCI_INIT_TIMEOUT); + if (IS_ERR(skb)) { + err = PTR_ERR(skb); + bt_dev_err(hdev, "QCA Change address cmd failed (%d)", err); +--- a/drivers/bluetooth/hci_qca.c ++++ b/drivers/bluetooth/hci_qca.c +@@ -225,6 +225,7 @@ struct qca_serdev { + struct qca_power *bt_power; + u32 init_speed; + u32 oper_speed; ++ bool bdaddr_property_broken; + const char *firmware_name; + }; + +@@ -1787,6 +1788,7 @@ static int qca_setup(struct hci_uart *hu + const char *firmware_name = qca_get_firmware_name(hu); + int ret; + struct qca_btsoc_version ver; ++ struct qca_serdev *qcadev; + const char *soc_name; + + ret = qca_check_speeds(hu); +@@ -1845,6 +1847,11 @@ retry: + case QCA_WCN6855: + case QCA_WCN7850: + set_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &hdev->quirks); ++ ++ qcadev = serdev_device_get_drvdata(hu->serdev); ++ if (qcadev->bdaddr_property_broken) ++ set_bit(HCI_QUIRK_BDADDR_PROPERTY_BROKEN, &hdev->quirks); ++ + hci_set_aosp_capable(hdev); + + ret = qca_read_soc_version(hdev, &ver, soc_type); +@@ -2212,6 +2219,9 @@ static int qca_serdev_probe(struct serde + if (!qcadev->oper_speed) + BT_DBG("UART will pick default operating speed"); + ++ qcadev->bdaddr_property_broken = device_property_read_bool(&serdev->dev, ++ "qcom,local-bd-address-broken"); ++ + if (data) + qcadev->btsoc_type = data->soc_type; + else diff --git a/queue-6.1/kvm-arm64-fix-host-programmed-guest-events-in-nvhe.patch b/queue-6.1/kvm-arm64-fix-host-programmed-guest-events-in-nvhe.patch new file mode 100644 index 00000000000..6256bfe0a55 --- /dev/null +++ b/queue-6.1/kvm-arm64-fix-host-programmed-guest-events-in-nvhe.patch @@ -0,0 +1,40 @@ +From e89c928bedd77d181edc2df01cb6672184775140 Mon Sep 17 00:00:00 2001 +From: Oliver Upton +Date: Tue, 5 Mar 2024 18:48:39 +0000 +Subject: KVM: arm64: Fix host-programmed guest events in nVHE + +From: Oliver Upton + +commit e89c928bedd77d181edc2df01cb6672184775140 upstream. + +Programming PMU events in the host that count during guest execution is +a feature supported by perf, e.g. + + perf stat -e cpu_cycles:G ./lkvm run + +While this works for VHE, the guest/host event bitmaps are not carried +through to the hypervisor in the nVHE configuration. Make +kvm_pmu_update_vcpu_events() conditional on whether or not _hardware_ +supports PMUv3 rather than if the vCPU as vPMU enabled. + +Cc: stable@vger.kernel.org +Fixes: 84d751a019a9 ("KVM: arm64: Pass pmu events to hyp via vcpu") +Reviewed-by: Marc Zyngier +Link: https://lore.kernel.org/r/20240305184840.636212-3-oliver.upton@linux.dev +Signed-off-by: Oliver Upton +Signed-off-by: Greg Kroah-Hartman +--- + include/kvm/arm_pmu.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/include/kvm/arm_pmu.h ++++ b/include/kvm/arm_pmu.h +@@ -85,7 +85,7 @@ void kvm_vcpu_pmu_restore_host(struct kv + */ + #define kvm_pmu_update_vcpu_events(vcpu) \ + do { \ +- if (!has_vhe() && kvm_vcpu_has_pmu(vcpu)) \ ++ if (!has_vhe() && kvm_arm_support_pmu_v3()) \ + vcpu->arch.pmu.events = *kvm_get_pmu_events(); \ + } while (0) + diff --git a/queue-6.1/net-rds-fix-possible-cp-null-dereference.patch b/queue-6.1/net-rds-fix-possible-cp-null-dereference.patch new file mode 100644 index 00000000000..d49821fd971 --- /dev/null +++ b/queue-6.1/net-rds-fix-possible-cp-null-dereference.patch @@ -0,0 +1,66 @@ +From 62fc3357e079a07a22465b9b6ef71bb6ea75ee4b Mon Sep 17 00:00:00 2001 +From: Mahmoud Adam +Date: Tue, 26 Mar 2024 16:31:33 +0100 +Subject: net/rds: fix possible cp null dereference + +From: Mahmoud Adam + +commit 62fc3357e079a07a22465b9b6ef71bb6ea75ee4b upstream. + +cp might be null, calling cp->cp_conn would produce null dereference + +[Simon Horman adds:] + +Analysis: + +* cp is a parameter of __rds_rdma_map and is not reassigned. + +* The following call-sites pass a NULL cp argument to __rds_rdma_map() + + - rds_get_mr() + - rds_get_mr_for_dest + +* Prior to the code above, the following assumes that cp may be NULL + (which is indicative, but could itself be unnecessary) + + trans_private = rs->rs_transport->get_mr( + sg, nents, rs, &mr->r_key, cp ? cp->cp_conn : NULL, + args->vec.addr, args->vec.bytes, + need_odp ? ODP_ZEROBASED : ODP_NOT_NEEDED); + +* The code modified by this patch is guarded by IS_ERR(trans_private), + where trans_private is assigned as per the previous point in this analysis. + + The only implementation of get_mr that I could locate is rds_ib_get_mr() + which can return an ERR_PTR if the conn (4th) argument is NULL. + +* ret is set to PTR_ERR(trans_private). + rds_ib_get_mr can return ERR_PTR(-ENODEV) if the conn (4th) argument is NULL. + Thus ret may be -ENODEV in which case the code in question will execute. + +Conclusion: +* cp may be NULL at the point where this patch adds a check; + this patch does seem to address a possible bug + +Fixes: c055fc00c07b ("net/rds: fix WARNING in rds_conn_connect_if_down") +Cc: stable@vger.kernel.org # v4.19+ +Signed-off-by: Mahmoud Adam +Reviewed-by: Simon Horman +Link: https://lore.kernel.org/r/20240326153132.55580-1-mngyadam@amazon.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/rds/rdma.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/net/rds/rdma.c ++++ b/net/rds/rdma.c +@@ -302,7 +302,7 @@ static int __rds_rdma_map(struct rds_soc + } + ret = PTR_ERR(trans_private); + /* Trigger connection so that its ready for the next retry */ +- if (ret == -ENODEV) ++ if (ret == -ENODEV && cp) + rds_conn_connect_if_down(cp->cp_conn); + goto out; + } diff --git a/queue-6.1/net-usb-ax88179_178a-avoid-the-interface-always-configured-as-random-address.patch b/queue-6.1/net-usb-ax88179_178a-avoid-the-interface-always-configured-as-random-address.patch new file mode 100644 index 00000000000..ea3fbbf1384 --- /dev/null +++ b/queue-6.1/net-usb-ax88179_178a-avoid-the-interface-always-configured-as-random-address.patch @@ -0,0 +1,47 @@ +From 2e91bb99b9d4f756e92e83c4453f894dda220f09 Mon Sep 17 00:00:00 2001 +From: Jose Ignacio Tornos Martinez +Date: Wed, 3 Apr 2024 15:21:58 +0200 +Subject: net: usb: ax88179_178a: avoid the interface always configured as random address + +From: Jose Ignacio Tornos Martinez + +commit 2e91bb99b9d4f756e92e83c4453f894dda220f09 upstream. + +After the commit d2689b6a86b9 ("net: usb: ax88179_178a: avoid two +consecutive device resets"), reset is not executed from bind operation and +mac address is not read from the device registers or the devicetree at that +moment. Since the check to configure if the assigned mac address is random +or not for the interface, happens after the bind operation from +usbnet_probe, the interface keeps configured as random address, although the +address is correctly read and set during open operation (the only reset +now). + +In order to keep only one reset for the device and to avoid the interface +always configured as random address, after reset, configure correctly the +suitable field from the driver, if the mac address is read successfully from +the device registers or the devicetree. Take into account if a locally +administered address (random) was previously stored. + +cc: stable@vger.kernel.org # 6.6+ +Fixes: d2689b6a86b9 ("net: usb: ax88179_178a: avoid two consecutive device resets") +Reported-by: Dave Stevenson +Signed-off-by: Jose Ignacio Tornos Martinez +Reviewed-by: Simon Horman +Link: https://lore.kernel.org/r/20240403132158.344838-1-jtornosm@redhat.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/usb/ax88179_178a.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/net/usb/ax88179_178a.c ++++ b/drivers/net/usb/ax88179_178a.c +@@ -1273,6 +1273,8 @@ static void ax88179_get_mac_addr(struct + + if (is_valid_ether_addr(mac)) { + eth_hw_addr_set(dev->net, mac); ++ if (!is_local_ether_addr(mac)) ++ dev->net->addr_assign_type = NET_ADDR_PERM; + } else { + netdev_info(dev->net, "invalid MAC address, using random\n"); + eth_hw_addr_random(dev->net); diff --git a/queue-6.1/r8169-fix-issue-caused-by-buggy-bios-on-certain-boards-with-rtl8168d.patch b/queue-6.1/r8169-fix-issue-caused-by-buggy-bios-on-certain-boards-with-rtl8168d.patch new file mode 100644 index 00000000000..07df6d6f4e7 --- /dev/null +++ b/queue-6.1/r8169-fix-issue-caused-by-buggy-bios-on-certain-boards-with-rtl8168d.patch @@ -0,0 +1,43 @@ +From 5d872c9f46bd2ea3524af3c2420a364a13667135 Mon Sep 17 00:00:00 2001 +From: Heiner Kallweit +Date: Sat, 30 Mar 2024 12:49:02 +0100 +Subject: r8169: fix issue caused by buggy BIOS on certain boards with RTL8168d + +From: Heiner Kallweit + +commit 5d872c9f46bd2ea3524af3c2420a364a13667135 upstream. + +On some boards with this chip version the BIOS is buggy and misses +to reset the PHY page selector. This results in the PHY ID read +accessing registers on a different page, returning a more or +less random value. Fix this by resetting the page selector first. + +Fixes: f1e911d5d0df ("r8169: add basic phylib support") +Cc: stable@vger.kernel.org +Signed-off-by: Heiner Kallweit +Reviewed-by: Simon Horman +Link: https://lore.kernel.org/r/64f2055e-98b8-45ec-8568-665e3d54d4e6@gmail.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/realtek/r8169_main.c | 9 +++++++++ + 1 file changed, 9 insertions(+) + +--- a/drivers/net/ethernet/realtek/r8169_main.c ++++ b/drivers/net/ethernet/realtek/r8169_main.c +@@ -5032,6 +5032,15 @@ static int r8169_mdio_register(struct rt + struct mii_bus *new_bus; + int ret; + ++ /* On some boards with this chip version the BIOS is buggy and misses ++ * to reset the PHY page selector. This results in the PHY ID read ++ * accessing registers on a different page, returning a more or ++ * less random value. Fix this by resetting the page selector first. ++ */ ++ if (tp->mac_version == RTL_GIGA_MAC_VER_25 || ++ tp->mac_version == RTL_GIGA_MAC_VER_26) ++ r8169_mdio_write(tp, 0x1f, 0); ++ + new_bus = devm_mdiobus_alloc(&pdev->dev); + if (!new_bus) + return -ENOMEM; diff --git a/queue-6.1/revert-bluetooth-hci_qca-set-bda-quirk-bit-if-fwnode-exists-in-dt.patch b/queue-6.1/revert-bluetooth-hci_qca-set-bda-quirk-bit-if-fwnode-exists-in-dt.patch new file mode 100644 index 00000000000..984d5121904 --- /dev/null +++ b/queue-6.1/revert-bluetooth-hci_qca-set-bda-quirk-bit-if-fwnode-exists-in-dt.patch @@ -0,0 +1,65 @@ +From 4790a73ace86f3d165bbedba898e0758e6e1b82d Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Thu, 14 Mar 2024 09:44:12 +0100 +Subject: Revert "Bluetooth: hci_qca: Set BDA quirk bit if fwnode exists in DT" + +From: Johan Hovold + +commit 4790a73ace86f3d165bbedba898e0758e6e1b82d upstream. + +This reverts commit 7dcd3e014aa7faeeaf4047190b22d8a19a0db696. + +Qualcomm Bluetooth controllers like WCN6855 do not have persistent +storage for the Bluetooth address and must therefore start as +unconfigured to allow the user to set a valid address unless one has +been provided by the boot firmware in the devicetree. + +A recent change snuck into v6.8-rc7 and incorrectly started marking the +default (non-unique) address as valid. This specifically also breaks the +Bluetooth setup for some user of the Lenovo ThinkPad X13s. + +Note that this is the second time Qualcomm breaks the driver this way +and that this was fixed last year by commit 6945795bc81a ("Bluetooth: +fix use-bdaddr-property quirk"), which also has some further details. + +Fixes: 7dcd3e014aa7 ("Bluetooth: hci_qca: Set BDA quirk bit if fwnode exists in DT") +Cc: stable@vger.kernel.org # 6.8 +Cc: Janaki Ramaiah Thota +Signed-off-by: Johan Hovold +Reported-by: Clayton Craft +Tested-by: Clayton Craft +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Greg Kroah-Hartman +--- + drivers/bluetooth/hci_qca.c | 13 +------------ + 1 file changed, 1 insertion(+), 12 deletions(-) + +--- a/drivers/bluetooth/hci_qca.c ++++ b/drivers/bluetooth/hci_qca.c +@@ -7,7 +7,6 @@ + * + * Copyright (C) 2007 Texas Instruments, Inc. + * Copyright (c) 2010, 2012, 2018 The Linux Foundation. All rights reserved. +- * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved. + * + * Acknowledgements: + * This file is based on hci_ll.c, which was... +@@ -1845,17 +1844,7 @@ retry: + case QCA_WCN6750: + case QCA_WCN6855: + case QCA_WCN7850: +- +- /* Set BDA quirk bit for reading BDA value from fwnode property +- * only if that property exist in DT. +- */ +- if (fwnode_property_present(dev_fwnode(hdev->dev.parent), "local-bd-address")) { +- set_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &hdev->quirks); +- bt_dev_info(hdev, "setting quirk bit to read BDA from fwnode later"); +- } else { +- bt_dev_dbg(hdev, "local-bd-address` is not present in the devicetree so not setting quirk bit for BDA"); +- } +- ++ set_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &hdev->quirks); + hci_set_aosp_capable(hdev); + + ret = qca_read_soc_version(hdev, &ver, soc_type); diff --git a/queue-6.1/series b/queue-6.1/series index 05f1a0e8f46..ccd1e22496a 100644 --- a/queue-6.1/series +++ b/queue-6.1/series @@ -23,3 +23,16 @@ inet-inet_defrag-prevent-sk-release-while-still-in-u.patch dm-integrity-fix-out-of-range-warning.patch x86-cpufeatures-add-new-word-for-scattered-features.patch perf-x86-amd-lbr-use-freeze-based-on-availability.patch +kvm-arm64-fix-host-programmed-guest-events-in-nvhe.patch +r8169-fix-issue-caused-by-buggy-bios-on-certain-boards-with-rtl8168d.patch +x86-cpufeatures-add-cpuid_lnx_5-to-track-recently-added-linux-defined-word.patch +revert-bluetooth-hci_qca-set-bda-quirk-bit-if-fwnode-exists-in-dt.patch +arm64-dts-qcom-sc7180-trogdor-mark-bluetooth-address-as-broken.patch +bluetooth-qca-fix-device-address-endianness.patch +bluetooth-add-quirk-for-broken-address-properties.patch +bluetooth-hci_event-set-the-conn-encrypted-before-conn-establishes.patch +bluetooth-fix-toctou-in-hci-debugfs-implementation.patch +xen-netfront-add-missing-skb_mark_for_recycle.patch +net-rds-fix-possible-cp-null-dereference.patch +net-usb-ax88179_178a-avoid-the-interface-always-configured-as-random-address.patch +vsock-virtio-fix-packet-delivery-to-tap-device.patch diff --git a/queue-6.1/vsock-virtio-fix-packet-delivery-to-tap-device.patch b/queue-6.1/vsock-virtio-fix-packet-delivery-to-tap-device.patch new file mode 100644 index 00000000000..d418424c49c --- /dev/null +++ b/queue-6.1/vsock-virtio-fix-packet-delivery-to-tap-device.patch @@ -0,0 +1,55 @@ +From b32a09ea7c38849ff925489a6bf5bd8914bc45df Mon Sep 17 00:00:00 2001 +From: Marco Pinna +Date: Fri, 29 Mar 2024 17:12:59 +0100 +Subject: vsock/virtio: fix packet delivery to tap device + +From: Marco Pinna + +commit b32a09ea7c38849ff925489a6bf5bd8914bc45df upstream. + +Commit 82dfb540aeb2 ("VSOCK: Add virtio vsock vsockmon hooks") added +virtio_transport_deliver_tap_pkt() for handing packets to the +vsockmon device. However, in virtio_transport_send_pkt_work(), +the function is called before actually sending the packet (i.e. +before placing it in the virtqueue with virtqueue_add_sgs() and checking +whether it returned successfully). +Queuing the packet in the virtqueue can fail even multiple times. +However, in virtio_transport_deliver_tap_pkt() we deliver the packet +to the monitoring tap interface only the first time we call it. +This certainly avoids seeing the same packet replicated multiple times +in the monitoring interface, but it can show the packet sent with the +wrong timestamp or even before we succeed to queue it in the virtqueue. + +Move virtio_transport_deliver_tap_pkt() after calling virtqueue_add_sgs() +and making sure it returned successfully. + +Fixes: 82dfb540aeb2 ("VSOCK: Add virtio vsock vsockmon hooks") +Cc: stable@vge.kernel.org +Signed-off-by: Marco Pinna +Reviewed-by: Stefano Garzarella +Link: https://lore.kernel.org/r/20240329161259.411751-1-marco.pinn95@gmail.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/vmw_vsock/virtio_transport.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/net/vmw_vsock/virtio_transport.c ++++ b/net/vmw_vsock/virtio_transport.c +@@ -109,7 +109,6 @@ virtio_transport_send_pkt_work(struct wo + if (!skb) + break; + +- virtio_transport_deliver_tap_pkt(skb); + reply = virtio_vsock_skb_reply(skb); + + sg_init_one(&hdr, virtio_vsock_hdr(skb), sizeof(*virtio_vsock_hdr(skb))); +@@ -128,6 +127,8 @@ virtio_transport_send_pkt_work(struct wo + break; + } + ++ virtio_transport_deliver_tap_pkt(skb); ++ + if (reply) { + struct virtqueue *rx_vq = vsock->vqs[VSOCK_VQ_RX]; + int val; diff --git a/queue-6.1/x86-cpufeatures-add-cpuid_lnx_5-to-track-recently-added-linux-defined-word.patch b/queue-6.1/x86-cpufeatures-add-cpuid_lnx_5-to-track-recently-added-linux-defined-word.patch new file mode 100644 index 00000000000..88e9a8ca3a2 --- /dev/null +++ b/queue-6.1/x86-cpufeatures-add-cpuid_lnx_5-to-track-recently-added-linux-defined-word.patch @@ -0,0 +1,59 @@ +From 8cb4a9a82b21623dbb4b3051dd30d98356cf95bc Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Thu, 4 Apr 2024 17:16:14 -0700 +Subject: x86/cpufeatures: Add CPUID_LNX_5 to track recently added Linux-defined word + +From: Sean Christopherson + +commit 8cb4a9a82b21623dbb4b3051dd30d98356cf95bc upstream. + +Add CPUID_LNX_5 to track cpufeatures' word 21, and add the appropriate +compile-time assert in KVM to prevent direct lookups on the features in +CPUID_LNX_5. KVM uses X86_FEATURE_* flags to manage guest CPUID, and so +must translate features that are scattered by Linux from the Linux-defined +bit to the hardware-defined bit, i.e. should never try to directly access +scattered features in guest CPUID. + +Opportunistically add NR_CPUID_WORDS to enum cpuid_leafs, along with a +compile-time assert in KVM's CPUID infrastructure to ensure that future +additions update cpuid_leafs along with NCAPINTS. + +No functional change intended. + +Fixes: 7f274e609f3d ("x86/cpufeatures: Add new word for scattered features") +Cc: Sandipan Das +Signed-off-by: Sean Christopherson +Acked-by: Dave Hansen +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/include/asm/cpufeature.h | 2 ++ + arch/x86/kvm/reverse_cpuid.h | 2 ++ + 2 files changed, 4 insertions(+) + +--- a/arch/x86/include/asm/cpufeature.h ++++ b/arch/x86/include/asm/cpufeature.h +@@ -33,6 +33,8 @@ enum cpuid_leafs + CPUID_7_EDX, + CPUID_8000_001F_EAX, + CPUID_8000_0021_EAX, ++ CPUID_LNX_5, ++ NR_CPUID_WORDS, + }; + + #define X86_CAP_FMT_NUM "%d:%d" +--- a/arch/x86/kvm/reverse_cpuid.h ++++ b/arch/x86/kvm/reverse_cpuid.h +@@ -83,10 +83,12 @@ static const struct cpuid_reg reverse_cp + */ + static __always_inline void reverse_cpuid_check(unsigned int x86_leaf) + { ++ BUILD_BUG_ON(NR_CPUID_WORDS != NCAPINTS); + BUILD_BUG_ON(x86_leaf == CPUID_LNX_1); + BUILD_BUG_ON(x86_leaf == CPUID_LNX_2); + BUILD_BUG_ON(x86_leaf == CPUID_LNX_3); + BUILD_BUG_ON(x86_leaf == CPUID_LNX_4); ++ BUILD_BUG_ON(x86_leaf == CPUID_LNX_5); + BUILD_BUG_ON(x86_leaf >= ARRAY_SIZE(reverse_cpuid)); + BUILD_BUG_ON(reverse_cpuid[x86_leaf].function == 0); + } diff --git a/queue-6.1/xen-netfront-add-missing-skb_mark_for_recycle.patch b/queue-6.1/xen-netfront-add-missing-skb_mark_for_recycle.patch new file mode 100644 index 00000000000..4f51a458b51 --- /dev/null +++ b/queue-6.1/xen-netfront-add-missing-skb_mark_for_recycle.patch @@ -0,0 +1,45 @@ +From 037965402a010898d34f4e35327d22c0a95cd51f Mon Sep 17 00:00:00 2001 +From: Jesper Dangaard Brouer +Date: Wed, 27 Mar 2024 13:14:56 +0100 +Subject: xen-netfront: Add missing skb_mark_for_recycle + +From: Jesper Dangaard Brouer + +commit 037965402a010898d34f4e35327d22c0a95cd51f upstream. + +Notice that skb_mark_for_recycle() is introduced later than fixes tag in +commit 6a5bcd84e886 ("page_pool: Allow drivers to hint on SKB recycling"). + +It is believed that fixes tag were missing a call to page_pool_release_page() +between v5.9 to v5.14, after which is should have used skb_mark_for_recycle(). +Since v6.6 the call page_pool_release_page() were removed (in +commit 535b9c61bdef ("net: page_pool: hide page_pool_release_page()") +and remaining callers converted (in commit 6bfef2ec0172 ("Merge branch +'net-page_pool-remove-page_pool_release_page'")). + +This leak became visible in v6.8 via commit dba1b8a7ab68 ("mm/page_pool: catch +page_pool memory leaks"). + +Cc: stable@vger.kernel.org +Fixes: 6c5aa6fc4def ("xen networking: add basic XDP support for xen-netfront") +Reported-by: Leonidas Spyropoulos +Link: https://bugzilla.kernel.org/show_bug.cgi?id=218654 +Reported-by: Arthur Borsboom +Signed-off-by: Jesper Dangaard Brouer +Link: https://lore.kernel.org/r/171154167446.2671062.9127105384591237363.stgit@firesoul +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/xen-netfront.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/net/xen-netfront.c ++++ b/drivers/net/xen-netfront.c +@@ -285,6 +285,7 @@ static struct sk_buff *xennet_alloc_one_ + return NULL; + } + skb_add_rx_frag(skb, 0, page, 0, 0, PAGE_SIZE); ++ skb_mark_for_recycle(skb); + + /* Align ip header to a 16 bytes boundary */ + skb_reserve(skb, NET_IP_ALIGN);