- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] wifi: ar5523: enable proper endpoint verification
by Chen Zhongjin 04 Jul '24

04 Jul '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> stable inclusion from stable-v5.10.219 commit ee25389df80138907bc9dcdf4a2be2067cde9a81 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SCR CVE: CVE-2024-38565 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit e120b6388d7d88635d67dcae6483f39c37111850 ] Syzkaller reports [1] hitting a warning about an endpoint in use not having an expected type to it. Fix the issue by checking for the existence of all proper endpoints with their according types intact. Sadly, this patch has not been tested on real hardware. [1] Syzkaller report: ------------[ cut here ]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275 ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline] ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline] ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655 usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573 hub_port_connect drivers/usb/core/hub.c:5353 [inline] hub_port_connect_change drivers/usb/core/hub.c:5497 [inline] port_event drivers/usb/core/hub.c:5653 [inline] hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> Reported-and-tested-by: syzbot+1bc2c2afd44f820a669f(a)syzkaller.appspotmail.com Fixes: b7d572e1871d ("ar5523: Add new driver") Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Signed-off-by: Kalle Valo <quic_kvalo(a)quicinc.com> Link: https://msgid.link/20240408121425.29392-1-n.zhandarovich@fintech.ru Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Chen Zhongjin <chenzhongjin(a)huawei.com> --- drivers/net/wireless/ath/ar5523/ar5523.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/net/wireless/ath/ar5523/ar5523.c b/drivers/net/wireless/ath/ar5523/ar5523.c index efe38b2c1df7..71c2bf8817dc 100644 --- a/drivers/net/wireless/ath/ar5523/ar5523.c +++ b/drivers/net/wireless/ath/ar5523/ar5523.c @@ -1590,6 +1590,20 @@ static int ar5523_probe(struct usb_interface *intf, struct ar5523 *ar; int error = -ENOMEM; + static const u8 bulk_ep_addr[] = { + AR5523_CMD_TX_PIPE | USB_DIR_OUT, + AR5523_DATA_TX_PIPE | USB_DIR_OUT, + AR5523_CMD_RX_PIPE | USB_DIR_IN, + AR5523_DATA_RX_PIPE | USB_DIR_IN, + 0}; + + if (!usb_check_bulk_endpoints(intf, bulk_ep_addr)) { + dev_err(&dev->dev, + "Could not find all expected endpoints\n"); + error = -ENODEV; + goto out; + } + /* * Load firmware if the device requires it. This will return * -ENXIO on success and we'll get called back afer the usb -- 2.25.1

2 1

[PATCH OLK-6.6 0/2] Fix xfs file creation issue
by Zizhi Wo 04 Jul '24

04 Jul '24

Revert the previous fix patch and adapt to the latest repair solution. Zizhi Wo (2): Revert "xfs: Fix file creation failure" xfs: Avoid races with cnt_btree lastrec updates fs/xfs/libxfs/xfs_alloc.c | 125 +++++++++++++++++++++++++++++--- fs/xfs/libxfs/xfs_alloc_btree.c | 72 ------------------ fs/xfs/libxfs/xfs_btree.c | 51 ------------- fs/xfs/libxfs/xfs_btree.h | 19 +---- 4 files changed, 115 insertions(+), 152 deletions(-) -- 2.39.2

2 3

[PATCH openEuler-22.03-LTS-SP1 0/2] CVE-2024-26816
by liwei 04 Jul '24

04 Jul '24

CVE-2024-26816 Guixiong Wei (1): x86/boot: Ignore relocations in .notes sections in walk_relocs() too Kees Cook (1): x86, relocs: Ignore relocations in .notes section arch/x86/tools/relocs.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) -- 2.25.1

2 3

[PATCH OLK-5.10 0/2] CVE-2024-26816
by liwei 04 Jul '24

04 Jul '24

CVE-2024-26816 Guixiong Wei (1): x86/boot: Ignore relocations in .notes sections in walk_relocs() too Kees Cook (1): x86, relocs: Ignore relocations in .notes section arch/x86/tools/relocs.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) -- 2.25.1

2 3

[PATCH openEuler-1.0-LTS 0/2] CVE-2024-26816
by liwei 04 Jul '24

04 Jul '24

CVE-2024-26816 Guixiong Wei (1): x86/boot: Ignore relocations in .notes sections in walk_relocs() too Kees Cook (1): x86, relocs: Ignore relocations in .notes section arch/x86/tools/relocs.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) -- 2.25.1

2 3

[PATCH openEuler-1.0-LTS 0/3] CVE-2024-23848
by Yongqiang Liu 04 Jul '24

04 Jul '24

Hans Verkuil (3): media: cec: cec-adap: always cancel work in cec_transmit_msg_fh media: cec: cec-api: add locking in cec_release() media: cec: core: avoid recursive cec_claim_log_addrs drivers/media/cec/cec-adap.c | 9 ++++++--- drivers/media/cec/cec-api.c | 5 ++++- include/media/cec.h | 1 + 3 files changed, 11 insertions(+), 4 deletions(-) -- 2.34.1

2 4

[PATCH v2 OLK-5.10] x86, relocs: Ignore relocations in .notes section
by liwei 04 Jul '24

04 Jul '24

From: Kees Cook <keescook(a)chromium.org> mainline inclusion from mainline-v6.9-rc1 commit aaa8736370db1a78f0e8434344a484f9fd20be3b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9FNFG CVE: CVE-2024-26816 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- When building with CONFIG_XEN_PV=y, .text symbols are emitted into the .notes section so that Xen can find the "startup_xen" entry point. This information is used prior to booting the kernel, so relocations are not useful. In fact, performing relocations against the .notes section means that the KASLR base is exposed since /sys/kernel/notes is world-readable. To avoid leaking the KASLR base without breaking unprivileged tools that are expecting to read /sys/kernel/notes, skip performing relocations in the .notes section. The values readable in .notes are then identical to those found in System.map. Reported-by: Guixiong Wei <guixiongwei(a)gmail.com> Closes: https://lore.kernel.org/all/20240218073501.54555-1-guixiongwei@gmail.com/ Fixes: 5ead97c84fa7 ("xen: Core Xen implementation") Fixes: da1a679cde9b ("Add /sys/kernel/notes") Reviewed-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: Kees Cook <keescook(a)chromium.org> Signed-off-by: liwei <liwei728(a)huawei.com> --- arch/x86/tools/relocs.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c index 1c3a1962cade..0043fd374a62 100644 --- a/arch/x86/tools/relocs.c +++ b/arch/x86/tools/relocs.c @@ -596,6 +596,14 @@ static void print_absolute_relocs(void) if (!(sec_applies->shdr.sh_flags & SHF_ALLOC)) { continue; } + /* + * Do not perform relocations in .notes section; any + * values there are meant for pre-boot consumption (e.g. + * startup_xen). + */ + if (sec_applies->shdr.sh_type == SHT_NOTE) { + continue; + } sh_symtab = sec_symtab->symtab; sym_strtab = sec_symtab->link->strtab; for (j = 0; j < sec->shdr.sh_size/sizeof(Elf_Rel); j++) { -- 2.25.1

2 1

[PATCH OLK-6.6] net: openvswitch: fix overwriting ct original tuple for ICMPv6
by Jinjie Ruan 04 Jul '24

04 Jul '24

From: Ilya Maximets <i.maximets(a)ovn.org> stable inclusion from stable-v5.10.219 commit 5ab6aecbede080b44b8e34720ab72050bf1e6982 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SH5 CVE: CVE-2024-38558 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 7c988176b6c16c516474f6fceebe0f055af5eb56 ] OVS_PACKET_CMD_EXECUTE has 3 main attributes: - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format. - OVS_PACKET_ATTR_PACKET - Binary packet content. - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet. OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure with the metadata like conntrack state, input port, recirculation id, etc. Then the packet itself gets parsed to populate the rest of the keys from the packet headers. Whenever the packet parsing code starts parsing the ICMPv6 header, it first zeroes out fields in the key corresponding to Neighbor Discovery information even if it is not an ND packet. It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares the space between 'nd' and 'ct_orig' that holds the original tuple conntrack metadata parsed from the OVS_PACKET_ATTR_KEY. ND packets should not normally have conntrack state, so it's fine to share the space, but normal ICMPv6 Echo packets or maybe other types of ICMPv6 can have the state attached and it should not be overwritten. The issue results in all but the last 4 bytes of the destination address being wiped from the original conntrack tuple leading to incorrect packet matching and potentially executing wrong actions in case this packet recirculates within the datapath or goes back to userspace. ND fields should not be accessed in non-ND packets, so not clearing them should be fine. Executing memset() only for actual ND packets to avoid the issue. Initializing the whole thing before parsing is needed because ND packet may not contain all the options. The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn't affect packets entering OVS datapath from network interfaces, because in this case CT metadata is populated from skb after the packet is already parsed. Fixes: 9dd7f8907c37 ("openvswitch: Add original direction conntrack tuple to sw_flow_key.") Reported-by: Antonin Bas <antonin.bas(a)broadcom.com> Closes: https://github.com/openvswitch/ovs-issues/issues/327 Signed-off-by: Ilya Maximets <i.maximets(a)ovn.org> Acked-by: Aaron Conole <aconole(a)redhat.com> Acked-by: Eelco Chaudron <echaudro(a)redhat.com> Link: https://lore.kernel.org/r/20240509094228.1035477-1-i.maximets@ovn.org Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- net/openvswitch/flow.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c index 33b21a0c0548..8a848ce72e29 100644 --- a/net/openvswitch/flow.c +++ b/net/openvswitch/flow.c @@ -561,7 +561,6 @@ static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key, */ key->tp.src = htons(icmp->icmp6_type); key->tp.dst = htons(icmp->icmp6_code); - memset(&key->ipv6.nd, 0, sizeof(key->ipv6.nd)); if (icmp->icmp6_code == 0 && (icmp->icmp6_type == NDISC_NEIGHBOUR_SOLICITATION || @@ -570,6 +569,8 @@ static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key, struct nd_msg *nd; int offset; + memset(&key->ipv6.nd, 0, sizeof(key->ipv6.nd)); + /* In order to process neighbor discovery options, we need the * entire packet. */ -- 2.34.1

2 1

[PATCH OLK-5.10] net: openvswitch: fix overwriting ct original tuple for ICMPv6
by Jinjie Ruan 04 Jul '24

04 Jul '24

From: Ilya Maximets <i.maximets(a)ovn.org> stable inclusion from stable-v5.10.219 commit 5ab6aecbede080b44b8e34720ab72050bf1e6982 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SH5 CVE: CVE-2024-38558 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 7c988176b6c16c516474f6fceebe0f055af5eb56 ] OVS_PACKET_CMD_EXECUTE has 3 main attributes: - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format. - OVS_PACKET_ATTR_PACKET - Binary packet content. - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet. OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure with the metadata like conntrack state, input port, recirculation id, etc. Then the packet itself gets parsed to populate the rest of the keys from the packet headers. Whenever the packet parsing code starts parsing the ICMPv6 header, it first zeroes out fields in the key corresponding to Neighbor Discovery information even if it is not an ND packet. It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares the space between 'nd' and 'ct_orig' that holds the original tuple conntrack metadata parsed from the OVS_PACKET_ATTR_KEY. ND packets should not normally have conntrack state, so it's fine to share the space, but normal ICMPv6 Echo packets or maybe other types of ICMPv6 can have the state attached and it should not be overwritten. The issue results in all but the last 4 bytes of the destination address being wiped from the original conntrack tuple leading to incorrect packet matching and potentially executing wrong actions in case this packet recirculates within the datapath or goes back to userspace. ND fields should not be accessed in non-ND packets, so not clearing them should be fine. Executing memset() only for actual ND packets to avoid the issue. Initializing the whole thing before parsing is needed because ND packet may not contain all the options. The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn't affect packets entering OVS datapath from network interfaces, because in this case CT metadata is populated from skb after the packet is already parsed. Fixes: 9dd7f8907c37 ("openvswitch: Add original direction conntrack tuple to sw_flow_key.") Reported-by: Antonin Bas <antonin.bas(a)broadcom.com> Closes: https://github.com/openvswitch/ovs-issues/issues/327 Signed-off-by: Ilya Maximets <i.maximets(a)ovn.org> Acked-by: Aaron Conole <aconole(a)redhat.com> Acked-by: Eelco Chaudron <echaudro(a)redhat.com> Link: https://lore.kernel.org/r/20240509094228.1035477-1-i.maximets@ovn.org Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- net/openvswitch/flow.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c index c9ba61413c98..9bad601c7fe8 100644 --- a/net/openvswitch/flow.c +++ b/net/openvswitch/flow.c @@ -412,7 +412,6 @@ static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key, */ key->tp.src = htons(icmp->icmp6_type); key->tp.dst = htons(icmp->icmp6_code); - memset(&key->ipv6.nd, 0, sizeof(key->ipv6.nd)); if (icmp->icmp6_code == 0 && (icmp->icmp6_type == NDISC_NEIGHBOUR_SOLICITATION || @@ -421,6 +420,8 @@ static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key, struct nd_msg *nd; int offset; + memset(&key->ipv6.nd, 0, sizeof(key->ipv6.nd)); + /* In order to process neighbor discovery options, we need the * entire packet. */ -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] wifi: ar5523: enable proper endpoint verification
by Chen Zhongjin 04 Jul '24

04 Jul '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> stable inclusion from stable-v4.19.316 commit 79ddf5f2020fd593d50f1363bb5131283d74f78f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SCR CVE: CVE-2024-38565 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit e120b6388d7d88635d67dcae6483f39c37111850 ] Syzkaller reports [1] hitting a warning about an endpoint in use not having an expected type to it. Fix the issue by checking for the existence of all proper endpoints with their according types intact. Sadly, this patch has not been tested on real hardware. [1] Syzkaller report: ------------[ cut here ]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275 ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline] ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline] ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655 usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573 hub_port_connect drivers/usb/core/hub.c:5353 [inline] hub_port_connect_change drivers/usb/core/hub.c:5497 [inline] port_event drivers/usb/core/hub.c:5653 [inline] hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> Reported-and-tested-by: syzbot+1bc2c2afd44f820a669f(a)syzkaller.appspotmail.com Fixes: b7d572e1871d ("ar5523: Add new driver") Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Signed-off-by: Kalle Valo <quic_kvalo(a)quicinc.com> Link: https://msgid.link/20240408121425.29392-1-n.zhandarovich@fintech.ru Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Chen Zhongjin <chenzhongjin(a)huawei.com> --- drivers/net/wireless/ath/ar5523/ar5523.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/net/wireless/ath/ar5523/ar5523.c b/drivers/net/wireless/ath/ar5523/ar5523.c index da2d179430ca..91b524ca3243 100644 --- a/drivers/net/wireless/ath/ar5523/ar5523.c +++ b/drivers/net/wireless/ath/ar5523/ar5523.c @@ -1580,6 +1580,20 @@ static int ar5523_probe(struct usb_interface *intf, struct ar5523 *ar; int error = -ENOMEM; + static const u8 bulk_ep_addr[] = { + AR5523_CMD_TX_PIPE | USB_DIR_OUT, + AR5523_DATA_TX_PIPE | USB_DIR_OUT, + AR5523_CMD_RX_PIPE | USB_DIR_IN, + AR5523_DATA_RX_PIPE | USB_DIR_IN, + 0}; + + if (!usb_check_bulk_endpoints(intf, bulk_ep_addr)) { + dev_err(&dev->dev, + "Could not find all expected endpoints\n"); + error = -ENODEV; + goto out; + } + /* * Load firmware if the device requires it. This will return * -ENXIO on success and we'll get called back afer the usb -- 2.25.1

2 1