-
Notifications
You must be signed in to change notification settings - Fork 57.8k
Golden cats love to play in the sun. Merge pull request #1 from torvalds/master #404
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Files changed 272
Hi @Kittybangers! Thanks for your contribution to the Linux kernel! Linux kernel development happens on mailing lists, rather than on GitHub - this GitHub repository is a read-only mirror that isn't used for accepting contributions. So that your change can become part of Linux, please email it to us as a patch. Sending patches isn't quite as simple as sending a pull request, but fortunately it is a well documented process. Here's what to do:
How do I format my contribution?The Linux kernel community is notoriously picky about how contributions are formatted and sent. Fortunately, they have documented their expectations. Firstly, all contributions need to be formatted as patches. A patch is a plain text document showing the change you want to make to the code, and documenting why it is a good idea. You can create patches with Secondly, patches need 'commit messages', which is the human-friendly documentation explaining what the change is and why it's necessary. Thirdly, changes have some technical requirements. There is a Linux kernel coding style, and there are licensing requirements you need to comply with. Both of these are documented in the Submitting Patches documentation that is part of the kernel. Note that you will almost certainly have to modify your existing git commits to satisfy these requirements. Don't worry: there are many guides on the internet for doing this. Who do I send my contribution to?The Linux kernel is composed of a number of subsystems. These subsystems are maintained by different people, and have different mailing lists where they discuss proposed changes. If you don't already know what subsystem your change belongs to, the
Make sure that your list of recipients includes a mailing list. If you can't find a more specific mailing list, then LKML - the Linux Kernel Mailing List - is the place to send your patches. It's not usually necessary to subscribe to the mailing list before you send the patches, but if you're interested in kernel development, subscribing to a subsystem mailing list is a good idea. (At this point, you probably don't need to subscribe to LKML - it is a very high traffic list with about a thousand messages per day, which is often not useful for beginners.) How do I send my contribution?Use For more information about using How do I get help if I'm stuck?Firstly, don't get discouraged! There are an enormous number of resources on the internet, and many kernel developers who would like to see you succeed. Many issues - especially about how to use certain tools - can be resolved by using your favourite internet search engine. If you can't find an answer, there are a few places you can turn:
If you get really, really stuck, you could try the owners of this bot, @daxtens and @ajdlinux. Please be aware that we do have full-time jobs, so we are almost certainly the slowest way to get answers! I sent my patch - now what?You wait. You can check that your email has been received by checking the mailing list archives for the mailing list you sent your patch to. Messages may not be received instantly, so be patient. Kernel developers are generally very busy people, so it may take a few weeks before your patch is looked at. Then, you keep waiting. Three things may happen:
Further information
Happy hacking! This message was posted by a bot - if you have any questions or suggestions, please talk to my owners, @ajdlinux and @daxtens, or raise an issue at https://github.com/ajdlinux/KernelPRBot. |
Fix valgrind nightly test
Because of both sides doing L2CAP disconnection at the same time, it was possible to receive L2CAP Disconnection Response with CID that was already freed. That caused problems if CID was already reused and L2CAP Connection Request with same CID was sent out. Before this patch kernel deleted channel context regardless of the state of the channel. Example where leftover Disconnection Response (frame torvalds#402) causes local device to delete L2CAP channel which was not yet connected. This in turn confuses remote device's stack because same CID is re-used without properly disconnecting. Btmon capture before patch: ** snip ** > ACL Data RX: Handle 43 flags 0x02 dlen 8 torvalds#394 [hci1] 10.748949 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 torvalds#395 [hci1] 10.749062 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#396 [hci1] 10.749073 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#397 [hci1] 10.752391 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#398 [hci1] 10.753394 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#399 [hci1] 10.756499 L2CAP: Disconnection Request (0x06) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#400 [hci1] 10.756548 L2CAP: Disconnection Response (0x07) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#401 [hci1] 10.757459 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#402 [hci1] 10.759148 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o.. 10.759447 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#403 [hci1] 10.759386 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#404 [hci1] 10.760397 L2CAP: Connection Request (0x02) ident 27 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 torvalds#405 [hci1] 10.760441 L2CAP: Connection Response (0x03) ident 27 len 8 Destination CID: 65 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 torvalds#406 [hci1] 10.760449 L2CAP: Configure Request (0x04) ident 19 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#407 [hci1] 10.761399 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 16 torvalds#408 [hci1] 10.762942 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Similar case after the patch: *snip* > ACL Data RX: Handle 43 flags 0x02 dlen 8 #22702 [hci0] 1664.411056 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #22703 [hci0] 1664.411136 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22704 [hci0] 1664.411143 L2CAP: Disconnection Request (0x06) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22705 [hci0] 1664.414009 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22706 [hci0] 1664.415007 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22707 [hci0] 1664.418674 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22708 [hci0] 1664.418762 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22709 [hci0] 1664.421073 L2CAP: Connection Request (0x02) ident 12 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22710 [hci0] 1664.421371 L2CAP: Disconnection Response (0x07) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22711 [hci0] 1664.424082 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22712 [hci0] 1664.425040 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22713 [hci0] 1664.426103 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #22714 [hci0] 1664.426186 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #22715 [hci0] 1664.426196 L2CAP: Configure Request (0x04) ident 13 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #22716 [hci0] 1664.428804 L2CAP: Connection Response (0x03) ident 12 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Fix is to check that channel is in state BT_DISCONN before deleting the channel. This bug was found while fuzzing Bluez's OBEX implementation using Synopsys Defensics. Reported-by: Matti Kamunen <matti.kamunen@synopsys.com> Reported-by: Ari Timonen <ari.timonen@synopsys.com> Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com>
Because of both sides doing L2CAP disconnection at the same time, it was possible to receive L2CAP Disconnection Response with CID that was already freed. That caused problems if CID was already reused and L2CAP Connection Request with same CID was sent out. Before this patch kernel deleted channel context regardless of the state of the channel. Example where leftover Disconnection Response (frame torvalds#402) causes local device to delete L2CAP channel which was not yet connected. This in turn confuses remote device's stack because same CID is re-used without properly disconnecting. Btmon capture before patch: ** snip ** > ACL Data RX: Handle 43 flags 0x02 dlen 8 torvalds#394 [hci1] 10.748949 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 torvalds#395 [hci1] 10.749062 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#396 [hci1] 10.749073 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#397 [hci1] 10.752391 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#398 [hci1] 10.753394 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#399 [hci1] 10.756499 L2CAP: Disconnection Request (0x06) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#400 [hci1] 10.756548 L2CAP: Disconnection Response (0x07) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#401 [hci1] 10.757459 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#402 [hci1] 10.759148 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o.. 10.759447 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#403 [hci1] 10.759386 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#404 [hci1] 10.760397 L2CAP: Connection Request (0x02) ident 27 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 torvalds#405 [hci1] 10.760441 L2CAP: Connection Response (0x03) ident 27 len 8 Destination CID: 65 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 torvalds#406 [hci1] 10.760449 L2CAP: Configure Request (0x04) ident 19 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#407 [hci1] 10.761399 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 16 torvalds#408 [hci1] 10.762942 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Similar case after the patch: *snip* > ACL Data RX: Handle 43 flags 0x02 dlen 8 #22702 [hci0] 1664.411056 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #22703 [hci0] 1664.411136 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22704 [hci0] 1664.411143 L2CAP: Disconnection Request (0x06) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22705 [hci0] 1664.414009 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22706 [hci0] 1664.415007 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22707 [hci0] 1664.418674 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22708 [hci0] 1664.418762 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22709 [hci0] 1664.421073 L2CAP: Connection Request (0x02) ident 12 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22710 [hci0] 1664.421371 L2CAP: Disconnection Response (0x07) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22711 [hci0] 1664.424082 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22712 [hci0] 1664.425040 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22713 [hci0] 1664.426103 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #22714 [hci0] 1664.426186 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #22715 [hci0] 1664.426196 L2CAP: Configure Request (0x04) ident 13 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #22716 [hci0] 1664.428804 L2CAP: Connection Response (0x03) ident 12 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Fix is to check that channel is in state BT_DISCONN before deleting the channel. This bug was found while fuzzing Bluez's OBEX implementation using Synopsys Defensics. Reported-by: Matti Kamunen <matti.kamunen@synopsys.com> Reported-by: Ari Timonen <ari.timonen@synopsys.com> Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
[ Upstream commit 28261da ] Because of both sides doing L2CAP disconnection at the same time, it was possible to receive L2CAP Disconnection Response with CID that was already freed. That caused problems if CID was already reused and L2CAP Connection Request with same CID was sent out. Before this patch kernel deleted channel context regardless of the state of the channel. Example where leftover Disconnection Response (frame torvalds#402) causes local device to delete L2CAP channel which was not yet connected. This in turn confuses remote device's stack because same CID is re-used without properly disconnecting. Btmon capture before patch: ** snip ** > ACL Data RX: Handle 43 flags 0x02 dlen 8 torvalds#394 [hci1] 10.748949 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 torvalds#395 [hci1] 10.749062 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#396 [hci1] 10.749073 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#397 [hci1] 10.752391 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#398 [hci1] 10.753394 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#399 [hci1] 10.756499 L2CAP: Disconnection Request (0x06) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#400 [hci1] 10.756548 L2CAP: Disconnection Response (0x07) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#401 [hci1] 10.757459 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#402 [hci1] 10.759148 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o.. 10.759447 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#403 [hci1] 10.759386 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#404 [hci1] 10.760397 L2CAP: Connection Request (0x02) ident 27 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 torvalds#405 [hci1] 10.760441 L2CAP: Connection Response (0x03) ident 27 len 8 Destination CID: 65 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 torvalds#406 [hci1] 10.760449 L2CAP: Configure Request (0x04) ident 19 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#407 [hci1] 10.761399 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 16 torvalds#408 [hci1] 10.762942 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Similar case after the patch: *snip* > ACL Data RX: Handle 43 flags 0x02 dlen 8 #22702 [hci0] 1664.411056 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #22703 [hci0] 1664.411136 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22704 [hci0] 1664.411143 L2CAP: Disconnection Request (0x06) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22705 [hci0] 1664.414009 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22706 [hci0] 1664.415007 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22707 [hci0] 1664.418674 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22708 [hci0] 1664.418762 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22709 [hci0] 1664.421073 L2CAP: Connection Request (0x02) ident 12 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22710 [hci0] 1664.421371 L2CAP: Disconnection Response (0x07) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22711 [hci0] 1664.424082 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22712 [hci0] 1664.425040 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22713 [hci0] 1664.426103 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #22714 [hci0] 1664.426186 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #22715 [hci0] 1664.426196 L2CAP: Configure Request (0x04) ident 13 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #22716 [hci0] 1664.428804 L2CAP: Connection Response (0x03) ident 12 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Fix is to check that channel is in state BT_DISCONN before deleting the channel. This bug was found while fuzzing Bluez's OBEX implementation using Synopsys Defensics. Reported-by: Matti Kamunen <matti.kamunen@synopsys.com> Reported-by: Ari Timonen <ari.timonen@synopsys.com> Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 28261da ] Because of both sides doing L2CAP disconnection at the same time, it was possible to receive L2CAP Disconnection Response with CID that was already freed. That caused problems if CID was already reused and L2CAP Connection Request with same CID was sent out. Before this patch kernel deleted channel context regardless of the state of the channel. Example where leftover Disconnection Response (frame torvalds#402) causes local device to delete L2CAP channel which was not yet connected. This in turn confuses remote device's stack because same CID is re-used without properly disconnecting. Btmon capture before patch: ** snip ** > ACL Data RX: Handle 43 flags 0x02 dlen 8 torvalds#394 [hci1] 10.748949 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 torvalds#395 [hci1] 10.749062 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#396 [hci1] 10.749073 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#397 [hci1] 10.752391 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#398 [hci1] 10.753394 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#399 [hci1] 10.756499 L2CAP: Disconnection Request (0x06) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#400 [hci1] 10.756548 L2CAP: Disconnection Response (0x07) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#401 [hci1] 10.757459 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#402 [hci1] 10.759148 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o.. 10.759447 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#403 [hci1] 10.759386 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#404 [hci1] 10.760397 L2CAP: Connection Request (0x02) ident 27 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 torvalds#405 [hci1] 10.760441 L2CAP: Connection Response (0x03) ident 27 len 8 Destination CID: 65 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 torvalds#406 [hci1] 10.760449 L2CAP: Configure Request (0x04) ident 19 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#407 [hci1] 10.761399 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 16 torvalds#408 [hci1] 10.762942 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Similar case after the patch: *snip* > ACL Data RX: Handle 43 flags 0x02 dlen 8 #22702 [hci0] 1664.411056 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #22703 [hci0] 1664.411136 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22704 [hci0] 1664.411143 L2CAP: Disconnection Request (0x06) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22705 [hci0] 1664.414009 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22706 [hci0] 1664.415007 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22707 [hci0] 1664.418674 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22708 [hci0] 1664.418762 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22709 [hci0] 1664.421073 L2CAP: Connection Request (0x02) ident 12 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22710 [hci0] 1664.421371 L2CAP: Disconnection Response (0x07) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22711 [hci0] 1664.424082 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22712 [hci0] 1664.425040 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22713 [hci0] 1664.426103 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #22714 [hci0] 1664.426186 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #22715 [hci0] 1664.426196 L2CAP: Configure Request (0x04) ident 13 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #22716 [hci0] 1664.428804 L2CAP: Connection Response (0x03) ident 12 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Fix is to check that channel is in state BT_DISCONN before deleting the channel. This bug was found while fuzzing Bluez's OBEX implementation using Synopsys Defensics. Reported-by: Matti Kamunen <matti.kamunen@synopsys.com> Reported-by: Ari Timonen <ari.timonen@synopsys.com> Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 28261da ] Because of both sides doing L2CAP disconnection at the same time, it was possible to receive L2CAP Disconnection Response with CID that was already freed. That caused problems if CID was already reused and L2CAP Connection Request with same CID was sent out. Before this patch kernel deleted channel context regardless of the state of the channel. Example where leftover Disconnection Response (frame torvalds#402) causes local device to delete L2CAP channel which was not yet connected. This in turn confuses remote device's stack because same CID is re-used without properly disconnecting. Btmon capture before patch: ** snip ** > ACL Data RX: Handle 43 flags 0x02 dlen 8 torvalds#394 [hci1] 10.748949 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 torvalds#395 [hci1] 10.749062 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#396 [hci1] 10.749073 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#397 [hci1] 10.752391 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#398 [hci1] 10.753394 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#399 [hci1] 10.756499 L2CAP: Disconnection Request (0x06) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#400 [hci1] 10.756548 L2CAP: Disconnection Response (0x07) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#401 [hci1] 10.757459 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#402 [hci1] 10.759148 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o.. 10.759447 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#403 [hci1] 10.759386 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#404 [hci1] 10.760397 L2CAP: Connection Request (0x02) ident 27 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 torvalds#405 [hci1] 10.760441 L2CAP: Connection Response (0x03) ident 27 len 8 Destination CID: 65 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 torvalds#406 [hci1] 10.760449 L2CAP: Configure Request (0x04) ident 19 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#407 [hci1] 10.761399 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 16 torvalds#408 [hci1] 10.762942 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Similar case after the patch: *snip* > ACL Data RX: Handle 43 flags 0x02 dlen 8 #22702 [hci0] 1664.411056 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #22703 [hci0] 1664.411136 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22704 [hci0] 1664.411143 L2CAP: Disconnection Request (0x06) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22705 [hci0] 1664.414009 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22706 [hci0] 1664.415007 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22707 [hci0] 1664.418674 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22708 [hci0] 1664.418762 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22709 [hci0] 1664.421073 L2CAP: Connection Request (0x02) ident 12 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22710 [hci0] 1664.421371 L2CAP: Disconnection Response (0x07) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22711 [hci0] 1664.424082 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22712 [hci0] 1664.425040 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22713 [hci0] 1664.426103 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #22714 [hci0] 1664.426186 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #22715 [hci0] 1664.426196 L2CAP: Configure Request (0x04) ident 13 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #22716 [hci0] 1664.428804 L2CAP: Connection Response (0x03) ident 12 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Fix is to check that channel is in state BT_DISCONN before deleting the channel. This bug was found while fuzzing Bluez's OBEX implementation using Synopsys Defensics. Reported-by: Matti Kamunen <matti.kamunen@synopsys.com> Reported-by: Ari Timonen <ari.timonen@synopsys.com> Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 28261da ] Because of both sides doing L2CAP disconnection at the same time, it was possible to receive L2CAP Disconnection Response with CID that was already freed. That caused problems if CID was already reused and L2CAP Connection Request with same CID was sent out. Before this patch kernel deleted channel context regardless of the state of the channel. Example where leftover Disconnection Response (frame torvalds#402) causes local device to delete L2CAP channel which was not yet connected. This in turn confuses remote device's stack because same CID is re-used without properly disconnecting. Btmon capture before patch: ** snip ** > ACL Data RX: Handle 43 flags 0x02 dlen 8 torvalds#394 [hci1] 10.748949 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 torvalds#395 [hci1] 10.749062 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#396 [hci1] 10.749073 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#397 [hci1] 10.752391 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#398 [hci1] 10.753394 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#399 [hci1] 10.756499 L2CAP: Disconnection Request (0x06) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#400 [hci1] 10.756548 L2CAP: Disconnection Response (0x07) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#401 [hci1] 10.757459 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#402 [hci1] 10.759148 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o.. 10.759447 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#403 [hci1] 10.759386 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#404 [hci1] 10.760397 L2CAP: Connection Request (0x02) ident 27 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 torvalds#405 [hci1] 10.760441 L2CAP: Connection Response (0x03) ident 27 len 8 Destination CID: 65 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 torvalds#406 [hci1] 10.760449 L2CAP: Configure Request (0x04) ident 19 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#407 [hci1] 10.761399 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 16 torvalds#408 [hci1] 10.762942 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Similar case after the patch: *snip* > ACL Data RX: Handle 43 flags 0x02 dlen 8 #22702 [hci0] 1664.411056 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #22703 [hci0] 1664.411136 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22704 [hci0] 1664.411143 L2CAP: Disconnection Request (0x06) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22705 [hci0] 1664.414009 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22706 [hci0] 1664.415007 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22707 [hci0] 1664.418674 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22708 [hci0] 1664.418762 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22709 [hci0] 1664.421073 L2CAP: Connection Request (0x02) ident 12 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22710 [hci0] 1664.421371 L2CAP: Disconnection Response (0x07) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22711 [hci0] 1664.424082 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22712 [hci0] 1664.425040 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22713 [hci0] 1664.426103 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #22714 [hci0] 1664.426186 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #22715 [hci0] 1664.426196 L2CAP: Configure Request (0x04) ident 13 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #22716 [hci0] 1664.428804 L2CAP: Connection Response (0x03) ident 12 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Fix is to check that channel is in state BT_DISCONN before deleting the channel. This bug was found while fuzzing Bluez's OBEX implementation using Synopsys Defensics. Reported-by: Matti Kamunen <matti.kamunen@synopsys.com> Reported-by: Ari Timonen <ari.timonen@synopsys.com> Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 28261da ] Because of both sides doing L2CAP disconnection at the same time, it was possible to receive L2CAP Disconnection Response with CID that was already freed. That caused problems if CID was already reused and L2CAP Connection Request with same CID was sent out. Before this patch kernel deleted channel context regardless of the state of the channel. Example where leftover Disconnection Response (frame torvalds#402) causes local device to delete L2CAP channel which was not yet connected. This in turn confuses remote device's stack because same CID is re-used without properly disconnecting. Btmon capture before patch: ** snip ** > ACL Data RX: Handle 43 flags 0x02 dlen 8 torvalds#394 [hci1] 10.748949 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 torvalds#395 [hci1] 10.749062 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#396 [hci1] 10.749073 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#397 [hci1] 10.752391 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#398 [hci1] 10.753394 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#399 [hci1] 10.756499 L2CAP: Disconnection Request (0x06) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#400 [hci1] 10.756548 L2CAP: Disconnection Response (0x07) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#401 [hci1] 10.757459 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#402 [hci1] 10.759148 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o.. 10.759447 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#403 [hci1] 10.759386 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#404 [hci1] 10.760397 L2CAP: Connection Request (0x02) ident 27 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 torvalds#405 [hci1] 10.760441 L2CAP: Connection Response (0x03) ident 27 len 8 Destination CID: 65 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 torvalds#406 [hci1] 10.760449 L2CAP: Configure Request (0x04) ident 19 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#407 [hci1] 10.761399 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 16 torvalds#408 [hci1] 10.762942 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Similar case after the patch: *snip* > ACL Data RX: Handle 43 flags 0x02 dlen 8 #22702 [hci0] 1664.411056 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #22703 [hci0] 1664.411136 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22704 [hci0] 1664.411143 L2CAP: Disconnection Request (0x06) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22705 [hci0] 1664.414009 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22706 [hci0] 1664.415007 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22707 [hci0] 1664.418674 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22708 [hci0] 1664.418762 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22709 [hci0] 1664.421073 L2CAP: Connection Request (0x02) ident 12 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22710 [hci0] 1664.421371 L2CAP: Disconnection Response (0x07) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22711 [hci0] 1664.424082 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22712 [hci0] 1664.425040 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22713 [hci0] 1664.426103 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #22714 [hci0] 1664.426186 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #22715 [hci0] 1664.426196 L2CAP: Configure Request (0x04) ident 13 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #22716 [hci0] 1664.428804 L2CAP: Connection Response (0x03) ident 12 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Fix is to check that channel is in state BT_DISCONN before deleting the channel. This bug was found while fuzzing Bluez's OBEX implementation using Synopsys Defensics. Reported-by: Matti Kamunen <matti.kamunen@synopsys.com> Reported-by: Ari Timonen <ari.timonen@synopsys.com> Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 28261da ] Because of both sides doing L2CAP disconnection at the same time, it was possible to receive L2CAP Disconnection Response with CID that was already freed. That caused problems if CID was already reused and L2CAP Connection Request with same CID was sent out. Before this patch kernel deleted channel context regardless of the state of the channel. Example where leftover Disconnection Response (frame torvalds#402) causes local device to delete L2CAP channel which was not yet connected. This in turn confuses remote device's stack because same CID is re-used without properly disconnecting. Btmon capture before patch: ** snip ** > ACL Data RX: Handle 43 flags 0x02 dlen 8 torvalds#394 [hci1] 10.748949 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 torvalds#395 [hci1] 10.749062 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#396 [hci1] 10.749073 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#397 [hci1] 10.752391 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#398 [hci1] 10.753394 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#399 [hci1] 10.756499 L2CAP: Disconnection Request (0x06) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#400 [hci1] 10.756548 L2CAP: Disconnection Response (0x07) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#401 [hci1] 10.757459 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#402 [hci1] 10.759148 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o.. 10.759447 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#403 [hci1] 10.759386 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#404 [hci1] 10.760397 L2CAP: Connection Request (0x02) ident 27 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 torvalds#405 [hci1] 10.760441 L2CAP: Connection Response (0x03) ident 27 len 8 Destination CID: 65 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 torvalds#406 [hci1] 10.760449 L2CAP: Configure Request (0x04) ident 19 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#407 [hci1] 10.761399 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 16 torvalds#408 [hci1] 10.762942 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Similar case after the patch: *snip* > ACL Data RX: Handle 43 flags 0x02 dlen 8 #22702 [hci0] 1664.411056 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #22703 [hci0] 1664.411136 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22704 [hci0] 1664.411143 L2CAP: Disconnection Request (0x06) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22705 [hci0] 1664.414009 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22706 [hci0] 1664.415007 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22707 [hci0] 1664.418674 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22708 [hci0] 1664.418762 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22709 [hci0] 1664.421073 L2CAP: Connection Request (0x02) ident 12 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22710 [hci0] 1664.421371 L2CAP: Disconnection Response (0x07) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22711 [hci0] 1664.424082 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22712 [hci0] 1664.425040 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22713 [hci0] 1664.426103 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #22714 [hci0] 1664.426186 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #22715 [hci0] 1664.426196 L2CAP: Configure Request (0x04) ident 13 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #22716 [hci0] 1664.428804 L2CAP: Connection Response (0x03) ident 12 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Fix is to check that channel is in state BT_DISCONN before deleting the channel. This bug was found while fuzzing Bluez's OBEX implementation using Synopsys Defensics. Reported-by: Matti Kamunen <matti.kamunen@synopsys.com> Reported-by: Ari Timonen <ari.timonen@synopsys.com> Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 28261da ] Because of both sides doing L2CAP disconnection at the same time, it was possible to receive L2CAP Disconnection Response with CID that was already freed. That caused problems if CID was already reused and L2CAP Connection Request with same CID was sent out. Before this patch kernel deleted channel context regardless of the state of the channel. Example where leftover Disconnection Response (frame torvalds#402) causes local device to delete L2CAP channel which was not yet connected. This in turn confuses remote device's stack because same CID is re-used without properly disconnecting. Btmon capture before patch: ** snip ** > ACL Data RX: Handle 43 flags 0x02 dlen 8 torvalds#394 [hci1] 10.748949 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 torvalds#395 [hci1] 10.749062 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#396 [hci1] 10.749073 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#397 [hci1] 10.752391 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#398 [hci1] 10.753394 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#399 [hci1] 10.756499 L2CAP: Disconnection Request (0x06) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#400 [hci1] 10.756548 L2CAP: Disconnection Response (0x07) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#401 [hci1] 10.757459 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#402 [hci1] 10.759148 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o.. 10.759447 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#403 [hci1] 10.759386 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#404 [hci1] 10.760397 L2CAP: Connection Request (0x02) ident 27 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 torvalds#405 [hci1] 10.760441 L2CAP: Connection Response (0x03) ident 27 len 8 Destination CID: 65 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 torvalds#406 [hci1] 10.760449 L2CAP: Configure Request (0x04) ident 19 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#407 [hci1] 10.761399 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 16 torvalds#408 [hci1] 10.762942 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Similar case after the patch: *snip* > ACL Data RX: Handle 43 flags 0x02 dlen 8 #22702 [hci0] 1664.411056 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #22703 [hci0] 1664.411136 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22704 [hci0] 1664.411143 L2CAP: Disconnection Request (0x06) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22705 [hci0] 1664.414009 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22706 [hci0] 1664.415007 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22707 [hci0] 1664.418674 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22708 [hci0] 1664.418762 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22709 [hci0] 1664.421073 L2CAP: Connection Request (0x02) ident 12 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22710 [hci0] 1664.421371 L2CAP: Disconnection Response (0x07) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22711 [hci0] 1664.424082 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22712 [hci0] 1664.425040 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22713 [hci0] 1664.426103 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #22714 [hci0] 1664.426186 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #22715 [hci0] 1664.426196 L2CAP: Configure Request (0x04) ident 13 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #22716 [hci0] 1664.428804 L2CAP: Connection Response (0x03) ident 12 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Fix is to check that channel is in state BT_DISCONN before deleting the channel. This bug was found while fuzzing Bluez's OBEX implementation using Synopsys Defensics. Reported-by: Matti Kamunen <matti.kamunen@synopsys.com> Reported-by: Ari Timonen <ari.timonen@synopsys.com> Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 28261da ] Because of both sides doing L2CAP disconnection at the same time, it was possible to receive L2CAP Disconnection Response with CID that was already freed. That caused problems if CID was already reused and L2CAP Connection Request with same CID was sent out. Before this patch kernel deleted channel context regardless of the state of the channel. Example where leftover Disconnection Response (frame torvalds#402) causes local device to delete L2CAP channel which was not yet connected. This in turn confuses remote device's stack because same CID is re-used without properly disconnecting. Btmon capture before patch: ** snip ** > ACL Data RX: Handle 43 flags 0x02 dlen 8 torvalds#394 [hci1] 10.748949 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 torvalds#395 [hci1] 10.749062 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#396 [hci1] 10.749073 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#397 [hci1] 10.752391 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#398 [hci1] 10.753394 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#399 [hci1] 10.756499 L2CAP: Disconnection Request (0x06) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#400 [hci1] 10.756548 L2CAP: Disconnection Response (0x07) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#401 [hci1] 10.757459 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#402 [hci1] 10.759148 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o.. 10.759447 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#403 [hci1] 10.759386 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#404 [hci1] 10.760397 L2CAP: Connection Request (0x02) ident 27 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 torvalds#405 [hci1] 10.760441 L2CAP: Connection Response (0x03) ident 27 len 8 Destination CID: 65 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 torvalds#406 [hci1] 10.760449 L2CAP: Configure Request (0x04) ident 19 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#407 [hci1] 10.761399 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 16 torvalds#408 [hci1] 10.762942 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Similar case after the patch: *snip* > ACL Data RX: Handle 43 flags 0x02 dlen 8 #22702 [hci0] 1664.411056 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #22703 [hci0] 1664.411136 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22704 [hci0] 1664.411143 L2CAP: Disconnection Request (0x06) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22705 [hci0] 1664.414009 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22706 [hci0] 1664.415007 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22707 [hci0] 1664.418674 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22708 [hci0] 1664.418762 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22709 [hci0] 1664.421073 L2CAP: Connection Request (0x02) ident 12 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22710 [hci0] 1664.421371 L2CAP: Disconnection Response (0x07) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22711 [hci0] 1664.424082 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22712 [hci0] 1664.425040 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22713 [hci0] 1664.426103 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #22714 [hci0] 1664.426186 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #22715 [hci0] 1664.426196 L2CAP: Configure Request (0x04) ident 13 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #22716 [hci0] 1664.428804 L2CAP: Connection Response (0x03) ident 12 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Fix is to check that channel is in state BT_DISCONN before deleting the channel. This bug was found while fuzzing Bluez's OBEX implementation using Synopsys Defensics. Reported-by: Matti Kamunen <matti.kamunen@synopsys.com> Reported-by: Ari Timonen <ari.timonen@synopsys.com> Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 28261da ] Because of both sides doing L2CAP disconnection at the same time, it was possible to receive L2CAP Disconnection Response with CID that was already freed. That caused problems if CID was already reused and L2CAP Connection Request with same CID was sent out. Before this patch kernel deleted channel context regardless of the state of the channel. Example where leftover Disconnection Response (frame torvalds#402) causes local device to delete L2CAP channel which was not yet connected. This in turn confuses remote device's stack because same CID is re-used without properly disconnecting. Btmon capture before patch: ** snip ** > ACL Data RX: Handle 43 flags 0x02 dlen 8 torvalds#394 [hci1] 10.748949 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 torvalds#395 [hci1] 10.749062 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#396 [hci1] 10.749073 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#397 [hci1] 10.752391 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#398 [hci1] 10.753394 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#399 [hci1] 10.756499 L2CAP: Disconnection Request (0x06) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#400 [hci1] 10.756548 L2CAP: Disconnection Response (0x07) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#401 [hci1] 10.757459 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#402 [hci1] 10.759148 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o.. 10.759447 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#403 [hci1] 10.759386 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#404 [hci1] 10.760397 L2CAP: Connection Request (0x02) ident 27 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 torvalds#405 [hci1] 10.760441 L2CAP: Connection Response (0x03) ident 27 len 8 Destination CID: 65 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 torvalds#406 [hci1] 10.760449 L2CAP: Configure Request (0x04) ident 19 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#407 [hci1] 10.761399 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 16 torvalds#408 [hci1] 10.762942 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Similar case after the patch: *snip* > ACL Data RX: Handle 43 flags 0x02 dlen 8 #22702 [hci0] 1664.411056 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #22703 [hci0] 1664.411136 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22704 [hci0] 1664.411143 L2CAP: Disconnection Request (0x06) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22705 [hci0] 1664.414009 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22706 [hci0] 1664.415007 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22707 [hci0] 1664.418674 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22708 [hci0] 1664.418762 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22709 [hci0] 1664.421073 L2CAP: Connection Request (0x02) ident 12 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22710 [hci0] 1664.421371 L2CAP: Disconnection Response (0x07) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22711 [hci0] 1664.424082 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22712 [hci0] 1664.425040 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22713 [hci0] 1664.426103 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #22714 [hci0] 1664.426186 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #22715 [hci0] 1664.426196 L2CAP: Configure Request (0x04) ident 13 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #22716 [hci0] 1664.428804 L2CAP: Connection Response (0x03) ident 12 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Fix is to check that channel is in state BT_DISCONN before deleting the channel. This bug was found while fuzzing Bluez's OBEX implementation using Synopsys Defensics. Reported-by: Matti Kamunen <matti.kamunen@synopsys.com> Reported-by: Ari Timonen <ari.timonen@synopsys.com> Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 28261da ] Because of both sides doing L2CAP disconnection at the same time, it was possible to receive L2CAP Disconnection Response with CID that was already freed. That caused problems if CID was already reused and L2CAP Connection Request with same CID was sent out. Before this patch kernel deleted channel context regardless of the state of the channel. Example where leftover Disconnection Response (frame torvalds#402) causes local device to delete L2CAP channel which was not yet connected. This in turn confuses remote device's stack because same CID is re-used without properly disconnecting. Btmon capture before patch: ** snip ** > ACL Data RX: Handle 43 flags 0x02 dlen 8 torvalds#394 [hci1] 10.748949 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 torvalds#395 [hci1] 10.749062 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#396 [hci1] 10.749073 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#397 [hci1] 10.752391 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#398 [hci1] 10.753394 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#399 [hci1] 10.756499 L2CAP: Disconnection Request (0x06) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#400 [hci1] 10.756548 L2CAP: Disconnection Response (0x07) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#401 [hci1] 10.757459 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#402 [hci1] 10.759148 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o.. 10.759447 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#403 [hci1] 10.759386 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#404 [hci1] 10.760397 L2CAP: Connection Request (0x02) ident 27 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 torvalds#405 [hci1] 10.760441 L2CAP: Connection Response (0x03) ident 27 len 8 Destination CID: 65 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 torvalds#406 [hci1] 10.760449 L2CAP: Configure Request (0x04) ident 19 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#407 [hci1] 10.761399 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 16 torvalds#408 [hci1] 10.762942 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Similar case after the patch: *snip* > ACL Data RX: Handle 43 flags 0x02 dlen 8 #22702 [hci0] 1664.411056 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #22703 [hci0] 1664.411136 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22704 [hci0] 1664.411143 L2CAP: Disconnection Request (0x06) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22705 [hci0] 1664.414009 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22706 [hci0] 1664.415007 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22707 [hci0] 1664.418674 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22708 [hci0] 1664.418762 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22709 [hci0] 1664.421073 L2CAP: Connection Request (0x02) ident 12 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22710 [hci0] 1664.421371 L2CAP: Disconnection Response (0x07) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22711 [hci0] 1664.424082 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22712 [hci0] 1664.425040 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22713 [hci0] 1664.426103 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #22714 [hci0] 1664.426186 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #22715 [hci0] 1664.426196 L2CAP: Configure Request (0x04) ident 13 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #22716 [hci0] 1664.428804 L2CAP: Connection Response (0x03) ident 12 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Fix is to check that channel is in state BT_DISCONN before deleting the channel. This bug was found while fuzzing Bluez's OBEX implementation using Synopsys Defensics. Reported-by: Matti Kamunen <matti.kamunen@synopsys.com> Reported-by: Ari Timonen <ari.timonen@synopsys.com> Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 28261da ] Because of both sides doing L2CAP disconnection at the same time, it was possible to receive L2CAP Disconnection Response with CID that was already freed. That caused problems if CID was already reused and L2CAP Connection Request with same CID was sent out. Before this patch kernel deleted channel context regardless of the state of the channel. Example where leftover Disconnection Response (frame torvalds#402) causes local device to delete L2CAP channel which was not yet connected. This in turn confuses remote device's stack because same CID is re-used without properly disconnecting. Btmon capture before patch: ** snip ** > ACL Data RX: Handle 43 flags 0x02 dlen 8 #394 [hci1] 10.748949 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #395 [hci1] 10.749062 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #396 [hci1] 10.749073 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#397 [hci1] 10.752391 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#398 [hci1] 10.753394 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#399 [hci1] 10.756499 L2CAP: Disconnection Request (0x06) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#400 [hci1] 10.756548 L2CAP: Disconnection Response (0x07) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#401 [hci1] 10.757459 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#402 [hci1] 10.759148 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o.. 10.759447 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#403 [hci1] 10.759386 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#404 [hci1] 10.760397 L2CAP: Connection Request (0x02) ident 27 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 torvalds#405 [hci1] 10.760441 L2CAP: Connection Response (0x03) ident 27 len 8 Destination CID: 65 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 torvalds#406 [hci1] 10.760449 L2CAP: Configure Request (0x04) ident 19 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#407 [hci1] 10.761399 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 16 torvalds#408 [hci1] 10.762942 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Similar case after the patch: *snip* > ACL Data RX: Handle 43 flags 0x02 dlen 8 #22702 [hci0] 1664.411056 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #22703 [hci0] 1664.411136 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22704 [hci0] 1664.411143 L2CAP: Disconnection Request (0x06) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22705 [hci0] 1664.414009 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22706 [hci0] 1664.415007 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22707 [hci0] 1664.418674 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22708 [hci0] 1664.418762 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22709 [hci0] 1664.421073 L2CAP: Connection Request (0x02) ident 12 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22710 [hci0] 1664.421371 L2CAP: Disconnection Response (0x07) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22711 [hci0] 1664.424082 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22712 [hci0] 1664.425040 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22713 [hci0] 1664.426103 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #22714 [hci0] 1664.426186 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #22715 [hci0] 1664.426196 L2CAP: Configure Request (0x04) ident 13 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #22716 [hci0] 1664.428804 L2CAP: Connection Response (0x03) ident 12 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Fix is to check that channel is in state BT_DISCONN before deleting the channel. This bug was found while fuzzing Bluez's OBEX implementation using Synopsys Defensics. Reported-by: Matti Kamunen <matti.kamunen@synopsys.com> Reported-by: Ari Timonen <ari.timonen@synopsys.com> Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 28261da ] Because of both sides doing L2CAP disconnection at the same time, it was possible to receive L2CAP Disconnection Response with CID that was already freed. That caused problems if CID was already reused and L2CAP Connection Request with same CID was sent out. Before this patch kernel deleted channel context regardless of the state of the channel. Example where leftover Disconnection Response (frame #402) causes local device to delete L2CAP channel which was not yet connected. This in turn confuses remote device's stack because same CID is re-used without properly disconnecting. Btmon capture before patch: ** snip ** > ACL Data RX: Handle 43 flags 0x02 dlen 8 #394 [hci1] 10.748949 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #395 [hci1] 10.749062 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #396 [hci1] 10.749073 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 #397 [hci1] 10.752391 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 #398 [hci1] 10.753394 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #399 [hci1] 10.756499 L2CAP: Disconnection Request (0x06) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #400 [hci1] 10.756548 L2CAP: Disconnection Response (0x07) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #401 [hci1] 10.757459 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #402 [hci1] 10.759148 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o.. 10.759447 > HCI Event: Number of Completed Packets (0x13) plen 5 #403 [hci1] 10.759386 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #404 [hci1] 10.760397 L2CAP: Connection Request (0x02) ident 27 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #405 [hci1] 10.760441 L2CAP: Connection Response (0x03) ident 27 len 8 Destination CID: 65 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #406 [hci1] 10.760449 L2CAP: Configure Request (0x04) ident 19 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > HCI Event: Number of Completed Packets (0x13) plen 5 #407 [hci1] 10.761399 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #408 [hci1] 10.762942 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Similar case after the patch: *snip* > ACL Data RX: Handle 43 flags 0x02 dlen 8 #22702 [hci0] 1664.411056 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #22703 [hci0] 1664.411136 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22704 [hci0] 1664.411143 L2CAP: Disconnection Request (0x06) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22705 [hci0] 1664.414009 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22706 [hci0] 1664.415007 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22707 [hci0] 1664.418674 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22708 [hci0] 1664.418762 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22709 [hci0] 1664.421073 L2CAP: Connection Request (0x02) ident 12 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22710 [hci0] 1664.421371 L2CAP: Disconnection Response (0x07) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22711 [hci0] 1664.424082 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22712 [hci0] 1664.425040 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22713 [hci0] 1664.426103 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #22714 [hci0] 1664.426186 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #22715 [hci0] 1664.426196 L2CAP: Configure Request (0x04) ident 13 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #22716 [hci0] 1664.428804 L2CAP: Connection Response (0x03) ident 12 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Fix is to check that channel is in state BT_DISCONN before deleting the channel. This bug was found while fuzzing Bluez's OBEX implementation using Synopsys Defensics. Reported-by: Matti Kamunen <matti.kamunen@synopsys.com> Reported-by: Ari Timonen <ari.timonen@synopsys.com> Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 28261da ] Because of both sides doing L2CAP disconnection at the same time, it was possible to receive L2CAP Disconnection Response with CID that was already freed. That caused problems if CID was already reused and L2CAP Connection Request with same CID was sent out. Before this patch kernel deleted channel context regardless of the state of the channel. Example where leftover Disconnection Response (frame torvalds#402) causes local device to delete L2CAP channel which was not yet connected. This in turn confuses remote device's stack because same CID is re-used without properly disconnecting. Btmon capture before patch: ** snip ** > ACL Data RX: Handle 43 flags 0x02 dlen 8 torvalds#394 [hci1] 10.748949 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 torvalds#395 [hci1] 10.749062 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#396 [hci1] 10.749073 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#397 [hci1] 10.752391 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#398 [hci1] 10.753394 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#399 [hci1] 10.756499 L2CAP: Disconnection Request (0x06) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#400 [hci1] 10.756548 L2CAP: Disconnection Response (0x07) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#401 [hci1] 10.757459 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#402 [hci1] 10.759148 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o.. 10.759447 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#403 [hci1] 10.759386 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#404 [hci1] 10.760397 L2CAP: Connection Request (0x02) ident 27 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 torvalds#405 [hci1] 10.760441 L2CAP: Connection Response (0x03) ident 27 len 8 Destination CID: 65 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 torvalds#406 [hci1] 10.760449 L2CAP: Configure Request (0x04) ident 19 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#407 [hci1] 10.761399 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 16 torvalds#408 [hci1] 10.762942 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Similar case after the patch: *snip* > ACL Data RX: Handle 43 flags 0x02 dlen 8 #22702 [hci0] 1664.411056 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #22703 [hci0] 1664.411136 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22704 [hci0] 1664.411143 L2CAP: Disconnection Request (0x06) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22705 [hci0] 1664.414009 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22706 [hci0] 1664.415007 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22707 [hci0] 1664.418674 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22708 [hci0] 1664.418762 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22709 [hci0] 1664.421073 L2CAP: Connection Request (0x02) ident 12 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22710 [hci0] 1664.421371 L2CAP: Disconnection Response (0x07) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22711 [hci0] 1664.424082 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22712 [hci0] 1664.425040 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22713 [hci0] 1664.426103 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #22714 [hci0] 1664.426186 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #22715 [hci0] 1664.426196 L2CAP: Configure Request (0x04) ident 13 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #22716 [hci0] 1664.428804 L2CAP: Connection Response (0x03) ident 12 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Fix is to check that channel is in state BT_DISCONN before deleting the channel. This bug was found while fuzzing Bluez's OBEX implementation using Synopsys Defensics. Reported-by: Matti Kamunen <matti.kamunen@synopsys.com> Reported-by: Ari Timonen <ari.timonen@synopsys.com> Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 28261da ] Because of both sides doing L2CAP disconnection at the same time, it was possible to receive L2CAP Disconnection Response with CID that was already freed. That caused problems if CID was already reused and L2CAP Connection Request with same CID was sent out. Before this patch kernel deleted channel context regardless of the state of the channel. Example where leftover Disconnection Response (frame torvalds#402) causes local device to delete L2CAP channel which was not yet connected. This in turn confuses remote device's stack because same CID is re-used without properly disconnecting. Btmon capture before patch: ** snip ** > ACL Data RX: Handle 43 flags 0x02 dlen 8 torvalds#394 [hci1] 10.748949 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 torvalds#395 [hci1] 10.749062 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#396 [hci1] 10.749073 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#397 [hci1] 10.752391 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#398 [hci1] 10.753394 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#399 [hci1] 10.756499 L2CAP: Disconnection Request (0x06) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#400 [hci1] 10.756548 L2CAP: Disconnection Response (0x07) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#401 [hci1] 10.757459 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#402 [hci1] 10.759148 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o.. 10.759447 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#403 [hci1] 10.759386 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#404 [hci1] 10.760397 L2CAP: Connection Request (0x02) ident 27 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 torvalds#405 [hci1] 10.760441 L2CAP: Connection Response (0x03) ident 27 len 8 Destination CID: 65 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 torvalds#406 [hci1] 10.760449 L2CAP: Configure Request (0x04) ident 19 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#407 [hci1] 10.761399 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 16 torvalds#408 [hci1] 10.762942 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Similar case after the patch: *snip* > ACL Data RX: Handle 43 flags 0x02 dlen 8 #22702 [hci0] 1664.411056 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #22703 [hci0] 1664.411136 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22704 [hci0] 1664.411143 L2CAP: Disconnection Request (0x06) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22705 [hci0] 1664.414009 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22706 [hci0] 1664.415007 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22707 [hci0] 1664.418674 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22708 [hci0] 1664.418762 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22709 [hci0] 1664.421073 L2CAP: Connection Request (0x02) ident 12 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22710 [hci0] 1664.421371 L2CAP: Disconnection Response (0x07) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22711 [hci0] 1664.424082 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22712 [hci0] 1664.425040 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22713 [hci0] 1664.426103 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #22714 [hci0] 1664.426186 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #22715 [hci0] 1664.426196 L2CAP: Configure Request (0x04) ident 13 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #22716 [hci0] 1664.428804 L2CAP: Connection Response (0x03) ident 12 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Fix is to check that channel is in state BT_DISCONN before deleting the channel. This bug was found while fuzzing Bluez's OBEX implementation using Synopsys Defensics. Reported-by: Matti Kamunen <matti.kamunen@synopsys.com> Reported-by: Ari Timonen <ari.timonen@synopsys.com> Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 28261da ] Because of both sides doing L2CAP disconnection at the same time, it was possible to receive L2CAP Disconnection Response with CID that was already freed. That caused problems if CID was already reused and L2CAP Connection Request with same CID was sent out. Before this patch kernel deleted channel context regardless of the state of the channel. Example where leftover Disconnection Response (frame torvalds#402) causes local device to delete L2CAP channel which was not yet connected. This in turn confuses remote device's stack because same CID is re-used without properly disconnecting. Btmon capture before patch: ** snip ** > ACL Data RX: Handle 43 flags 0x02 dlen 8 torvalds#394 [hci1] 10.748949 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 torvalds#395 [hci1] 10.749062 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#396 [hci1] 10.749073 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#397 [hci1] 10.752391 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#398 [hci1] 10.753394 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#399 [hci1] 10.756499 L2CAP: Disconnection Request (0x06) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#400 [hci1] 10.756548 L2CAP: Disconnection Response (0x07) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#401 [hci1] 10.757459 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#402 [hci1] 10.759148 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o.. 10.759447 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#403 [hci1] 10.759386 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#404 [hci1] 10.760397 L2CAP: Connection Request (0x02) ident 27 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 torvalds#405 [hci1] 10.760441 L2CAP: Connection Response (0x03) ident 27 len 8 Destination CID: 65 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 torvalds#406 [hci1] 10.760449 L2CAP: Configure Request (0x04) ident 19 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#407 [hci1] 10.761399 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 16 torvalds#408 [hci1] 10.762942 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Similar case after the patch: *snip* > ACL Data RX: Handle 43 flags 0x02 dlen 8 #22702 [hci0] 1664.411056 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #22703 [hci0] 1664.411136 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22704 [hci0] 1664.411143 L2CAP: Disconnection Request (0x06) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22705 [hci0] 1664.414009 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22706 [hci0] 1664.415007 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22707 [hci0] 1664.418674 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22708 [hci0] 1664.418762 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22709 [hci0] 1664.421073 L2CAP: Connection Request (0x02) ident 12 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22710 [hci0] 1664.421371 L2CAP: Disconnection Response (0x07) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22711 [hci0] 1664.424082 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22712 [hci0] 1664.425040 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22713 [hci0] 1664.426103 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #22714 [hci0] 1664.426186 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #22715 [hci0] 1664.426196 L2CAP: Configure Request (0x04) ident 13 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #22716 [hci0] 1664.428804 L2CAP: Connection Response (0x03) ident 12 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Fix is to check that channel is in state BT_DISCONN before deleting the channel. This bug was found while fuzzing Bluez's OBEX implementation using Synopsys Defensics. Reported-by: Matti Kamunen <matti.kamunen@synopsys.com> Reported-by: Ari Timonen <ari.timonen@synopsys.com> Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 28261da ] Because of both sides doing L2CAP disconnection at the same time, it was possible to receive L2CAP Disconnection Response with CID that was already freed. That caused problems if CID was already reused and L2CAP Connection Request with same CID was sent out. Before this patch kernel deleted channel context regardless of the state of the channel. Example where leftover Disconnection Response (frame torvalds#402) causes local device to delete L2CAP channel which was not yet connected. This in turn confuses remote device's stack because same CID is re-used without properly disconnecting. Btmon capture before patch: ** snip ** > ACL Data RX: Handle 43 flags 0x02 dlen 8 torvalds#394 [hci1] 10.748949 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 torvalds#395 [hci1] 10.749062 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#396 [hci1] 10.749073 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#397 [hci1] 10.752391 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#398 [hci1] 10.753394 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#399 [hci1] 10.756499 L2CAP: Disconnection Request (0x06) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#400 [hci1] 10.756548 L2CAP: Disconnection Response (0x07) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#401 [hci1] 10.757459 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#402 [hci1] 10.759148 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o.. 10.759447 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#403 [hci1] 10.759386 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#404 [hci1] 10.760397 L2CAP: Connection Request (0x02) ident 27 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 torvalds#405 [hci1] 10.760441 L2CAP: Connection Response (0x03) ident 27 len 8 Destination CID: 65 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 torvalds#406 [hci1] 10.760449 L2CAP: Configure Request (0x04) ident 19 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#407 [hci1] 10.761399 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 16 torvalds#408 [hci1] 10.762942 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Similar case after the patch: *snip* > ACL Data RX: Handle 43 flags 0x02 dlen 8 #22702 [hci0] 1664.411056 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #22703 [hci0] 1664.411136 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22704 [hci0] 1664.411143 L2CAP: Disconnection Request (0x06) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22705 [hci0] 1664.414009 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22706 [hci0] 1664.415007 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22707 [hci0] 1664.418674 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22708 [hci0] 1664.418762 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22709 [hci0] 1664.421073 L2CAP: Connection Request (0x02) ident 12 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22710 [hci0] 1664.421371 L2CAP: Disconnection Response (0x07) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22711 [hci0] 1664.424082 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22712 [hci0] 1664.425040 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22713 [hci0] 1664.426103 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #22714 [hci0] 1664.426186 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #22715 [hci0] 1664.426196 L2CAP: Configure Request (0x04) ident 13 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #22716 [hci0] 1664.428804 L2CAP: Connection Response (0x03) ident 12 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Fix is to check that channel is in state BT_DISCONN before deleting the channel. This bug was found while fuzzing Bluez's OBEX implementation using Synopsys Defensics. Reported-by: Matti Kamunen <matti.kamunen@synopsys.com> Reported-by: Ari Timonen <ari.timonen@synopsys.com> Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 28261da ] Because of both sides doing L2CAP disconnection at the same time, it was possible to receive L2CAP Disconnection Response with CID that was already freed. That caused problems if CID was already reused and L2CAP Connection Request with same CID was sent out. Before this patch kernel deleted channel context regardless of the state of the channel. Example where leftover Disconnection Response (frame torvalds#402) causes local device to delete L2CAP channel which was not yet connected. This in turn confuses remote device's stack because same CID is re-used without properly disconnecting. Btmon capture before patch: ** snip ** > ACL Data RX: Handle 43 flags 0x02 dlen 8 torvalds#394 [hci1] 10.748949 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 torvalds#395 [hci1] 10.749062 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#396 [hci1] 10.749073 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#397 [hci1] 10.752391 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#398 [hci1] 10.753394 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#399 [hci1] 10.756499 L2CAP: Disconnection Request (0x06) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#400 [hci1] 10.756548 L2CAP: Disconnection Response (0x07) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#401 [hci1] 10.757459 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#402 [hci1] 10.759148 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o.. 10.759447 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#403 [hci1] 10.759386 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#404 [hci1] 10.760397 L2CAP: Connection Request (0x02) ident 27 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 torvalds#405 [hci1] 10.760441 L2CAP: Connection Response (0x03) ident 27 len 8 Destination CID: 65 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 torvalds#406 [hci1] 10.760449 L2CAP: Configure Request (0x04) ident 19 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#407 [hci1] 10.761399 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 16 torvalds#408 [hci1] 10.762942 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Similar case after the patch: *snip* > ACL Data RX: Handle 43 flags 0x02 dlen 8 #22702 [hci0] 1664.411056 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #22703 [hci0] 1664.411136 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22704 [hci0] 1664.411143 L2CAP: Disconnection Request (0x06) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22705 [hci0] 1664.414009 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22706 [hci0] 1664.415007 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22707 [hci0] 1664.418674 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22708 [hci0] 1664.418762 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22709 [hci0] 1664.421073 L2CAP: Connection Request (0x02) ident 12 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22710 [hci0] 1664.421371 L2CAP: Disconnection Response (0x07) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22711 [hci0] 1664.424082 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22712 [hci0] 1664.425040 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22713 [hci0] 1664.426103 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #22714 [hci0] 1664.426186 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #22715 [hci0] 1664.426196 L2CAP: Configure Request (0x04) ident 13 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #22716 [hci0] 1664.428804 L2CAP: Connection Response (0x03) ident 12 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Fix is to check that channel is in state BT_DISCONN before deleting the channel. This bug was found while fuzzing Bluez's OBEX implementation using Synopsys Defensics. Reported-by: Matti Kamunen <matti.kamunen@synopsys.com> Reported-by: Ari Timonen <ari.timonen@synopsys.com> Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 28261da ] Because of both sides doing L2CAP disconnection at the same time, it was possible to receive L2CAP Disconnection Response with CID that was already freed. That caused problems if CID was already reused and L2CAP Connection Request with same CID was sent out. Before this patch kernel deleted channel context regardless of the state of the channel. Example where leftover Disconnection Response (frame torvalds#402) causes local device to delete L2CAP channel which was not yet connected. This in turn confuses remote device's stack because same CID is re-used without properly disconnecting. Btmon capture before patch: ** snip ** > ACL Data RX: Handle 43 flags 0x02 dlen 8 torvalds#394 [hci1] 10.748949 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 torvalds#395 [hci1] 10.749062 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#396 [hci1] 10.749073 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#397 [hci1] 10.752391 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#398 [hci1] 10.753394 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#399 [hci1] 10.756499 L2CAP: Disconnection Request (0x06) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#400 [hci1] 10.756548 L2CAP: Disconnection Response (0x07) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#401 [hci1] 10.757459 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#402 [hci1] 10.759148 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o.. 10.759447 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#403 [hci1] 10.759386 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#404 [hci1] 10.760397 L2CAP: Connection Request (0x02) ident 27 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 torvalds#405 [hci1] 10.760441 L2CAP: Connection Response (0x03) ident 27 len 8 Destination CID: 65 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 torvalds#406 [hci1] 10.760449 L2CAP: Configure Request (0x04) ident 19 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#407 [hci1] 10.761399 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 16 torvalds#408 [hci1] 10.762942 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Similar case after the patch: *snip* > ACL Data RX: Handle 43 flags 0x02 dlen 8 #22702 [hci0] 1664.411056 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #22703 [hci0] 1664.411136 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22704 [hci0] 1664.411143 L2CAP: Disconnection Request (0x06) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22705 [hci0] 1664.414009 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22706 [hci0] 1664.415007 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22707 [hci0] 1664.418674 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22708 [hci0] 1664.418762 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22709 [hci0] 1664.421073 L2CAP: Connection Request (0x02) ident 12 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22710 [hci0] 1664.421371 L2CAP: Disconnection Response (0x07) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22711 [hci0] 1664.424082 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22712 [hci0] 1664.425040 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22713 [hci0] 1664.426103 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #22714 [hci0] 1664.426186 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #22715 [hci0] 1664.426196 L2CAP: Configure Request (0x04) ident 13 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #22716 [hci0] 1664.428804 L2CAP: Connection Response (0x03) ident 12 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Fix is to check that channel is in state BT_DISCONN before deleting the channel. This bug was found while fuzzing Bluez's OBEX implementation using Synopsys Defensics. Reported-by: Matti Kamunen <matti.kamunen@synopsys.com> Reported-by: Ari Timonen <ari.timonen@synopsys.com> Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 28261da ] Because of both sides doing L2CAP disconnection at the same time, it was possible to receive L2CAP Disconnection Response with CID that was already freed. That caused problems if CID was already reused and L2CAP Connection Request with same CID was sent out. Before this patch kernel deleted channel context regardless of the state of the channel. Example where leftover Disconnection Response (frame torvalds#402) causes local device to delete L2CAP channel which was not yet connected. This in turn confuses remote device's stack because same CID is re-used without properly disconnecting. Btmon capture before patch: ** snip ** > ACL Data RX: Handle 43 flags 0x02 dlen 8 torvalds#394 [hci1] 10.748949 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 torvalds#395 [hci1] 10.749062 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#396 [hci1] 10.749073 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#397 [hci1] 10.752391 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#398 [hci1] 10.753394 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#399 [hci1] 10.756499 L2CAP: Disconnection Request (0x06) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#400 [hci1] 10.756548 L2CAP: Disconnection Response (0x07) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#401 [hci1] 10.757459 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#402 [hci1] 10.759148 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o.. 10.759447 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#403 [hci1] 10.759386 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#404 [hci1] 10.760397 L2CAP: Connection Request (0x02) ident 27 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 torvalds#405 [hci1] 10.760441 L2CAP: Connection Response (0x03) ident 27 len 8 Destination CID: 65 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 torvalds#406 [hci1] 10.760449 L2CAP: Configure Request (0x04) ident 19 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#407 [hci1] 10.761399 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 16 torvalds#408 [hci1] 10.762942 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Similar case after the patch: *snip* > ACL Data RX: Handle 43 flags 0x02 dlen 8 #22702 [hci0] 1664.411056 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #22703 [hci0] 1664.411136 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22704 [hci0] 1664.411143 L2CAP: Disconnection Request (0x06) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22705 [hci0] 1664.414009 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22706 [hci0] 1664.415007 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22707 [hci0] 1664.418674 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22708 [hci0] 1664.418762 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22709 [hci0] 1664.421073 L2CAP: Connection Request (0x02) ident 12 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22710 [hci0] 1664.421371 L2CAP: Disconnection Response (0x07) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22711 [hci0] 1664.424082 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22712 [hci0] 1664.425040 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22713 [hci0] 1664.426103 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #22714 [hci0] 1664.426186 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #22715 [hci0] 1664.426196 L2CAP: Configure Request (0x04) ident 13 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #22716 [hci0] 1664.428804 L2CAP: Connection Response (0x03) ident 12 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Fix is to check that channel is in state BT_DISCONN before deleting the channel. This bug was found while fuzzing Bluez's OBEX implementation using Synopsys Defensics. Reported-by: Matti Kamunen <matti.kamunen@synopsys.com> Reported-by: Ari Timonen <ari.timonen@synopsys.com> Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 28261da ] Because of both sides doing L2CAP disconnection at the same time, it was possible to receive L2CAP Disconnection Response with CID that was already freed. That caused problems if CID was already reused and L2CAP Connection Request with same CID was sent out. Before this patch kernel deleted channel context regardless of the state of the channel. Example where leftover Disconnection Response (frame torvalds#402) causes local device to delete L2CAP channel which was not yet connected. This in turn confuses remote device's stack because same CID is re-used without properly disconnecting. Btmon capture before patch: ** snip ** > ACL Data RX: Handle 43 flags 0x02 dlen 8 torvalds#394 [hci1] 10.748949 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 torvalds#395 [hci1] 10.749062 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#396 [hci1] 10.749073 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#397 [hci1] 10.752391 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#398 [hci1] 10.753394 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#399 [hci1] 10.756499 L2CAP: Disconnection Request (0x06) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#400 [hci1] 10.756548 L2CAP: Disconnection Response (0x07) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#401 [hci1] 10.757459 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#402 [hci1] 10.759148 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o.. 10.759447 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#403 [hci1] 10.759386 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#404 [hci1] 10.760397 L2CAP: Connection Request (0x02) ident 27 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 torvalds#405 [hci1] 10.760441 L2CAP: Connection Response (0x03) ident 27 len 8 Destination CID: 65 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 torvalds#406 [hci1] 10.760449 L2CAP: Configure Request (0x04) ident 19 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#407 [hci1] 10.761399 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 16 torvalds#408 [hci1] 10.762942 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Similar case after the patch: *snip* > ACL Data RX: Handle 43 flags 0x02 dlen 8 #22702 [hci0] 1664.411056 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #22703 [hci0] 1664.411136 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22704 [hci0] 1664.411143 L2CAP: Disconnection Request (0x06) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22705 [hci0] 1664.414009 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22706 [hci0] 1664.415007 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22707 [hci0] 1664.418674 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22708 [hci0] 1664.418762 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22709 [hci0] 1664.421073 L2CAP: Connection Request (0x02) ident 12 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22710 [hci0] 1664.421371 L2CAP: Disconnection Response (0x07) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22711 [hci0] 1664.424082 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22712 [hci0] 1664.425040 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22713 [hci0] 1664.426103 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #22714 [hci0] 1664.426186 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #22715 [hci0] 1664.426196 L2CAP: Configure Request (0x04) ident 13 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #22716 [hci0] 1664.428804 L2CAP: Connection Response (0x03) ident 12 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Fix is to check that channel is in state BT_DISCONN before deleting the channel. This bug was found while fuzzing Bluez's OBEX implementation using Synopsys Defensics. Reported-by: Matti Kamunen <matti.kamunen@synopsys.com> Reported-by: Ari Timonen <ari.timonen@synopsys.com> Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 28261da ] Because of both sides doing L2CAP disconnection at the same time, it was possible to receive L2CAP Disconnection Response with CID that was already freed. That caused problems if CID was already reused and L2CAP Connection Request with same CID was sent out. Before this patch kernel deleted channel context regardless of the state of the channel. Example where leftover Disconnection Response (frame torvalds#402) causes local device to delete L2CAP channel which was not yet connected. This in turn confuses remote device's stack because same CID is re-used without properly disconnecting. Btmon capture before patch: ** snip ** > ACL Data RX: Handle 43 flags 0x02 dlen 8 torvalds#394 [hci1] 10.748949 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 torvalds#395 [hci1] 10.749062 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#396 [hci1] 10.749073 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#397 [hci1] 10.752391 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#398 [hci1] 10.753394 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#399 [hci1] 10.756499 L2CAP: Disconnection Request (0x06) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#400 [hci1] 10.756548 L2CAP: Disconnection Response (0x07) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#401 [hci1] 10.757459 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#402 [hci1] 10.759148 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o.. 10.759447 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#403 [hci1] 10.759386 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#404 [hci1] 10.760397 L2CAP: Connection Request (0x02) ident 27 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 torvalds#405 [hci1] 10.760441 L2CAP: Connection Response (0x03) ident 27 len 8 Destination CID: 65 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 torvalds#406 [hci1] 10.760449 L2CAP: Configure Request (0x04) ident 19 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#407 [hci1] 10.761399 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 16 torvalds#408 [hci1] 10.762942 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Similar case after the patch: *snip* > ACL Data RX: Handle 43 flags 0x02 dlen 8 #22702 [hci0] 1664.411056 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #22703 [hci0] 1664.411136 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22704 [hci0] 1664.411143 L2CAP: Disconnection Request (0x06) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22705 [hci0] 1664.414009 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22706 [hci0] 1664.415007 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22707 [hci0] 1664.418674 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22708 [hci0] 1664.418762 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22709 [hci0] 1664.421073 L2CAP: Connection Request (0x02) ident 12 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22710 [hci0] 1664.421371 L2CAP: Disconnection Response (0x07) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22711 [hci0] 1664.424082 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22712 [hci0] 1664.425040 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22713 [hci0] 1664.426103 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #22714 [hci0] 1664.426186 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #22715 [hci0] 1664.426196 L2CAP: Configure Request (0x04) ident 13 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #22716 [hci0] 1664.428804 L2CAP: Connection Response (0x03) ident 12 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Fix is to check that channel is in state BT_DISCONN before deleting the channel. This bug was found while fuzzing Bluez's OBEX implementation using Synopsys Defensics. Reported-by: Matti Kamunen <matti.kamunen@synopsys.com> Reported-by: Ari Timonen <ari.timonen@synopsys.com> Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 28261da ] Because of both sides doing L2CAP disconnection at the same time, it was possible to receive L2CAP Disconnection Response with CID that was already freed. That caused problems if CID was already reused and L2CAP Connection Request with same CID was sent out. Before this patch kernel deleted channel context regardless of the state of the channel. Example where leftover Disconnection Response (frame torvalds#402) causes local device to delete L2CAP channel which was not yet connected. This in turn confuses remote device's stack because same CID is re-used without properly disconnecting. Btmon capture before patch: ** snip ** > ACL Data RX: Handle 43 flags 0x02 dlen 8 torvalds#394 [hci1] 10.748949 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 torvalds#395 [hci1] 10.749062 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#396 [hci1] 10.749073 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#397 [hci1] 10.752391 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#398 [hci1] 10.753394 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#399 [hci1] 10.756499 L2CAP: Disconnection Request (0x06) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#400 [hci1] 10.756548 L2CAP: Disconnection Response (0x07) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#401 [hci1] 10.757459 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#402 [hci1] 10.759148 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o.. 10.759447 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#403 [hci1] 10.759386 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#404 [hci1] 10.760397 L2CAP: Connection Request (0x02) ident 27 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 torvalds#405 [hci1] 10.760441 L2CAP: Connection Response (0x03) ident 27 len 8 Destination CID: 65 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 torvalds#406 [hci1] 10.760449 L2CAP: Configure Request (0x04) ident 19 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#407 [hci1] 10.761399 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 16 torvalds#408 [hci1] 10.762942 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Similar case after the patch: *snip* > ACL Data RX: Handle 43 flags 0x02 dlen 8 #22702 [hci0] 1664.411056 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #22703 [hci0] 1664.411136 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22704 [hci0] 1664.411143 L2CAP: Disconnection Request (0x06) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22705 [hci0] 1664.414009 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22706 [hci0] 1664.415007 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22707 [hci0] 1664.418674 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22708 [hci0] 1664.418762 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22709 [hci0] 1664.421073 L2CAP: Connection Request (0x02) ident 12 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22710 [hci0] 1664.421371 L2CAP: Disconnection Response (0x07) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22711 [hci0] 1664.424082 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22712 [hci0] 1664.425040 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22713 [hci0] 1664.426103 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #22714 [hci0] 1664.426186 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #22715 [hci0] 1664.426196 L2CAP: Configure Request (0x04) ident 13 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #22716 [hci0] 1664.428804 L2CAP: Connection Response (0x03) ident 12 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Fix is to check that channel is in state BT_DISCONN before deleting the channel. This bug was found while fuzzing Bluez's OBEX implementation using Synopsys Defensics. Reported-by: Matti Kamunen <matti.kamunen@synopsys.com> Reported-by: Ari Timonen <ari.timonen@synopsys.com> Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 28261da ] Because of both sides doing L2CAP disconnection at the same time, it was possible to receive L2CAP Disconnection Response with CID that was already freed. That caused problems if CID was already reused and L2CAP Connection Request with same CID was sent out. Before this patch kernel deleted channel context regardless of the state of the channel. Example where leftover Disconnection Response (frame torvalds#402) causes local device to delete L2CAP channel which was not yet connected. This in turn confuses remote device's stack because same CID is re-used without properly disconnecting. Btmon capture before patch: ** snip ** > ACL Data RX: Handle 43 flags 0x02 dlen 8 torvalds#394 [hci1] 10.748949 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 torvalds#395 [hci1] 10.749062 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#396 [hci1] 10.749073 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#397 [hci1] 10.752391 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#398 [hci1] 10.753394 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#399 [hci1] 10.756499 L2CAP: Disconnection Request (0x06) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#400 [hci1] 10.756548 L2CAP: Disconnection Response (0x07) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#401 [hci1] 10.757459 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#402 [hci1] 10.759148 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o.. 10.759447 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#403 [hci1] 10.759386 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#404 [hci1] 10.760397 L2CAP: Connection Request (0x02) ident 27 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 torvalds#405 [hci1] 10.760441 L2CAP: Connection Response (0x03) ident 27 len 8 Destination CID: 65 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 torvalds#406 [hci1] 10.760449 L2CAP: Configure Request (0x04) ident 19 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#407 [hci1] 10.761399 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 16 torvalds#408 [hci1] 10.762942 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Similar case after the patch: *snip* > ACL Data RX: Handle 43 flags 0x02 dlen 8 #22702 [hci0] 1664.411056 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #22703 [hci0] 1664.411136 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22704 [hci0] 1664.411143 L2CAP: Disconnection Request (0x06) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22705 [hci0] 1664.414009 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22706 [hci0] 1664.415007 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22707 [hci0] 1664.418674 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22708 [hci0] 1664.418762 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22709 [hci0] 1664.421073 L2CAP: Connection Request (0x02) ident 12 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22710 [hci0] 1664.421371 L2CAP: Disconnection Response (0x07) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22711 [hci0] 1664.424082 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22712 [hci0] 1664.425040 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22713 [hci0] 1664.426103 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #22714 [hci0] 1664.426186 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #22715 [hci0] 1664.426196 L2CAP: Configure Request (0x04) ident 13 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #22716 [hci0] 1664.428804 L2CAP: Connection Response (0x03) ident 12 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Fix is to check that channel is in state BT_DISCONN before deleting the channel. This bug was found while fuzzing Bluez's OBEX implementation using Synopsys Defensics. Reported-by: Matti Kamunen <matti.kamunen@synopsys.com> Reported-by: Ari Timonen <ari.timonen@synopsys.com> Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 28261da ] Because of both sides doing L2CAP disconnection at the same time, it was possible to receive L2CAP Disconnection Response with CID that was already freed. That caused problems if CID was already reused and L2CAP Connection Request with same CID was sent out. Before this patch kernel deleted channel context regardless of the state of the channel. Example where leftover Disconnection Response (frame torvalds#402) causes local device to delete L2CAP channel which was not yet connected. This in turn confuses remote device's stack because same CID is re-used without properly disconnecting. Btmon capture before patch: ** snip ** > ACL Data RX: Handle 43 flags 0x02 dlen 8 torvalds#394 [hci1] 10.748949 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 torvalds#395 [hci1] 10.749062 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#396 [hci1] 10.749073 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#397 [hci1] 10.752391 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#398 [hci1] 10.753394 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#399 [hci1] 10.756499 L2CAP: Disconnection Request (0x06) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#400 [hci1] 10.756548 L2CAP: Disconnection Response (0x07) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#401 [hci1] 10.757459 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#402 [hci1] 10.759148 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o.. 10.759447 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#403 [hci1] 10.759386 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#404 [hci1] 10.760397 L2CAP: Connection Request (0x02) ident 27 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 torvalds#405 [hci1] 10.760441 L2CAP: Connection Response (0x03) ident 27 len 8 Destination CID: 65 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 torvalds#406 [hci1] 10.760449 L2CAP: Configure Request (0x04) ident 19 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#407 [hci1] 10.761399 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 16 torvalds#408 [hci1] 10.762942 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Similar case after the patch: *snip* > ACL Data RX: Handle 43 flags 0x02 dlen 8 #22702 [hci0] 1664.411056 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #22703 [hci0] 1664.411136 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22704 [hci0] 1664.411143 L2CAP: Disconnection Request (0x06) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22705 [hci0] 1664.414009 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22706 [hci0] 1664.415007 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22707 [hci0] 1664.418674 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22708 [hci0] 1664.418762 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22709 [hci0] 1664.421073 L2CAP: Connection Request (0x02) ident 12 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22710 [hci0] 1664.421371 L2CAP: Disconnection Response (0x07) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22711 [hci0] 1664.424082 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22712 [hci0] 1664.425040 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22713 [hci0] 1664.426103 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #22714 [hci0] 1664.426186 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #22715 [hci0] 1664.426196 L2CAP: Configure Request (0x04) ident 13 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #22716 [hci0] 1664.428804 L2CAP: Connection Response (0x03) ident 12 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Fix is to check that channel is in state BT_DISCONN before deleting the channel. This bug was found while fuzzing Bluez's OBEX implementation using Synopsys Defensics. Reported-by: Matti Kamunen <matti.kamunen@synopsys.com> Reported-by: Ari Timonen <ari.timonen@synopsys.com> Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 28261da ] Because of both sides doing L2CAP disconnection at the same time, it was possible to receive L2CAP Disconnection Response with CID that was already freed. That caused problems if CID was already reused and L2CAP Connection Request with same CID was sent out. Before this patch kernel deleted channel context regardless of the state of the channel. Example where leftover Disconnection Response (frame torvalds#402) causes local device to delete L2CAP channel which was not yet connected. This in turn confuses remote device's stack because same CID is re-used without properly disconnecting. Btmon capture before patch: ** snip ** > ACL Data RX: Handle 43 flags 0x02 dlen 8 torvalds#394 [hci1] 10.748949 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 torvalds#395 [hci1] 10.749062 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#396 [hci1] 10.749073 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#397 [hci1] 10.752391 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#398 [hci1] 10.753394 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#399 [hci1] 10.756499 L2CAP: Disconnection Request (0x06) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#400 [hci1] 10.756548 L2CAP: Disconnection Response (0x07) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 torvalds#401 [hci1] 10.757459 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#402 [hci1] 10.759148 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o.. 10.759447 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#403 [hci1] 10.759386 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 torvalds#404 [hci1] 10.760397 L2CAP: Connection Request (0x02) ident 27 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 torvalds#405 [hci1] 10.760441 L2CAP: Connection Response (0x03) ident 27 len 8 Destination CID: 65 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 torvalds#406 [hci1] 10.760449 L2CAP: Configure Request (0x04) ident 19 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > HCI Event: Number of Completed Packets (0x13) plen 5 torvalds#407 [hci1] 10.761399 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 16 torvalds#408 [hci1] 10.762942 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Similar case after the patch: *snip* > ACL Data RX: Handle 43 flags 0x02 dlen 8 #22702 [hci0] 1664.411056 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #22703 [hci0] 1664.411136 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22704 [hci0] 1664.411143 L2CAP: Disconnection Request (0x06) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22705 [hci0] 1664.414009 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22706 [hci0] 1664.415007 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22707 [hci0] 1664.418674 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22708 [hci0] 1664.418762 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22709 [hci0] 1664.421073 L2CAP: Connection Request (0x02) ident 12 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22710 [hci0] 1664.421371 L2CAP: Disconnection Response (0x07) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22711 [hci0] 1664.424082 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22712 [hci0] 1664.425040 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22713 [hci0] 1664.426103 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #22714 [hci0] 1664.426186 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #22715 [hci0] 1664.426196 L2CAP: Configure Request (0x04) ident 13 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #22716 [hci0] 1664.428804 L2CAP: Connection Response (0x03) ident 12 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Fix is to check that channel is in state BT_DISCONN before deleting the channel. This bug was found while fuzzing Bluez's OBEX implementation using Synopsys Defensics. Reported-by: Matti Kamunen <matti.kamunen@synopsys.com> Reported-by: Ari Timonen <ari.timonen@synopsys.com> Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
BPF selftests for streams commonly trigger warnings on 32-bit armhf like: root@qemu-armhf:~/kselftests-bpf# ./test_progs -a stream_syscall ------------[ cut here ]------------ WARNING: CPU: 0 PID: 86 at kernel/bpf/stream.c:107 bpf_stream_page_check_room+0x78/0x7c Modules linked in: bpf_testmod(OE) CPU: 0 UID: 0 PID: 86 Comm: test_progs Tainted: G OE 6.16.0-rc3-00371-g38238de3a9ea torvalds#44 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Generic DT based system Call trace: dump_backtrace from show_stack+0x20/0x24 r7:c031a62c r6:00000009 r5:600f0093 r4:c12b927c show_stack from dump_stack_lvl+0x70/0x7c dump_stack_lvl from dump_stack+0x18/0x1c r5:0000006b r4:c12cd464 dump_stack from __warn+0x8c/0x128 __warn from warn_slowpath_fmt+0x184/0x18c r8:ddde5f40 r7:c031a62c r6:c12cd464 r5:00000000 r4:c189b304 warn_slowpath_fmt from bpf_stream_page_check_room+0x78/0x7c r7:c2e2a907 r6:00000003 r5:00000fec r4:00000fec bpf_stream_page_check_room from bpf_stream_page_reserve_elem+0x3c/0x12c r7:c2e2a907 r6:800f0013 r5:00000003 r4:c4012000 bpf_stream_page_reserve_elem from bpf_stream_elem_alloc+0x5c/0x70 r7:c2e2a907 r6:800f0013 r5:00000000 r4:c189af5c bpf_stream_elem_alloc from bpf_stream_vprintk+0x134/0x1a8 r7:c2e2a907 r6:c274c400 r5:00000000 r4:00000000 bpf_stream_vprintk from bpf_prog_acae6871cd11984a_stream_syscall+0xe4/0x12c r9:ffffffff r8:fffffff8 r7:ffffffff r6:c031ab50 r5:be920898 r4:c2cd2a00 bpf_prog_acae6871cd11984a_stream_syscall from bpf_prog_test_run_syscall+0xdc/0x2ac r10:df93b000 r9:00000000 r8:00000051 r7:00000000 r6:00000000 r5:be920898 r4:c2cd2a00 bpf_prog_test_run_syscall from __sys_bpf+0x580/0xda8 r10:00000000 r9:be920898 r8:00000051 r7:00000000 r6:0000000a r5:dfb55eb0 r4:df93b000 __sys_bpf from sys_bpf+0x34/0x3c r10:00000182 r9:c2cd2a00 r8:c0100268 r7:00000182 r6:0000000a r5:be920898 r4:00000050 sys_bpf from ret_fast_syscall+0x0/0x54 Exception stack(0xdfb55fa8 to 0xdfb55ff0) 5fa0: 00000050 be920898 0000000a be920898 00000050 012abc70 5fc0: 00000050 be920898 0000000a 00000182 008c5319 b6f6bd80 00000000 012c27b8 5fe0: be920870 be920860 008ee593 b6e79f72 ---[ end trace 0000000000000000 ]--- torvalds#404 stream_syscall:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED This occurs because streams kernel code assumes 8-byte char buf alignment within both 'struct bpf_stream_page' and 'struct bpf_stream_elem', and makes bpf_stream_page_push_elem() round up consumed space to 8-bytes. This scheme breaks on 32-bit because bpf_stream_elem member 'struct llist_node' is pointer-sized and so triggers a warning in bpf_stream_page_check_room(): int min = offsetof(struct bpf_stream_elem, str[0]); int consumed = stream_page->consumed; int total = BPF_STREAM_PAGE_SZ; int rem = max(0, total - consumed - min); /* Let's give room of at least 8 bytes. */ WARN_ON_ONCE(rem % 8 != 0); Fix by instead rounding and checking alignment against 'sizeof(long)'. Fixes: 5ab154f ("bpf: Introduce BPF standard streams") Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com>
BPF selftests for streams commonly trigger warnings on 32-bit armhf like: root@qemu-armhf:~/kselftests-bpf# ./test_progs -a stream_syscall ------------[ cut here ]------------ WARNING: CPU: 0 PID: 86 at kernel/bpf/stream.c:107 bpf_stream_page_check_room+0x78/0x7c Modules linked in: bpf_testmod(OE) CPU: 0 UID: 0 PID: 86 Comm: test_progs Tainted: G OE 6.16.0-rc3-00371-g38238de3a9ea torvalds#44 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Generic DT based system Call trace: dump_backtrace from show_stack+0x20/0x24 r7:c031a62c r6:00000009 r5:600f0093 r4:c12b927c show_stack from dump_stack_lvl+0x70/0x7c dump_stack_lvl from dump_stack+0x18/0x1c r5:0000006b r4:c12cd464 dump_stack from __warn+0x8c/0x128 __warn from warn_slowpath_fmt+0x184/0x18c r8:ddde5f40 r7:c031a62c r6:c12cd464 r5:00000000 r4:c189b304 warn_slowpath_fmt from bpf_stream_page_check_room+0x78/0x7c r7:c2e2a907 r6:00000003 r5:00000fec r4:00000fec bpf_stream_page_check_room from bpf_stream_page_reserve_elem+0x3c/0x12c r7:c2e2a907 r6:800f0013 r5:00000003 r4:c4012000 bpf_stream_page_reserve_elem from bpf_stream_elem_alloc+0x5c/0x70 r7:c2e2a907 r6:800f0013 r5:00000000 r4:c189af5c bpf_stream_elem_alloc from bpf_stream_vprintk+0x134/0x1a8 r7:c2e2a907 r6:c274c400 r5:00000000 r4:00000000 bpf_stream_vprintk from bpf_prog_acae6871cd11984a_stream_syscall+0xe4/0x12c r9:ffffffff r8:fffffff8 r7:ffffffff r6:c031ab50 r5:be920898 r4:c2cd2a00 bpf_prog_acae6871cd11984a_stream_syscall from bpf_prog_test_run_syscall+0xdc/0x2ac r10:df93b000 r9:00000000 r8:00000051 r7:00000000 r6:00000000 r5:be920898 r4:c2cd2a00 bpf_prog_test_run_syscall from __sys_bpf+0x580/0xda8 r10:00000000 r9:be920898 r8:00000051 r7:00000000 r6:0000000a r5:dfb55eb0 r4:df93b000 __sys_bpf from sys_bpf+0x34/0x3c r10:00000182 r9:c2cd2a00 r8:c0100268 r7:00000182 r6:0000000a r5:be920898 r4:00000050 sys_bpf from ret_fast_syscall+0x0/0x54 Exception stack(0xdfb55fa8 to 0xdfb55ff0) 5fa0: 00000050 be920898 0000000a be920898 00000050 012abc70 5fc0: 00000050 be920898 0000000a 00000182 008c5319 b6f6bd80 00000000 012c27b8 5fe0: be920870 be920860 008ee593 b6e79f72 ---[ end trace 0000000000000000 ]--- torvalds#404 stream_syscall:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED This occurs because streams kernel code assumes 8-byte char buf alignment within both 'struct bpf_stream_page' and 'struct bpf_stream_elem', and makes bpf_stream_page_push_elem() round up consumed space to 8-bytes. This scheme breaks on 32-bit because bpf_stream_elem member 'struct llist_node' is pointer-sized and so triggers a warning in bpf_stream_page_check_room(): int min = offsetof(struct bpf_stream_elem, str[0]); int consumed = stream_page->consumed; int total = BPF_STREAM_PAGE_SZ; int rem = max(0, total - consumed - min); /* Let's give room of at least 8 bytes. */ WARN_ON_ONCE(rem % 8 != 0); Fix by instead rounding and checking alignment against 'sizeof(long)'. Fixes: 5ab154f ("bpf: Introduce BPF standard streams") Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com>
As arm64 JIT now supports timed may_goto instruction, make sure all relevant tests run on this architecture. Some tests were enabled and other required modifications to work properly on arm64. $ ./test_progs -a "stream*","*may_goto*",verifier_bpf_fastcall torvalds#404 stream_errors:OK [...] torvalds#406/2 stream_success/stream_cond_break:OK [...] torvalds#494/23 verifier_bpf_fastcall/may_goto_interaction_x86_64:SKIP torvalds#494/24 verifier_bpf_fastcall/may_goto_interaction_arm64:OK [...] torvalds#539/1 verifier_may_goto_1/may_goto 0:OK torvalds#539/2 verifier_may_goto_1/batch 2 of may_goto 0:OK torvalds#539/3 verifier_may_goto_1/may_goto batch with offsets 2/1/0:OK torvalds#539/4 verifier_may_goto_1/may_goto batch with offsets 2/0:OK torvalds#539 verifier_may_goto_1:OK torvalds#540/1 verifier_may_goto_2/C code with may_goto 0:OK torvalds#540 verifier_may_goto_2:OK Summary: 7/16 PASSED, 25 SKIPPED, 0 FAILED Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Acked-by: Xu Kuohai <xukuohai@huawei.com> Link: https://lore.kernel.org/r/20250827113245.52629-3-puranjay@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Puranjay Mohan says: ==================== bpf, arm64: support for timed may_goto Changes in v2->v3: v2: https://lore.kernel.org/all/20250809204833.44803-1-puranjay@kernel.org/ - Rebased on bpf-next/master - Added Acked-by: tags from Xu and Kumar Changes in v1->v2: v1: https://lore.kernel.org/bpf/20250724125443.26182-1-puranjay@kernel.org/ - Added comment in arch_bpf_timed_may_goto() about BPF_REG_FP setup (Xu Kuohai) This set adds support for the timed may_goto instruction for the arm64. The timed may_goto instruction is implemented by the verifier by reserving 2 8byte slots in the program stack and then calling arch_bpf_timed_may_goto() in a loop with the stack offset of these two slots in BPF_REG_AX. It expects the function to put a timestamp in the first slot and the returned count in BPF_REG_AX is put into the second slot by a store instruction emitted by the verifier. arch_bpf_timed_may_goto() is special as it receives the parameter in BPF_REG_AX and is expected to return the result in BPF_REG_AX as well. It can't clobber any caller saved registers because verifier doesn't save anything before emitting the call. So, arch_bpf_timed_may_goto() is implemented in assembly so the exact registers that are stored/restored can be controlled (BPF caller saved registers here) and it also needs to take care of moving arguments and return values to and from BPF_REG_AX <-> arm64 R0. So, arch_bpf_timed_may_goto() acts as a trampoline to call bpf_check_timed_may_goto() which does the main logic of placing the timestamp and returning the count. All tests that use may_goto instruction pass after the changing some of them in patch 2 torvalds#404 stream_errors:OK [...] torvalds#406/2 stream_success/stream_cond_break:OK [...] torvalds#494/23 verifier_bpf_fastcall/may_goto_interaction_x86_64:SKIP torvalds#494/24 verifier_bpf_fastcall/may_goto_interaction_arm64:OK [...] torvalds#539/1 verifier_may_goto_1/may_goto 0:OK torvalds#539/2 verifier_may_goto_1/batch 2 of may_goto 0:OK torvalds#539/3 verifier_may_goto_1/may_goto batch with offsets 2/1/0:OK torvalds#539/4 verifier_may_goto_1/may_goto batch with offsets 2/0:OK torvalds#539 verifier_may_goto_1:OK torvalds#540/1 verifier_may_goto_2/C code with may_goto 0:OK torvalds#540 verifier_may_goto_2:OK Summary: 7/16 PASSED, 25 SKIPPED, 0 FAILED ==================== Link: https://patch.msgid.link/20250827113245.52629-1-puranjay@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
BPF selftests for streams commonly trigger warnings on 32-bit armhf like: root@qemu-armhf:~/kselftests-bpf# ./test_progs -a stream_syscall ------------[ cut here ]------------ WARNING: CPU: 0 PID: 86 at kernel/bpf/stream.c:107 bpf_stream_page_check_room+0x78/0x7c Modules linked in: bpf_testmod(OE) CPU: 0 UID: 0 PID: 86 Comm: test_progs Tainted: G OE 6.16.0-rc3-00371-g38238de3a9ea torvalds#44 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Generic DT based system Call trace: dump_backtrace from show_stack+0x20/0x24 r7:c031a62c r6:00000009 r5:600f0093 r4:c12b927c show_stack from dump_stack_lvl+0x70/0x7c dump_stack_lvl from dump_stack+0x18/0x1c r5:0000006b r4:c12cd464 dump_stack from __warn+0x8c/0x128 __warn from warn_slowpath_fmt+0x184/0x18c r8:ddde5f40 r7:c031a62c r6:c12cd464 r5:00000000 r4:c189b304 warn_slowpath_fmt from bpf_stream_page_check_room+0x78/0x7c r7:c2e2a907 r6:00000003 r5:00000fec r4:00000fec bpf_stream_page_check_room from bpf_stream_page_reserve_elem+0x3c/0x12c r7:c2e2a907 r6:800f0013 r5:00000003 r4:c4012000 bpf_stream_page_reserve_elem from bpf_stream_elem_alloc+0x5c/0x70 r7:c2e2a907 r6:800f0013 r5:00000000 r4:c189af5c bpf_stream_elem_alloc from bpf_stream_vprintk+0x134/0x1a8 r7:c2e2a907 r6:c274c400 r5:00000000 r4:00000000 bpf_stream_vprintk from bpf_prog_acae6871cd11984a_stream_syscall+0xe4/0x12c r9:ffffffff r8:fffffff8 r7:ffffffff r6:c031ab50 r5:be920898 r4:c2cd2a00 bpf_prog_acae6871cd11984a_stream_syscall from bpf_prog_test_run_syscall+0xdc/0x2ac r10:df93b000 r9:00000000 r8:00000051 r7:00000000 r6:00000000 r5:be920898 r4:c2cd2a00 bpf_prog_test_run_syscall from __sys_bpf+0x580/0xda8 r10:00000000 r9:be920898 r8:00000051 r7:00000000 r6:0000000a r5:dfb55eb0 r4:df93b000 __sys_bpf from sys_bpf+0x34/0x3c r10:00000182 r9:c2cd2a00 r8:c0100268 r7:00000182 r6:0000000a r5:be920898 r4:00000050 sys_bpf from ret_fast_syscall+0x0/0x54 Exception stack(0xdfb55fa8 to 0xdfb55ff0) 5fa0: 00000050 be920898 0000000a be920898 00000050 012abc70 5fc0: 00000050 be920898 0000000a 00000182 008c5319 b6f6bd80 00000000 012c27b8 5fe0: be920870 be920860 008ee593 b6e79f72 ---[ end trace 0000000000000000 ]--- torvalds#404 stream_syscall:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED This occurs because streams kernel code assumes 8-byte char buf alignment within both 'struct bpf_stream_page' and 'struct bpf_stream_elem', and makes bpf_stream_page_push_elem() round up consumed space to 8-bytes. This scheme breaks on 32-bit because bpf_stream_elem member 'struct llist_node' is pointer-sized and so triggers a warning in bpf_stream_page_check_room(): int min = offsetof(struct bpf_stream_elem, str[0]); int consumed = stream_page->consumed; int total = BPF_STREAM_PAGE_SZ; int rem = max(0, total - consumed - min); /* Let's give room of at least 8 bytes. */ WARN_ON_ONCE(rem % 8 != 0); Fix by instead rounding and checking alignment against 'sizeof(long)'. Fixes: 5ab154f ("bpf: Introduce BPF standard streams") Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com>
BPF selftests for streams commonly trigger warnings on 32-bit armhf like: root@qemu-armhf:~/kselftests-bpf# ./test_progs -a stream_syscall ------------[ cut here ]------------ WARNING: CPU: 0 PID: 86 at kernel/bpf/stream.c:107 bpf_stream_page_check_room+0x78/0x7c Modules linked in: bpf_testmod(OE) CPU: 0 UID: 0 PID: 86 Comm: test_progs Tainted: G OE 6.16.0-rc3-00371-g38238de3a9ea torvalds#44 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Generic DT based system Call trace: dump_backtrace from show_stack+0x20/0x24 r7:c031a62c r6:00000009 r5:600f0093 r4:c12b927c show_stack from dump_stack_lvl+0x70/0x7c dump_stack_lvl from dump_stack+0x18/0x1c r5:0000006b r4:c12cd464 dump_stack from __warn+0x8c/0x128 __warn from warn_slowpath_fmt+0x184/0x18c r8:ddde5f40 r7:c031a62c r6:c12cd464 r5:00000000 r4:c189b304 warn_slowpath_fmt from bpf_stream_page_check_room+0x78/0x7c r7:c2e2a907 r6:00000003 r5:00000fec r4:00000fec bpf_stream_page_check_room from bpf_stream_page_reserve_elem+0x3c/0x12c r7:c2e2a907 r6:800f0013 r5:00000003 r4:c4012000 bpf_stream_page_reserve_elem from bpf_stream_elem_alloc+0x5c/0x70 r7:c2e2a907 r6:800f0013 r5:00000000 r4:c189af5c bpf_stream_elem_alloc from bpf_stream_vprintk+0x134/0x1a8 r7:c2e2a907 r6:c274c400 r5:00000000 r4:00000000 bpf_stream_vprintk from bpf_prog_acae6871cd11984a_stream_syscall+0xe4/0x12c r9:ffffffff r8:fffffff8 r7:ffffffff r6:c031ab50 r5:be920898 r4:c2cd2a00 bpf_prog_acae6871cd11984a_stream_syscall from bpf_prog_test_run_syscall+0xdc/0x2ac r10:df93b000 r9:00000000 r8:00000051 r7:00000000 r6:00000000 r5:be920898 r4:c2cd2a00 bpf_prog_test_run_syscall from __sys_bpf+0x580/0xda8 r10:00000000 r9:be920898 r8:00000051 r7:00000000 r6:0000000a r5:dfb55eb0 r4:df93b000 __sys_bpf from sys_bpf+0x34/0x3c r10:00000182 r9:c2cd2a00 r8:c0100268 r7:00000182 r6:0000000a r5:be920898 r4:00000050 sys_bpf from ret_fast_syscall+0x0/0x54 Exception stack(0xdfb55fa8 to 0xdfb55ff0) 5fa0: 00000050 be920898 0000000a be920898 00000050 012abc70 5fc0: 00000050 be920898 0000000a 00000182 008c5319 b6f6bd80 00000000 012c27b8 5fe0: be920870 be920860 008ee593 b6e79f72 ---[ end trace 0000000000000000 ]--- torvalds#404 stream_syscall:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED This occurs because streams kernel code assumes 8-byte char buf alignment within both 'struct bpf_stream_page' and 'struct bpf_stream_elem', and makes bpf_stream_page_push_elem() round up consumed space to 8-bytes. This scheme breaks on 32-bit because bpf_stream_elem member 'struct llist_node' is pointer-sized and so triggers a warning in bpf_stream_page_check_room(): int min = offsetof(struct bpf_stream_elem, str[0]); int consumed = stream_page->consumed; int total = BPF_STREAM_PAGE_SZ; int rem = max(0, total - consumed - min); /* Let's give room of at least 8 bytes. */ WARN_ON_ONCE(rem % 8 != 0); Fix by instead rounding and checking alignment against 'sizeof(long)'. Fixes: 5ab154f ("bpf: Introduce BPF standard streams") Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com>
BPF selftests for streams commonly trigger warnings on 32-bit armhf like: root@qemu-armhf:~/kselftests-bpf# ./test_progs -a stream_syscall ------------[ cut here ]------------ WARNING: CPU: 0 PID: 86 at kernel/bpf/stream.c:107 bpf_stream_page_check_room+0x78/0x7c Modules linked in: bpf_testmod(OE) CPU: 0 UID: 0 PID: 86 Comm: test_progs Tainted: G OE 6.16.0-rc3-00371-g38238de3a9ea torvalds#44 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Generic DT based system Call trace: dump_backtrace from show_stack+0x20/0x24 r7:c031a62c r6:00000009 r5:600f0093 r4:c12b927c show_stack from dump_stack_lvl+0x70/0x7c dump_stack_lvl from dump_stack+0x18/0x1c r5:0000006b r4:c12cd464 dump_stack from __warn+0x8c/0x128 __warn from warn_slowpath_fmt+0x184/0x18c r8:ddde5f40 r7:c031a62c r6:c12cd464 r5:00000000 r4:c189b304 warn_slowpath_fmt from bpf_stream_page_check_room+0x78/0x7c r7:c2e2a907 r6:00000003 r5:00000fec r4:00000fec bpf_stream_page_check_room from bpf_stream_page_reserve_elem+0x3c/0x12c r7:c2e2a907 r6:800f0013 r5:00000003 r4:c4012000 bpf_stream_page_reserve_elem from bpf_stream_elem_alloc+0x5c/0x70 r7:c2e2a907 r6:800f0013 r5:00000000 r4:c189af5c bpf_stream_elem_alloc from bpf_stream_vprintk+0x134/0x1a8 r7:c2e2a907 r6:c274c400 r5:00000000 r4:00000000 bpf_stream_vprintk from bpf_prog_acae6871cd11984a_stream_syscall+0xe4/0x12c r9:ffffffff r8:fffffff8 r7:ffffffff r6:c031ab50 r5:be920898 r4:c2cd2a00 bpf_prog_acae6871cd11984a_stream_syscall from bpf_prog_test_run_syscall+0xdc/0x2ac r10:df93b000 r9:00000000 r8:00000051 r7:00000000 r6:00000000 r5:be920898 r4:c2cd2a00 bpf_prog_test_run_syscall from __sys_bpf+0x580/0xda8 r10:00000000 r9:be920898 r8:00000051 r7:00000000 r6:0000000a r5:dfb55eb0 r4:df93b000 __sys_bpf from sys_bpf+0x34/0x3c r10:00000182 r9:c2cd2a00 r8:c0100268 r7:00000182 r6:0000000a r5:be920898 r4:00000050 sys_bpf from ret_fast_syscall+0x0/0x54 Exception stack(0xdfb55fa8 to 0xdfb55ff0) 5fa0: 00000050 be920898 0000000a be920898 00000050 012abc70 5fc0: 00000050 be920898 0000000a 00000182 008c5319 b6f6bd80 00000000 012c27b8 5fe0: be920870 be920860 008ee593 b6e79f72 ---[ end trace 0000000000000000 ]--- torvalds#404 stream_syscall:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED This occurs because streams kernel code assumes 8-byte char buf alignment within both 'struct bpf_stream_page' and 'struct bpf_stream_elem', and makes bpf_stream_page_push_elem() round up consumed space to 8-bytes. This scheme breaks on 32-bit because bpf_stream_elem member 'struct llist_node' is pointer-sized and so triggers a warning in bpf_stream_page_check_room(): int min = offsetof(struct bpf_stream_elem, str[0]); int consumed = stream_page->consumed; int total = BPF_STREAM_PAGE_SZ; int rem = max(0, total - consumed - min); /* Let's give room of at least 8 bytes. */ WARN_ON_ONCE(rem % 8 != 0); Fix by instead rounding and checking alignment against 'sizeof(long)'. Fixes: 5ab154f ("bpf: Introduce BPF standard streams") Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com>
BPF selftests for streams commonly trigger warnings on 32-bit armhf like: root@qemu-armhf:~/kselftests-bpf# ./test_progs -a stream_syscall ------------[ cut here ]------------ WARNING: CPU: 0 PID: 86 at kernel/bpf/stream.c:107 bpf_stream_page_check_room+0x78/0x7c Modules linked in: bpf_testmod(OE) CPU: 0 UID: 0 PID: 86 Comm: test_progs Tainted: G OE 6.16.0-rc3-00371-g38238de3a9ea torvalds#44 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Generic DT based system Call trace: dump_backtrace from show_stack+0x20/0x24 r7:c031a62c r6:00000009 r5:600f0093 r4:c12b927c show_stack from dump_stack_lvl+0x70/0x7c dump_stack_lvl from dump_stack+0x18/0x1c r5:0000006b r4:c12cd464 dump_stack from __warn+0x8c/0x128 __warn from warn_slowpath_fmt+0x184/0x18c r8:ddde5f40 r7:c031a62c r6:c12cd464 r5:00000000 r4:c189b304 warn_slowpath_fmt from bpf_stream_page_check_room+0x78/0x7c r7:c2e2a907 r6:00000003 r5:00000fec r4:00000fec bpf_stream_page_check_room from bpf_stream_page_reserve_elem+0x3c/0x12c r7:c2e2a907 r6:800f0013 r5:00000003 r4:c4012000 bpf_stream_page_reserve_elem from bpf_stream_elem_alloc+0x5c/0x70 r7:c2e2a907 r6:800f0013 r5:00000000 r4:c189af5c bpf_stream_elem_alloc from bpf_stream_vprintk+0x134/0x1a8 r7:c2e2a907 r6:c274c400 r5:00000000 r4:00000000 bpf_stream_vprintk from bpf_prog_acae6871cd11984a_stream_syscall+0xe4/0x12c r9:ffffffff r8:fffffff8 r7:ffffffff r6:c031ab50 r5:be920898 r4:c2cd2a00 bpf_prog_acae6871cd11984a_stream_syscall from bpf_prog_test_run_syscall+0xdc/0x2ac r10:df93b000 r9:00000000 r8:00000051 r7:00000000 r6:00000000 r5:be920898 r4:c2cd2a00 bpf_prog_test_run_syscall from __sys_bpf+0x580/0xda8 r10:00000000 r9:be920898 r8:00000051 r7:00000000 r6:0000000a r5:dfb55eb0 r4:df93b000 __sys_bpf from sys_bpf+0x34/0x3c r10:00000182 r9:c2cd2a00 r8:c0100268 r7:00000182 r6:0000000a r5:be920898 r4:00000050 sys_bpf from ret_fast_syscall+0x0/0x54 Exception stack(0xdfb55fa8 to 0xdfb55ff0) 5fa0: 00000050 be920898 0000000a be920898 00000050 012abc70 5fc0: 00000050 be920898 0000000a 00000182 008c5319 b6f6bd80 00000000 012c27b8 5fe0: be920870 be920860 008ee593 b6e79f72 ---[ end trace 0000000000000000 ]--- torvalds#404 stream_syscall:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED This occurs because streams kernel code assumes 8-byte char buf alignment within both 'struct bpf_stream_page' and 'struct bpf_stream_elem', and makes bpf_stream_page_push_elem() round up consumed space to 8-bytes. This scheme breaks on 32-bit because bpf_stream_elem member 'struct llist_node' is pointer-sized and so triggers a warning in bpf_stream_page_check_room(): int min = offsetof(struct bpf_stream_elem, str[0]); int consumed = stream_page->consumed; int total = BPF_STREAM_PAGE_SZ; int rem = max(0, total - consumed - min); /* Let's give room of at least 8 bytes. */ WARN_ON_ONCE(rem % 8 != 0); Fix by instead rounding and checking alignment against 'sizeof(long)'. Fixes: 5ab154f ("bpf: Introduce BPF standard streams") Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com>
BPF selftests for streams commonly trigger warnings on 32-bit armhf like: root@qemu-armhf:~/kselftests-bpf# ./test_progs -a stream_syscall ------------[ cut here ]------------ WARNING: CPU: 0 PID: 86 at kernel/bpf/stream.c:107 bpf_stream_page_check_room+0x78/0x7c Modules linked in: bpf_testmod(OE) CPU: 0 UID: 0 PID: 86 Comm: test_progs Tainted: G OE 6.16.0-rc3-00371-g38238de3a9ea torvalds#44 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Generic DT based system Call trace: dump_backtrace from show_stack+0x20/0x24 r7:c031a62c r6:00000009 r5:600f0093 r4:c12b927c show_stack from dump_stack_lvl+0x70/0x7c dump_stack_lvl from dump_stack+0x18/0x1c r5:0000006b r4:c12cd464 dump_stack from __warn+0x8c/0x128 __warn from warn_slowpath_fmt+0x184/0x18c r8:ddde5f40 r7:c031a62c r6:c12cd464 r5:00000000 r4:c189b304 warn_slowpath_fmt from bpf_stream_page_check_room+0x78/0x7c r7:c2e2a907 r6:00000003 r5:00000fec r4:00000fec bpf_stream_page_check_room from bpf_stream_page_reserve_elem+0x3c/0x12c r7:c2e2a907 r6:800f0013 r5:00000003 r4:c4012000 bpf_stream_page_reserve_elem from bpf_stream_elem_alloc+0x5c/0x70 r7:c2e2a907 r6:800f0013 r5:00000000 r4:c189af5c bpf_stream_elem_alloc from bpf_stream_vprintk+0x134/0x1a8 r7:c2e2a907 r6:c274c400 r5:00000000 r4:00000000 bpf_stream_vprintk from bpf_prog_acae6871cd11984a_stream_syscall+0xe4/0x12c r9:ffffffff r8:fffffff8 r7:ffffffff r6:c031ab50 r5:be920898 r4:c2cd2a00 bpf_prog_acae6871cd11984a_stream_syscall from bpf_prog_test_run_syscall+0xdc/0x2ac r10:df93b000 r9:00000000 r8:00000051 r7:00000000 r6:00000000 r5:be920898 r4:c2cd2a00 bpf_prog_test_run_syscall from __sys_bpf+0x580/0xda8 r10:00000000 r9:be920898 r8:00000051 r7:00000000 r6:0000000a r5:dfb55eb0 r4:df93b000 __sys_bpf from sys_bpf+0x34/0x3c r10:00000182 r9:c2cd2a00 r8:c0100268 r7:00000182 r6:0000000a r5:be920898 r4:00000050 sys_bpf from ret_fast_syscall+0x0/0x54 Exception stack(0xdfb55fa8 to 0xdfb55ff0) 5fa0: 00000050 be920898 0000000a be920898 00000050 012abc70 5fc0: 00000050 be920898 0000000a 00000182 008c5319 b6f6bd80 00000000 012c27b8 5fe0: be920870 be920860 008ee593 b6e79f72 ---[ end trace 0000000000000000 ]--- torvalds#404 stream_syscall:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED This occurs because streams kernel code assumes 8-byte char buf alignment within both 'struct bpf_stream_page' and 'struct bpf_stream_elem', and makes bpf_stream_page_push_elem() round up consumed space to 8-bytes. This scheme breaks on 32-bit because bpf_stream_elem member 'struct llist_node' is pointer-sized and so triggers a warning in bpf_stream_page_check_room(): int min = offsetof(struct bpf_stream_elem, str[0]); int consumed = stream_page->consumed; int total = BPF_STREAM_PAGE_SZ; int rem = max(0, total - consumed - min); /* Let's give room of at least 8 bytes. */ WARN_ON_ONCE(rem % 8 != 0); Fix by instead rounding and checking alignment against 'sizeof(long)'. Fixes: 5ab154f ("bpf: Introduce BPF standard streams") Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com>
BPF selftests for streams commonly trigger warnings on 32-bit armhf like: root@qemu-armhf:~/kselftests-bpf# ./test_progs -a stream_syscall ------------[ cut here ]------------ WARNING: CPU: 0 PID: 86 at kernel/bpf/stream.c:107 bpf_stream_page_check_room+0x78/0x7c Modules linked in: bpf_testmod(OE) CPU: 0 UID: 0 PID: 86 Comm: test_progs Tainted: G OE 6.16.0-rc3-00371-g38238de3a9ea torvalds#44 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Generic DT based system Call trace: dump_backtrace from show_stack+0x20/0x24 r7:c031a62c r6:00000009 r5:600f0093 r4:c12b927c show_stack from dump_stack_lvl+0x70/0x7c dump_stack_lvl from dump_stack+0x18/0x1c r5:0000006b r4:c12cd464 dump_stack from __warn+0x8c/0x128 __warn from warn_slowpath_fmt+0x184/0x18c r8:ddde5f40 r7:c031a62c r6:c12cd464 r5:00000000 r4:c189b304 warn_slowpath_fmt from bpf_stream_page_check_room+0x78/0x7c r7:c2e2a907 r6:00000003 r5:00000fec r4:00000fec bpf_stream_page_check_room from bpf_stream_page_reserve_elem+0x3c/0x12c r7:c2e2a907 r6:800f0013 r5:00000003 r4:c4012000 bpf_stream_page_reserve_elem from bpf_stream_elem_alloc+0x5c/0x70 r7:c2e2a907 r6:800f0013 r5:00000000 r4:c189af5c bpf_stream_elem_alloc from bpf_stream_vprintk+0x134/0x1a8 r7:c2e2a907 r6:c274c400 r5:00000000 r4:00000000 bpf_stream_vprintk from bpf_prog_acae6871cd11984a_stream_syscall+0xe4/0x12c r9:ffffffff r8:fffffff8 r7:ffffffff r6:c031ab50 r5:be920898 r4:c2cd2a00 bpf_prog_acae6871cd11984a_stream_syscall from bpf_prog_test_run_syscall+0xdc/0x2ac r10:df93b000 r9:00000000 r8:00000051 r7:00000000 r6:00000000 r5:be920898 r4:c2cd2a00 bpf_prog_test_run_syscall from __sys_bpf+0x580/0xda8 r10:00000000 r9:be920898 r8:00000051 r7:00000000 r6:0000000a r5:dfb55eb0 r4:df93b000 __sys_bpf from sys_bpf+0x34/0x3c r10:00000182 r9:c2cd2a00 r8:c0100268 r7:00000182 r6:0000000a r5:be920898 r4:00000050 sys_bpf from ret_fast_syscall+0x0/0x54 Exception stack(0xdfb55fa8 to 0xdfb55ff0) 5fa0: 00000050 be920898 0000000a be920898 00000050 012abc70 5fc0: 00000050 be920898 0000000a 00000182 008c5319 b6f6bd80 00000000 012c27b8 5fe0: be920870 be920860 008ee593 b6e79f72 ---[ end trace 0000000000000000 ]--- torvalds#404 stream_syscall:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED This occurs because streams kernel code assumes 8-byte char buf alignment within both 'struct bpf_stream_page' and 'struct bpf_stream_elem', and makes bpf_stream_page_push_elem() round up consumed space to 8-bytes. This scheme breaks on 32-bit because bpf_stream_elem member 'struct llist_node' is pointer-sized and so triggers a warning in bpf_stream_page_check_room(): int min = offsetof(struct bpf_stream_elem, str[0]); int consumed = stream_page->consumed; int total = BPF_STREAM_PAGE_SZ; int rem = max(0, total - consumed - min); /* Let's give room of at least 8 bytes. */ WARN_ON_ONCE(rem % 8 != 0); Fix by instead rounding and checking alignment against 'sizeof(long)'. Fixes: 5ab154f ("bpf: Introduce BPF standard streams") Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com>
BPF selftests for streams commonly trigger warnings on 32-bit armhf like: root@qemu-armhf:~/kselftests-bpf# ./test_progs -a stream_syscall ------------[ cut here ]------------ WARNING: CPU: 0 PID: 86 at kernel/bpf/stream.c:107 bpf_stream_page_check_room+0x78/0x7c Modules linked in: bpf_testmod(OE) CPU: 0 UID: 0 PID: 86 Comm: test_progs Tainted: G OE 6.16.0-rc3-00371-g38238de3a9ea torvalds#44 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Generic DT based system Call trace: dump_backtrace from show_stack+0x20/0x24 r7:c031a62c r6:00000009 r5:600f0093 r4:c12b927c show_stack from dump_stack_lvl+0x70/0x7c dump_stack_lvl from dump_stack+0x18/0x1c r5:0000006b r4:c12cd464 dump_stack from __warn+0x8c/0x128 __warn from warn_slowpath_fmt+0x184/0x18c r8:ddde5f40 r7:c031a62c r6:c12cd464 r5:00000000 r4:c189b304 warn_slowpath_fmt from bpf_stream_page_check_room+0x78/0x7c r7:c2e2a907 r6:00000003 r5:00000fec r4:00000fec bpf_stream_page_check_room from bpf_stream_page_reserve_elem+0x3c/0x12c r7:c2e2a907 r6:800f0013 r5:00000003 r4:c4012000 bpf_stream_page_reserve_elem from bpf_stream_elem_alloc+0x5c/0x70 r7:c2e2a907 r6:800f0013 r5:00000000 r4:c189af5c bpf_stream_elem_alloc from bpf_stream_vprintk+0x134/0x1a8 r7:c2e2a907 r6:c274c400 r5:00000000 r4:00000000 bpf_stream_vprintk from bpf_prog_acae6871cd11984a_stream_syscall+0xe4/0x12c r9:ffffffff r8:fffffff8 r7:ffffffff r6:c031ab50 r5:be920898 r4:c2cd2a00 bpf_prog_acae6871cd11984a_stream_syscall from bpf_prog_test_run_syscall+0xdc/0x2ac r10:df93b000 r9:00000000 r8:00000051 r7:00000000 r6:00000000 r5:be920898 r4:c2cd2a00 bpf_prog_test_run_syscall from __sys_bpf+0x580/0xda8 r10:00000000 r9:be920898 r8:00000051 r7:00000000 r6:0000000a r5:dfb55eb0 r4:df93b000 __sys_bpf from sys_bpf+0x34/0x3c r10:00000182 r9:c2cd2a00 r8:c0100268 r7:00000182 r6:0000000a r5:be920898 r4:00000050 sys_bpf from ret_fast_syscall+0x0/0x54 Exception stack(0xdfb55fa8 to 0xdfb55ff0) 5fa0: 00000050 be920898 0000000a be920898 00000050 012abc70 5fc0: 00000050 be920898 0000000a 00000182 008c5319 b6f6bd80 00000000 012c27b8 5fe0: be920870 be920860 008ee593 b6e79f72 ---[ end trace 0000000000000000 ]--- torvalds#404 stream_syscall:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED This occurs because streams kernel code assumes 8-byte char buf alignment within both 'struct bpf_stream_page' and 'struct bpf_stream_elem', and makes bpf_stream_page_push_elem() round up consumed space to 8-bytes. This scheme breaks on 32-bit because bpf_stream_elem member 'struct llist_node' is pointer-sized and so triggers a warning in bpf_stream_page_check_room(): int min = offsetof(struct bpf_stream_elem, str[0]); int consumed = stream_page->consumed; int total = BPF_STREAM_PAGE_SZ; int rem = max(0, total - consumed - min); /* Let's give room of at least 8 bytes. */ WARN_ON_ONCE(rem % 8 != 0); Fix by instead rounding and checking alignment against 'sizeof(long)'. Fixes: 5ab154f ("bpf: Introduce BPF standard streams") Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com>
Use BPF_TRAMP_F_INDIRECT flag to detect struct ops and emit proper prologue and epilogue for this case. With this patch, all of the struct_ops related testcases (except struct_ops_multi_pages) passed on LoongArch. The testcase struct_ops_multi_pages failed is because the actual image_pages_cnt is 40 which is bigger than MAX_TRAMP_IMAGE_PAGES. Before: $ sudo ./test_progs -t struct_ops -d struct_ops_multi_pages ... WATCHDOG: test case struct_ops_module/struct_ops_load executes for 10 seconds... After: $ sudo ./test_progs -t struct_ops -d struct_ops_multi_pages ... torvalds#15 bad_struct_ops:OK ... torvalds#399 struct_ops_autocreate:OK ... torvalds#400 struct_ops_kptr_return:OK ... torvalds#401 struct_ops_maybe_null:OK ... torvalds#402 struct_ops_module:OK ... torvalds#404 struct_ops_no_cfi:OK ... torvalds#405 struct_ops_private_stack:SKIP ... torvalds#406 struct_ops_refcounted:OK Summary: 8/25 PASSED, 3 SKIPPED, 0 FAILED Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: maoxiaochuan <maoxiaochuan@loongson.cn>
BPF selftests for streams commonly trigger warnings on 32-bit armhf like: root@qemu-armhf:~/kselftests-bpf# ./test_progs -a stream_syscall ------------[ cut here ]------------ WARNING: CPU: 0 PID: 86 at kernel/bpf/stream.c:107 bpf_stream_page_check_room+0x78/0x7c Modules linked in: bpf_testmod(OE) CPU: 0 UID: 0 PID: 86 Comm: test_progs Tainted: G OE 6.16.0-rc3-00371-g38238de3a9ea torvalds#44 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Generic DT based system Call trace: dump_backtrace from show_stack+0x20/0x24 r7:c031a62c r6:00000009 r5:600f0093 r4:c12b927c show_stack from dump_stack_lvl+0x70/0x7c dump_stack_lvl from dump_stack+0x18/0x1c r5:0000006b r4:c12cd464 dump_stack from __warn+0x8c/0x128 __warn from warn_slowpath_fmt+0x184/0x18c r8:ddde5f40 r7:c031a62c r6:c12cd464 r5:00000000 r4:c189b304 warn_slowpath_fmt from bpf_stream_page_check_room+0x78/0x7c r7:c2e2a907 r6:00000003 r5:00000fec r4:00000fec bpf_stream_page_check_room from bpf_stream_page_reserve_elem+0x3c/0x12c r7:c2e2a907 r6:800f0013 r5:00000003 r4:c4012000 bpf_stream_page_reserve_elem from bpf_stream_elem_alloc+0x5c/0x70 r7:c2e2a907 r6:800f0013 r5:00000000 r4:c189af5c bpf_stream_elem_alloc from bpf_stream_vprintk+0x134/0x1a8 r7:c2e2a907 r6:c274c400 r5:00000000 r4:00000000 bpf_stream_vprintk from bpf_prog_acae6871cd11984a_stream_syscall+0xe4/0x12c r9:ffffffff r8:fffffff8 r7:ffffffff r6:c031ab50 r5:be920898 r4:c2cd2a00 bpf_prog_acae6871cd11984a_stream_syscall from bpf_prog_test_run_syscall+0xdc/0x2ac r10:df93b000 r9:00000000 r8:00000051 r7:00000000 r6:00000000 r5:be920898 r4:c2cd2a00 bpf_prog_test_run_syscall from __sys_bpf+0x580/0xda8 r10:00000000 r9:be920898 r8:00000051 r7:00000000 r6:0000000a r5:dfb55eb0 r4:df93b000 __sys_bpf from sys_bpf+0x34/0x3c r10:00000182 r9:c2cd2a00 r8:c0100268 r7:00000182 r6:0000000a r5:be920898 r4:00000050 sys_bpf from ret_fast_syscall+0x0/0x54 Exception stack(0xdfb55fa8 to 0xdfb55ff0) 5fa0: 00000050 be920898 0000000a be920898 00000050 012abc70 5fc0: 00000050 be920898 0000000a 00000182 008c5319 b6f6bd80 00000000 012c27b8 5fe0: be920870 be920860 008ee593 b6e79f72 ---[ end trace 0000000000000000 ]--- torvalds#404 stream_syscall:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED This occurs because streams kernel code assumes 8-byte char buf alignment within both 'struct bpf_stream_page' and 'struct bpf_stream_elem', and makes bpf_stream_page_push_elem() round up consumed space to 8-bytes. This scheme breaks on 32-bit because bpf_stream_elem member 'struct llist_node' is pointer-sized and so triggers a warning in bpf_stream_page_check_room(): int min = offsetof(struct bpf_stream_elem, str[0]); int consumed = stream_page->consumed; int total = BPF_STREAM_PAGE_SZ; int rem = max(0, total - consumed - min); /* Let's give room of at least 8 bytes. */ WARN_ON_ONCE(rem % 8 != 0); Fix by instead rounding and checking alignment against 'sizeof(long)'. Fixes: 5ab154f ("bpf: Introduce BPF standard streams") Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com>
BPF selftests for streams commonly trigger warnings on 32-bit armhf like: root@qemu-armhf:~/kselftests-bpf# ./test_progs -a stream_syscall ------------[ cut here ]------------ WARNING: CPU: 0 PID: 86 at kernel/bpf/stream.c:107 bpf_stream_page_check_room+0x78/0x7c Modules linked in: bpf_testmod(OE) CPU: 0 UID: 0 PID: 86 Comm: test_progs Tainted: G OE 6.16.0-rc3-00371-g38238de3a9ea torvalds#44 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Generic DT based system Call trace: dump_backtrace from show_stack+0x20/0x24 r7:c031a62c r6:00000009 r5:600f0093 r4:c12b927c show_stack from dump_stack_lvl+0x70/0x7c dump_stack_lvl from dump_stack+0x18/0x1c r5:0000006b r4:c12cd464 dump_stack from __warn+0x8c/0x128 __warn from warn_slowpath_fmt+0x184/0x18c r8:ddde5f40 r7:c031a62c r6:c12cd464 r5:00000000 r4:c189b304 warn_slowpath_fmt from bpf_stream_page_check_room+0x78/0x7c r7:c2e2a907 r6:00000003 r5:00000fec r4:00000fec bpf_stream_page_check_room from bpf_stream_page_reserve_elem+0x3c/0x12c r7:c2e2a907 r6:800f0013 r5:00000003 r4:c4012000 bpf_stream_page_reserve_elem from bpf_stream_elem_alloc+0x5c/0x70 r7:c2e2a907 r6:800f0013 r5:00000000 r4:c189af5c bpf_stream_elem_alloc from bpf_stream_vprintk+0x134/0x1a8 r7:c2e2a907 r6:c274c400 r5:00000000 r4:00000000 bpf_stream_vprintk from bpf_prog_acae6871cd11984a_stream_syscall+0xe4/0x12c r9:ffffffff r8:fffffff8 r7:ffffffff r6:c031ab50 r5:be920898 r4:c2cd2a00 bpf_prog_acae6871cd11984a_stream_syscall from bpf_prog_test_run_syscall+0xdc/0x2ac r10:df93b000 r9:00000000 r8:00000051 r7:00000000 r6:00000000 r5:be920898 r4:c2cd2a00 bpf_prog_test_run_syscall from __sys_bpf+0x580/0xda8 r10:00000000 r9:be920898 r8:00000051 r7:00000000 r6:0000000a r5:dfb55eb0 r4:df93b000 __sys_bpf from sys_bpf+0x34/0x3c r10:00000182 r9:c2cd2a00 r8:c0100268 r7:00000182 r6:0000000a r5:be920898 r4:00000050 sys_bpf from ret_fast_syscall+0x0/0x54 Exception stack(0xdfb55fa8 to 0xdfb55ff0) 5fa0: 00000050 be920898 0000000a be920898 00000050 012abc70 5fc0: 00000050 be920898 0000000a 00000182 008c5319 b6f6bd80 00000000 012c27b8 5fe0: be920870 be920860 008ee593 b6e79f72 ---[ end trace 0000000000000000 ]--- torvalds#404 stream_syscall:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED This occurs because streams kernel code assumes 8-byte char buf alignment within both 'struct bpf_stream_page' and 'struct bpf_stream_elem', and makes bpf_stream_page_push_elem() round up consumed space to 8-bytes. This scheme breaks on 32-bit because bpf_stream_elem member 'struct llist_node' is pointer-sized and so triggers a warning in bpf_stream_page_check_room(): int min = offsetof(struct bpf_stream_elem, str[0]); int consumed = stream_page->consumed; int total = BPF_STREAM_PAGE_SZ; int rem = max(0, total - consumed - min); /* Let's give room of at least 8 bytes. */ WARN_ON_ONCE(rem % 8 != 0); Fix by instead rounding and checking alignment against 'sizeof(long)'. Fixes: 5ab154f ("bpf: Introduce BPF standard streams") Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com>
BPF selftests for streams commonly trigger warnings on 32-bit armhf like: root@qemu-armhf:~/kselftests-bpf# ./test_progs -a stream_syscall ------------[ cut here ]------------ WARNING: CPU: 0 PID: 86 at kernel/bpf/stream.c:107 bpf_stream_page_check_room+0x78/0x7c Modules linked in: bpf_testmod(OE) CPU: 0 UID: 0 PID: 86 Comm: test_progs Tainted: G OE 6.16.0-rc3-00371-g38238de3a9ea torvalds#44 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Generic DT based system Call trace: dump_backtrace from show_stack+0x20/0x24 r7:c031a62c r6:00000009 r5:600f0093 r4:c12b927c show_stack from dump_stack_lvl+0x70/0x7c dump_stack_lvl from dump_stack+0x18/0x1c r5:0000006b r4:c12cd464 dump_stack from __warn+0x8c/0x128 __warn from warn_slowpath_fmt+0x184/0x18c r8:ddde5f40 r7:c031a62c r6:c12cd464 r5:00000000 r4:c189b304 warn_slowpath_fmt from bpf_stream_page_check_room+0x78/0x7c r7:c2e2a907 r6:00000003 r5:00000fec r4:00000fec bpf_stream_page_check_room from bpf_stream_page_reserve_elem+0x3c/0x12c r7:c2e2a907 r6:800f0013 r5:00000003 r4:c4012000 bpf_stream_page_reserve_elem from bpf_stream_elem_alloc+0x5c/0x70 r7:c2e2a907 r6:800f0013 r5:00000000 r4:c189af5c bpf_stream_elem_alloc from bpf_stream_vprintk+0x134/0x1a8 r7:c2e2a907 r6:c274c400 r5:00000000 r4:00000000 bpf_stream_vprintk from bpf_prog_acae6871cd11984a_stream_syscall+0xe4/0x12c r9:ffffffff r8:fffffff8 r7:ffffffff r6:c031ab50 r5:be920898 r4:c2cd2a00 bpf_prog_acae6871cd11984a_stream_syscall from bpf_prog_test_run_syscall+0xdc/0x2ac r10:df93b000 r9:00000000 r8:00000051 r7:00000000 r6:00000000 r5:be920898 r4:c2cd2a00 bpf_prog_test_run_syscall from __sys_bpf+0x580/0xda8 r10:00000000 r9:be920898 r8:00000051 r7:00000000 r6:0000000a r5:dfb55eb0 r4:df93b000 __sys_bpf from sys_bpf+0x34/0x3c r10:00000182 r9:c2cd2a00 r8:c0100268 r7:00000182 r6:0000000a r5:be920898 r4:00000050 sys_bpf from ret_fast_syscall+0x0/0x54 Exception stack(0xdfb55fa8 to 0xdfb55ff0) 5fa0: 00000050 be920898 0000000a be920898 00000050 012abc70 5fc0: 00000050 be920898 0000000a 00000182 008c5319 b6f6bd80 00000000 012c27b8 5fe0: be920870 be920860 008ee593 b6e79f72 ---[ end trace 0000000000000000 ]--- torvalds#404 stream_syscall:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED This occurs because streams kernel code assumes 8-byte char buf alignment within both 'struct bpf_stream_page' and 'struct bpf_stream_elem', and makes bpf_stream_page_push_elem() round up consumed space to 8-bytes. This scheme breaks on 32-bit because bpf_stream_elem member 'struct llist_node' is pointer-sized and so triggers a warning in bpf_stream_page_check_room(): int min = offsetof(struct bpf_stream_elem, str[0]); int consumed = stream_page->consumed; int total = BPF_STREAM_PAGE_SZ; int rem = max(0, total - consumed - min); /* Let's give room of at least 8 bytes. */ WARN_ON_ONCE(rem % 8 != 0); Fix by instead rounding and checking alignment against 'sizeof(long)'. Fixes: 5ab154f ("bpf: Introduce BPF standard streams") Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com>
BPF selftests for streams commonly trigger warnings on 32-bit armhf like: root@qemu-armhf:~/kselftests-bpf# ./test_progs -a stream_syscall ------------[ cut here ]------------ WARNING: CPU: 0 PID: 86 at kernel/bpf/stream.c:107 bpf_stream_page_check_room+0x78/0x7c Modules linked in: bpf_testmod(OE) CPU: 0 UID: 0 PID: 86 Comm: test_progs Tainted: G OE 6.16.0-rc3-00371-g38238de3a9ea torvalds#44 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Generic DT based system Call trace: dump_backtrace from show_stack+0x20/0x24 r7:c031a62c r6:00000009 r5:600f0093 r4:c12b927c show_stack from dump_stack_lvl+0x70/0x7c dump_stack_lvl from dump_stack+0x18/0x1c r5:0000006b r4:c12cd464 dump_stack from __warn+0x8c/0x128 __warn from warn_slowpath_fmt+0x184/0x18c r8:ddde5f40 r7:c031a62c r6:c12cd464 r5:00000000 r4:c189b304 warn_slowpath_fmt from bpf_stream_page_check_room+0x78/0x7c r7:c2e2a907 r6:00000003 r5:00000fec r4:00000fec bpf_stream_page_check_room from bpf_stream_page_reserve_elem+0x3c/0x12c r7:c2e2a907 r6:800f0013 r5:00000003 r4:c4012000 bpf_stream_page_reserve_elem from bpf_stream_elem_alloc+0x5c/0x70 r7:c2e2a907 r6:800f0013 r5:00000000 r4:c189af5c bpf_stream_elem_alloc from bpf_stream_vprintk+0x134/0x1a8 r7:c2e2a907 r6:c274c400 r5:00000000 r4:00000000 bpf_stream_vprintk from bpf_prog_acae6871cd11984a_stream_syscall+0xe4/0x12c r9:ffffffff r8:fffffff8 r7:ffffffff r6:c031ab50 r5:be920898 r4:c2cd2a00 bpf_prog_acae6871cd11984a_stream_syscall from bpf_prog_test_run_syscall+0xdc/0x2ac r10:df93b000 r9:00000000 r8:00000051 r7:00000000 r6:00000000 r5:be920898 r4:c2cd2a00 bpf_prog_test_run_syscall from __sys_bpf+0x580/0xda8 r10:00000000 r9:be920898 r8:00000051 r7:00000000 r6:0000000a r5:dfb55eb0 r4:df93b000 __sys_bpf from sys_bpf+0x34/0x3c r10:00000182 r9:c2cd2a00 r8:c0100268 r7:00000182 r6:0000000a r5:be920898 r4:00000050 sys_bpf from ret_fast_syscall+0x0/0x54 Exception stack(0xdfb55fa8 to 0xdfb55ff0) 5fa0: 00000050 be920898 0000000a be920898 00000050 012abc70 5fc0: 00000050 be920898 0000000a 00000182 008c5319 b6f6bd80 00000000 012c27b8 5fe0: be920870 be920860 008ee593 b6e79f72 ---[ end trace 0000000000000000 ]--- torvalds#404 stream_syscall:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED This occurs because streams kernel code assumes 8-byte char buf alignment within both 'struct bpf_stream_page' and 'struct bpf_stream_elem', and makes bpf_stream_page_push_elem() round up consumed space to 8-bytes. This scheme breaks on 32-bit because bpf_stream_elem member 'struct llist_node' is pointer-sized and so triggers a warning in bpf_stream_page_check_room(): int min = offsetof(struct bpf_stream_elem, str[0]); int consumed = stream_page->consumed; int total = BPF_STREAM_PAGE_SZ; int rem = max(0, total - consumed - min); /* Let's give room of at least 8 bytes. */ WARN_ON_ONCE(rem % 8 != 0); Fix by instead rounding and checking alignment against 'sizeof(long)'. Fixes: 5ab154f ("bpf: Introduce BPF standard streams") Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com>
BPF selftests for streams commonly trigger warnings on 32-bit armhf like: root@qemu-armhf:~/kselftests-bpf# ./test_progs -a stream_syscall ------------[ cut here ]------------ WARNING: CPU: 0 PID: 86 at kernel/bpf/stream.c:107 bpf_stream_page_check_room+0x78/0x7c Modules linked in: bpf_testmod(OE) CPU: 0 UID: 0 PID: 86 Comm: test_progs Tainted: G OE 6.16.0-rc3-00371-g38238de3a9ea torvalds#44 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Generic DT based system Call trace: dump_backtrace from show_stack+0x20/0x24 r7:c031a62c r6:00000009 r5:600f0093 r4:c12b927c show_stack from dump_stack_lvl+0x70/0x7c dump_stack_lvl from dump_stack+0x18/0x1c r5:0000006b r4:c12cd464 dump_stack from __warn+0x8c/0x128 __warn from warn_slowpath_fmt+0x184/0x18c r8:ddde5f40 r7:c031a62c r6:c12cd464 r5:00000000 r4:c189b304 warn_slowpath_fmt from bpf_stream_page_check_room+0x78/0x7c r7:c2e2a907 r6:00000003 r5:00000fec r4:00000fec bpf_stream_page_check_room from bpf_stream_page_reserve_elem+0x3c/0x12c r7:c2e2a907 r6:800f0013 r5:00000003 r4:c4012000 bpf_stream_page_reserve_elem from bpf_stream_elem_alloc+0x5c/0x70 r7:c2e2a907 r6:800f0013 r5:00000000 r4:c189af5c bpf_stream_elem_alloc from bpf_stream_vprintk+0x134/0x1a8 r7:c2e2a907 r6:c274c400 r5:00000000 r4:00000000 bpf_stream_vprintk from bpf_prog_acae6871cd11984a_stream_syscall+0xe4/0x12c r9:ffffffff r8:fffffff8 r7:ffffffff r6:c031ab50 r5:be920898 r4:c2cd2a00 bpf_prog_acae6871cd11984a_stream_syscall from bpf_prog_test_run_syscall+0xdc/0x2ac r10:df93b000 r9:00000000 r8:00000051 r7:00000000 r6:00000000 r5:be920898 r4:c2cd2a00 bpf_prog_test_run_syscall from __sys_bpf+0x580/0xda8 r10:00000000 r9:be920898 r8:00000051 r7:00000000 r6:0000000a r5:dfb55eb0 r4:df93b000 __sys_bpf from sys_bpf+0x34/0x3c r10:00000182 r9:c2cd2a00 r8:c0100268 r7:00000182 r6:0000000a r5:be920898 r4:00000050 sys_bpf from ret_fast_syscall+0x0/0x54 Exception stack(0xdfb55fa8 to 0xdfb55ff0) 5fa0: 00000050 be920898 0000000a be920898 00000050 012abc70 5fc0: 00000050 be920898 0000000a 00000182 008c5319 b6f6bd80 00000000 012c27b8 5fe0: be920870 be920860 008ee593 b6e79f72 ---[ end trace 0000000000000000 ]--- torvalds#404 stream_syscall:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED This occurs because streams kernel code assumes 8-byte char buf alignment within both 'struct bpf_stream_page' and 'struct bpf_stream_elem', and makes bpf_stream_page_push_elem() round up consumed space to 8-bytes. This scheme breaks on 32-bit because bpf_stream_elem member 'struct llist_node' is pointer-sized and so triggers a warning in bpf_stream_page_check_room(): int min = offsetof(struct bpf_stream_elem, str[0]); int consumed = stream_page->consumed; int total = BPF_STREAM_PAGE_SZ; int rem = max(0, total - consumed - min); /* Let's give room of at least 8 bytes. */ WARN_ON_ONCE(rem % 8 != 0); Fix by instead rounding and checking alignment against 'sizeof(long)'. Fixes: 5ab154f ("bpf: Introduce BPF standard streams") Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com>
BPF selftests for streams commonly trigger warnings on 32-bit armhf like: root@qemu-armhf:~/kselftests-bpf# ./test_progs -a stream_syscall ------------[ cut here ]------------ WARNING: CPU: 0 PID: 86 at kernel/bpf/stream.c:107 bpf_stream_page_check_room+0x78/0x7c Modules linked in: bpf_testmod(OE) CPU: 0 UID: 0 PID: 86 Comm: test_progs Tainted: G OE 6.16.0-rc3-00371-g38238de3a9ea torvalds#44 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Generic DT based system Call trace: dump_backtrace from show_stack+0x20/0x24 r7:c031a62c r6:00000009 r5:600f0093 r4:c12b927c show_stack from dump_stack_lvl+0x70/0x7c dump_stack_lvl from dump_stack+0x18/0x1c r5:0000006b r4:c12cd464 dump_stack from __warn+0x8c/0x128 __warn from warn_slowpath_fmt+0x184/0x18c r8:ddde5f40 r7:c031a62c r6:c12cd464 r5:00000000 r4:c189b304 warn_slowpath_fmt from bpf_stream_page_check_room+0x78/0x7c r7:c2e2a907 r6:00000003 r5:00000fec r4:00000fec bpf_stream_page_check_room from bpf_stream_page_reserve_elem+0x3c/0x12c r7:c2e2a907 r6:800f0013 r5:00000003 r4:c4012000 bpf_stream_page_reserve_elem from bpf_stream_elem_alloc+0x5c/0x70 r7:c2e2a907 r6:800f0013 r5:00000000 r4:c189af5c bpf_stream_elem_alloc from bpf_stream_vprintk+0x134/0x1a8 r7:c2e2a907 r6:c274c400 r5:00000000 r4:00000000 bpf_stream_vprintk from bpf_prog_acae6871cd11984a_stream_syscall+0xe4/0x12c r9:ffffffff r8:fffffff8 r7:ffffffff r6:c031ab50 r5:be920898 r4:c2cd2a00 bpf_prog_acae6871cd11984a_stream_syscall from bpf_prog_test_run_syscall+0xdc/0x2ac r10:df93b000 r9:00000000 r8:00000051 r7:00000000 r6:00000000 r5:be920898 r4:c2cd2a00 bpf_prog_test_run_syscall from __sys_bpf+0x580/0xda8 r10:00000000 r9:be920898 r8:00000051 r7:00000000 r6:0000000a r5:dfb55eb0 r4:df93b000 __sys_bpf from sys_bpf+0x34/0x3c r10:00000182 r9:c2cd2a00 r8:c0100268 r7:00000182 r6:0000000a r5:be920898 r4:00000050 sys_bpf from ret_fast_syscall+0x0/0x54 Exception stack(0xdfb55fa8 to 0xdfb55ff0) 5fa0: 00000050 be920898 0000000a be920898 00000050 012abc70 5fc0: 00000050 be920898 0000000a 00000182 008c5319 b6f6bd80 00000000 012c27b8 5fe0: be920870 be920860 008ee593 b6e79f72 ---[ end trace 0000000000000000 ]--- torvalds#404 stream_syscall:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED This occurs because streams kernel code assumes 8-byte char buf alignment within both 'struct bpf_stream_page' and 'struct bpf_stream_elem', and makes bpf_stream_page_push_elem() round up consumed space to 8-bytes. This scheme breaks on 32-bit because bpf_stream_elem member 'struct llist_node' is pointer-sized and so triggers a warning in bpf_stream_page_check_room(): int min = offsetof(struct bpf_stream_elem, str[0]); int consumed = stream_page->consumed; int total = BPF_STREAM_PAGE_SZ; int rem = max(0, total - consumed - min); /* Let's give room of at least 8 bytes. */ WARN_ON_ONCE(rem % 8 != 0); Fix by instead rounding and checking alignment against 'sizeof(long)'. Fixes: 5ab154f ("bpf: Introduce BPF standard streams") Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com>
BPF selftests for streams commonly trigger warnings on 32-bit armhf like: root@qemu-armhf:~/kselftests-bpf# ./test_progs -a stream_syscall ------------[ cut here ]------------ WARNING: CPU: 0 PID: 86 at kernel/bpf/stream.c:107 bpf_stream_page_check_room+0x78/0x7c Modules linked in: bpf_testmod(OE) CPU: 0 UID: 0 PID: 86 Comm: test_progs Tainted: G OE 6.16.0-rc3-00371-g38238de3a9ea torvalds#44 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Generic DT based system Call trace: dump_backtrace from show_stack+0x20/0x24 r7:c031a62c r6:00000009 r5:600f0093 r4:c12b927c show_stack from dump_stack_lvl+0x70/0x7c dump_stack_lvl from dump_stack+0x18/0x1c r5:0000006b r4:c12cd464 dump_stack from __warn+0x8c/0x128 __warn from warn_slowpath_fmt+0x184/0x18c r8:ddde5f40 r7:c031a62c r6:c12cd464 r5:00000000 r4:c189b304 warn_slowpath_fmt from bpf_stream_page_check_room+0x78/0x7c r7:c2e2a907 r6:00000003 r5:00000fec r4:00000fec bpf_stream_page_check_room from bpf_stream_page_reserve_elem+0x3c/0x12c r7:c2e2a907 r6:800f0013 r5:00000003 r4:c4012000 bpf_stream_page_reserve_elem from bpf_stream_elem_alloc+0x5c/0x70 r7:c2e2a907 r6:800f0013 r5:00000000 r4:c189af5c bpf_stream_elem_alloc from bpf_stream_vprintk+0x134/0x1a8 r7:c2e2a907 r6:c274c400 r5:00000000 r4:00000000 bpf_stream_vprintk from bpf_prog_acae6871cd11984a_stream_syscall+0xe4/0x12c r9:ffffffff r8:fffffff8 r7:ffffffff r6:c031ab50 r5:be920898 r4:c2cd2a00 bpf_prog_acae6871cd11984a_stream_syscall from bpf_prog_test_run_syscall+0xdc/0x2ac r10:df93b000 r9:00000000 r8:00000051 r7:00000000 r6:00000000 r5:be920898 r4:c2cd2a00 bpf_prog_test_run_syscall from __sys_bpf+0x580/0xda8 r10:00000000 r9:be920898 r8:00000051 r7:00000000 r6:0000000a r5:dfb55eb0 r4:df93b000 __sys_bpf from sys_bpf+0x34/0x3c r10:00000182 r9:c2cd2a00 r8:c0100268 r7:00000182 r6:0000000a r5:be920898 r4:00000050 sys_bpf from ret_fast_syscall+0x0/0x54 Exception stack(0xdfb55fa8 to 0xdfb55ff0) 5fa0: 00000050 be920898 0000000a be920898 00000050 012abc70 5fc0: 00000050 be920898 0000000a 00000182 008c5319 b6f6bd80 00000000 012c27b8 5fe0: be920870 be920860 008ee593 b6e79f72 ---[ end trace 0000000000000000 ]--- torvalds#404 stream_syscall:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED This occurs because streams kernel code assumes 8-byte char buf alignment within both 'struct bpf_stream_page' and 'struct bpf_stream_elem', and makes bpf_stream_page_push_elem() round up consumed space to 8-bytes. This scheme breaks on 32-bit because bpf_stream_elem member 'struct llist_node' is pointer-sized and so triggers a warning in bpf_stream_page_check_room(): int min = offsetof(struct bpf_stream_elem, str[0]); int consumed = stream_page->consumed; int total = BPF_STREAM_PAGE_SZ; int rem = max(0, total - consumed - min); /* Let's give room of at least 8 bytes. */ WARN_ON_ONCE(rem % 8 != 0); Fix by instead rounding and checking alignment against 'sizeof(long)'. Fixes: 5ab154f ("bpf: Introduce BPF standard streams") Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com>
BPF selftests for streams commonly trigger warnings on 32-bit armhf like: root@qemu-armhf:~/kselftests-bpf# ./test_progs -a stream_syscall ------------[ cut here ]------------ WARNING: CPU: 0 PID: 86 at kernel/bpf/stream.c:107 bpf_stream_page_check_room+0x78/0x7c Modules linked in: bpf_testmod(OE) CPU: 0 UID: 0 PID: 86 Comm: test_progs Tainted: G OE 6.16.0-rc3-00371-g38238de3a9ea torvalds#44 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Generic DT based system Call trace: dump_backtrace from show_stack+0x20/0x24 r7:c031a62c r6:00000009 r5:600f0093 r4:c12b927c show_stack from dump_stack_lvl+0x70/0x7c dump_stack_lvl from dump_stack+0x18/0x1c r5:0000006b r4:c12cd464 dump_stack from __warn+0x8c/0x128 __warn from warn_slowpath_fmt+0x184/0x18c r8:ddde5f40 r7:c031a62c r6:c12cd464 r5:00000000 r4:c189b304 warn_slowpath_fmt from bpf_stream_page_check_room+0x78/0x7c r7:c2e2a907 r6:00000003 r5:00000fec r4:00000fec bpf_stream_page_check_room from bpf_stream_page_reserve_elem+0x3c/0x12c r7:c2e2a907 r6:800f0013 r5:00000003 r4:c4012000 bpf_stream_page_reserve_elem from bpf_stream_elem_alloc+0x5c/0x70 r7:c2e2a907 r6:800f0013 r5:00000000 r4:c189af5c bpf_stream_elem_alloc from bpf_stream_vprintk+0x134/0x1a8 r7:c2e2a907 r6:c274c400 r5:00000000 r4:00000000 bpf_stream_vprintk from bpf_prog_acae6871cd11984a_stream_syscall+0xe4/0x12c r9:ffffffff r8:fffffff8 r7:ffffffff r6:c031ab50 r5:be920898 r4:c2cd2a00 bpf_prog_acae6871cd11984a_stream_syscall from bpf_prog_test_run_syscall+0xdc/0x2ac r10:df93b000 r9:00000000 r8:00000051 r7:00000000 r6:00000000 r5:be920898 r4:c2cd2a00 bpf_prog_test_run_syscall from __sys_bpf+0x580/0xda8 r10:00000000 r9:be920898 r8:00000051 r7:00000000 r6:0000000a r5:dfb55eb0 r4:df93b000 __sys_bpf from sys_bpf+0x34/0x3c r10:00000182 r9:c2cd2a00 r8:c0100268 r7:00000182 r6:0000000a r5:be920898 r4:00000050 sys_bpf from ret_fast_syscall+0x0/0x54 Exception stack(0xdfb55fa8 to 0xdfb55ff0) 5fa0: 00000050 be920898 0000000a be920898 00000050 012abc70 5fc0: 00000050 be920898 0000000a 00000182 008c5319 b6f6bd80 00000000 012c27b8 5fe0: be920870 be920860 008ee593 b6e79f72 ---[ end trace 0000000000000000 ]--- torvalds#404 stream_syscall:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED This occurs because streams kernel code assumes 8-byte char buf alignment within both 'struct bpf_stream_page' and 'struct bpf_stream_elem', and makes bpf_stream_page_push_elem() round up consumed space to 8-bytes. This scheme breaks on 32-bit because bpf_stream_elem member 'struct llist_node' is pointer-sized and so triggers a warning in bpf_stream_page_check_room(): int min = offsetof(struct bpf_stream_elem, str[0]); int consumed = stream_page->consumed; int total = BPF_STREAM_PAGE_SZ; int rem = max(0, total - consumed - min); /* Let's give room of at least 8 bytes. */ WARN_ON_ONCE(rem % 8 != 0); Fix by instead rounding and checking alignment against 'sizeof(long)'. Fixes: 5ab154f ("bpf: Introduce BPF standard streams") Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com>
BPF selftests for streams commonly trigger warnings on 32-bit armhf like: root@qemu-armhf:~/kselftests-bpf# ./test_progs -a stream_syscall ------------[ cut here ]------------ WARNING: CPU: 0 PID: 86 at kernel/bpf/stream.c:107 bpf_stream_page_check_room+0x78/0x7c Modules linked in: bpf_testmod(OE) CPU: 0 UID: 0 PID: 86 Comm: test_progs Tainted: G OE 6.16.0-rc3-00371-g38238de3a9ea torvalds#44 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Generic DT based system Call trace: dump_backtrace from show_stack+0x20/0x24 r7:c031a62c r6:00000009 r5:600f0093 r4:c12b927c show_stack from dump_stack_lvl+0x70/0x7c dump_stack_lvl from dump_stack+0x18/0x1c r5:0000006b r4:c12cd464 dump_stack from __warn+0x8c/0x128 __warn from warn_slowpath_fmt+0x184/0x18c r8:ddde5f40 r7:c031a62c r6:c12cd464 r5:00000000 r4:c189b304 warn_slowpath_fmt from bpf_stream_page_check_room+0x78/0x7c r7:c2e2a907 r6:00000003 r5:00000fec r4:00000fec bpf_stream_page_check_room from bpf_stream_page_reserve_elem+0x3c/0x12c r7:c2e2a907 r6:800f0013 r5:00000003 r4:c4012000 bpf_stream_page_reserve_elem from bpf_stream_elem_alloc+0x5c/0x70 r7:c2e2a907 r6:800f0013 r5:00000000 r4:c189af5c bpf_stream_elem_alloc from bpf_stream_vprintk+0x134/0x1a8 r7:c2e2a907 r6:c274c400 r5:00000000 r4:00000000 bpf_stream_vprintk from bpf_prog_acae6871cd11984a_stream_syscall+0xe4/0x12c r9:ffffffff r8:fffffff8 r7:ffffffff r6:c031ab50 r5:be920898 r4:c2cd2a00 bpf_prog_acae6871cd11984a_stream_syscall from bpf_prog_test_run_syscall+0xdc/0x2ac r10:df93b000 r9:00000000 r8:00000051 r7:00000000 r6:00000000 r5:be920898 r4:c2cd2a00 bpf_prog_test_run_syscall from __sys_bpf+0x580/0xda8 r10:00000000 r9:be920898 r8:00000051 r7:00000000 r6:0000000a r5:dfb55eb0 r4:df93b000 __sys_bpf from sys_bpf+0x34/0x3c r10:00000182 r9:c2cd2a00 r8:c0100268 r7:00000182 r6:0000000a r5:be920898 r4:00000050 sys_bpf from ret_fast_syscall+0x0/0x54 Exception stack(0xdfb55fa8 to 0xdfb55ff0) 5fa0: 00000050 be920898 0000000a be920898 00000050 012abc70 5fc0: 00000050 be920898 0000000a 00000182 008c5319 b6f6bd80 00000000 012c27b8 5fe0: be920870 be920860 008ee593 b6e79f72 ---[ end trace 0000000000000000 ]--- torvalds#404 stream_syscall:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED This occurs because streams kernel code assumes 8-byte char buf alignment within both 'struct bpf_stream_page' and 'struct bpf_stream_elem', and makes bpf_stream_page_push_elem() round up consumed space to 8-bytes. This scheme breaks on 32-bit because bpf_stream_elem member 'struct llist_node' is pointer-sized and so triggers a warning in bpf_stream_page_check_room(): int min = offsetof(struct bpf_stream_elem, str[0]); int consumed = stream_page->consumed; int total = BPF_STREAM_PAGE_SZ; int rem = max(0, total - consumed - min); /* Let's give room of at least 8 bytes. */ WARN_ON_ONCE(rem % 8 != 0); Fix by instead rounding and checking alignment against 'sizeof(long)'. Fixes: 5ab154f ("bpf: Introduce BPF standard streams") Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com>
BPF selftests for streams commonly trigger warnings on 32-bit armhf like: root@qemu-armhf:~/kselftests-bpf# ./test_progs -a stream_syscall ------------[ cut here ]------------ WARNING: CPU: 0 PID: 86 at kernel/bpf/stream.c:107 bpf_stream_page_check_room+0x78/0x7c Modules linked in: bpf_testmod(OE) CPU: 0 UID: 0 PID: 86 Comm: test_progs Tainted: G OE 6.16.0-rc3-00371-g38238de3a9ea torvalds#44 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Generic DT based system Call trace: dump_backtrace from show_stack+0x20/0x24 r7:c031a62c r6:00000009 r5:600f0093 r4:c12b927c show_stack from dump_stack_lvl+0x70/0x7c dump_stack_lvl from dump_stack+0x18/0x1c r5:0000006b r4:c12cd464 dump_stack from __warn+0x8c/0x128 __warn from warn_slowpath_fmt+0x184/0x18c r8:ddde5f40 r7:c031a62c r6:c12cd464 r5:00000000 r4:c189b304 warn_slowpath_fmt from bpf_stream_page_check_room+0x78/0x7c r7:c2e2a907 r6:00000003 r5:00000fec r4:00000fec bpf_stream_page_check_room from bpf_stream_page_reserve_elem+0x3c/0x12c r7:c2e2a907 r6:800f0013 r5:00000003 r4:c4012000 bpf_stream_page_reserve_elem from bpf_stream_elem_alloc+0x5c/0x70 r7:c2e2a907 r6:800f0013 r5:00000000 r4:c189af5c bpf_stream_elem_alloc from bpf_stream_vprintk+0x134/0x1a8 r7:c2e2a907 r6:c274c400 r5:00000000 r4:00000000 bpf_stream_vprintk from bpf_prog_acae6871cd11984a_stream_syscall+0xe4/0x12c r9:ffffffff r8:fffffff8 r7:ffffffff r6:c031ab50 r5:be920898 r4:c2cd2a00 bpf_prog_acae6871cd11984a_stream_syscall from bpf_prog_test_run_syscall+0xdc/0x2ac r10:df93b000 r9:00000000 r8:00000051 r7:00000000 r6:00000000 r5:be920898 r4:c2cd2a00 bpf_prog_test_run_syscall from __sys_bpf+0x580/0xda8 r10:00000000 r9:be920898 r8:00000051 r7:00000000 r6:0000000a r5:dfb55eb0 r4:df93b000 __sys_bpf from sys_bpf+0x34/0x3c r10:00000182 r9:c2cd2a00 r8:c0100268 r7:00000182 r6:0000000a r5:be920898 r4:00000050 sys_bpf from ret_fast_syscall+0x0/0x54 Exception stack(0xdfb55fa8 to 0xdfb55ff0) 5fa0: 00000050 be920898 0000000a be920898 00000050 012abc70 5fc0: 00000050 be920898 0000000a 00000182 008c5319 b6f6bd80 00000000 012c27b8 5fe0: be920870 be920860 008ee593 b6e79f72 ---[ end trace 0000000000000000 ]--- torvalds#404 stream_syscall:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED This occurs because streams kernel code assumes 8-byte char buf alignment within both 'struct bpf_stream_page' and 'struct bpf_stream_elem', and makes bpf_stream_page_push_elem() round up consumed space to 8-bytes. This scheme breaks on 32-bit because bpf_stream_elem member 'struct llist_node' is pointer-sized and so triggers a warning in bpf_stream_page_check_room(): int min = offsetof(struct bpf_stream_elem, str[0]); int consumed = stream_page->consumed; int total = BPF_STREAM_PAGE_SZ; int rem = max(0, total - consumed - min); /* Let's give room of at least 8 bytes. */ WARN_ON_ONCE(rem % 8 != 0); Fix by instead rounding and checking alignment against 'sizeof(long)'. Fixes: 5ab154f ("bpf: Introduce BPF standard streams") Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com>
BPF selftests for streams commonly trigger warnings on 32-bit armhf like: root@qemu-armhf:~/kselftests-bpf# ./test_progs -a stream_syscall ------------[ cut here ]------------ WARNING: CPU: 0 PID: 86 at kernel/bpf/stream.c:107 bpf_stream_page_check_room+0x78/0x7c Modules linked in: bpf_testmod(OE) CPU: 0 UID: 0 PID: 86 Comm: test_progs Tainted: G OE 6.16.0-rc3-00371-g38238de3a9ea torvalds#44 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Generic DT based system Call trace: dump_backtrace from show_stack+0x20/0x24 r7:c031a62c r6:00000009 r5:600f0093 r4:c12b927c show_stack from dump_stack_lvl+0x70/0x7c dump_stack_lvl from dump_stack+0x18/0x1c r5:0000006b r4:c12cd464 dump_stack from __warn+0x8c/0x128 __warn from warn_slowpath_fmt+0x184/0x18c r8:ddde5f40 r7:c031a62c r6:c12cd464 r5:00000000 r4:c189b304 warn_slowpath_fmt from bpf_stream_page_check_room+0x78/0x7c r7:c2e2a907 r6:00000003 r5:00000fec r4:00000fec bpf_stream_page_check_room from bpf_stream_page_reserve_elem+0x3c/0x12c r7:c2e2a907 r6:800f0013 r5:00000003 r4:c4012000 bpf_stream_page_reserve_elem from bpf_stream_elem_alloc+0x5c/0x70 r7:c2e2a907 r6:800f0013 r5:00000000 r4:c189af5c bpf_stream_elem_alloc from bpf_stream_vprintk+0x134/0x1a8 r7:c2e2a907 r6:c274c400 r5:00000000 r4:00000000 bpf_stream_vprintk from bpf_prog_acae6871cd11984a_stream_syscall+0xe4/0x12c r9:ffffffff r8:fffffff8 r7:ffffffff r6:c031ab50 r5:be920898 r4:c2cd2a00 bpf_prog_acae6871cd11984a_stream_syscall from bpf_prog_test_run_syscall+0xdc/0x2ac r10:df93b000 r9:00000000 r8:00000051 r7:00000000 r6:00000000 r5:be920898 r4:c2cd2a00 bpf_prog_test_run_syscall from __sys_bpf+0x580/0xda8 r10:00000000 r9:be920898 r8:00000051 r7:00000000 r6:0000000a r5:dfb55eb0 r4:df93b000 __sys_bpf from sys_bpf+0x34/0x3c r10:00000182 r9:c2cd2a00 r8:c0100268 r7:00000182 r6:0000000a r5:be920898 r4:00000050 sys_bpf from ret_fast_syscall+0x0/0x54 Exception stack(0xdfb55fa8 to 0xdfb55ff0) 5fa0: 00000050 be920898 0000000a be920898 00000050 012abc70 5fc0: 00000050 be920898 0000000a 00000182 008c5319 b6f6bd80 00000000 012c27b8 5fe0: be920870 be920860 008ee593 b6e79f72 ---[ end trace 0000000000000000 ]--- torvalds#404 stream_syscall:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED This occurs because streams kernel code assumes 8-byte char buf alignment within both 'struct bpf_stream_page' and 'struct bpf_stream_elem', and makes bpf_stream_page_push_elem() round up consumed space to 8-bytes. This scheme breaks on 32-bit because bpf_stream_elem member 'struct llist_node' is pointer-sized and so triggers a warning in bpf_stream_page_check_room(): int min = offsetof(struct bpf_stream_elem, str[0]); int consumed = stream_page->consumed; int total = BPF_STREAM_PAGE_SZ; int rem = max(0, total - consumed - min); /* Let's give room of at least 8 bytes. */ WARN_ON_ONCE(rem % 8 != 0); Fix by instead rounding and checking alignment against 'sizeof(long)'. Fixes: 5ab154f ("bpf: Introduce BPF standard streams") Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com>
BPF selftests for streams commonly trigger warnings on 32-bit armhf like: root@qemu-armhf:~/kselftests-bpf# ./test_progs -a stream_syscall ------------[ cut here ]------------ WARNING: CPU: 0 PID: 86 at kernel/bpf/stream.c:107 bpf_stream_page_check_room+0x78/0x7c Modules linked in: bpf_testmod(OE) CPU: 0 UID: 0 PID: 86 Comm: test_progs Tainted: G OE 6.16.0-rc3-00371-g38238de3a9ea torvalds#44 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Generic DT based system Call trace: dump_backtrace from show_stack+0x20/0x24 r7:c031a62c r6:00000009 r5:600f0093 r4:c12b927c show_stack from dump_stack_lvl+0x70/0x7c dump_stack_lvl from dump_stack+0x18/0x1c r5:0000006b r4:c12cd464 dump_stack from __warn+0x8c/0x128 __warn from warn_slowpath_fmt+0x184/0x18c r8:ddde5f40 r7:c031a62c r6:c12cd464 r5:00000000 r4:c189b304 warn_slowpath_fmt from bpf_stream_page_check_room+0x78/0x7c r7:c2e2a907 r6:00000003 r5:00000fec r4:00000fec bpf_stream_page_check_room from bpf_stream_page_reserve_elem+0x3c/0x12c r7:c2e2a907 r6:800f0013 r5:00000003 r4:c4012000 bpf_stream_page_reserve_elem from bpf_stream_elem_alloc+0x5c/0x70 r7:c2e2a907 r6:800f0013 r5:00000000 r4:c189af5c bpf_stream_elem_alloc from bpf_stream_vprintk+0x134/0x1a8 r7:c2e2a907 r6:c274c400 r5:00000000 r4:00000000 bpf_stream_vprintk from bpf_prog_acae6871cd11984a_stream_syscall+0xe4/0x12c r9:ffffffff r8:fffffff8 r7:ffffffff r6:c031ab50 r5:be920898 r4:c2cd2a00 bpf_prog_acae6871cd11984a_stream_syscall from bpf_prog_test_run_syscall+0xdc/0x2ac r10:df93b000 r9:00000000 r8:00000051 r7:00000000 r6:00000000 r5:be920898 r4:c2cd2a00 bpf_prog_test_run_syscall from __sys_bpf+0x580/0xda8 r10:00000000 r9:be920898 r8:00000051 r7:00000000 r6:0000000a r5:dfb55eb0 r4:df93b000 __sys_bpf from sys_bpf+0x34/0x3c r10:00000182 r9:c2cd2a00 r8:c0100268 r7:00000182 r6:0000000a r5:be920898 r4:00000050 sys_bpf from ret_fast_syscall+0x0/0x54 Exception stack(0xdfb55fa8 to 0xdfb55ff0) 5fa0: 00000050 be920898 0000000a be920898 00000050 012abc70 5fc0: 00000050 be920898 0000000a 00000182 008c5319 b6f6bd80 00000000 012c27b8 5fe0: be920870 be920860 008ee593 b6e79f72 ---[ end trace 0000000000000000 ]--- torvalds#404 stream_syscall:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED This occurs because streams kernel code assumes 8-byte char buf alignment within both 'struct bpf_stream_page' and 'struct bpf_stream_elem', and makes bpf_stream_page_push_elem() round up consumed space to 8-bytes. This scheme breaks on 32-bit because bpf_stream_elem member 'struct llist_node' is pointer-sized and so triggers a warning in bpf_stream_page_check_room(): int min = offsetof(struct bpf_stream_elem, str[0]); int consumed = stream_page->consumed; int total = BPF_STREAM_PAGE_SZ; int rem = max(0, total - consumed - min); /* Let's give room of at least 8 bytes. */ WARN_ON_ONCE(rem % 8 != 0); Fix by instead rounding and checking alignment against 'sizeof(long)'. Fixes: 5ab154f ("bpf: Introduce BPF standard streams") Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com>
BPF selftests for streams commonly trigger warnings on 32-bit armhf like: root@qemu-armhf:~/kselftests-bpf# ./test_progs -a stream_syscall ------------[ cut here ]------------ WARNING: CPU: 0 PID: 86 at kernel/bpf/stream.c:107 bpf_stream_page_check_room+0x78/0x7c Modules linked in: bpf_testmod(OE) CPU: 0 UID: 0 PID: 86 Comm: test_progs Tainted: G OE 6.16.0-rc3-00371-g38238de3a9ea torvalds#44 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Generic DT based system Call trace: dump_backtrace from show_stack+0x20/0x24 r7:c031a62c r6:00000009 r5:600f0093 r4:c12b927c show_stack from dump_stack_lvl+0x70/0x7c dump_stack_lvl from dump_stack+0x18/0x1c r5:0000006b r4:c12cd464 dump_stack from __warn+0x8c/0x128 __warn from warn_slowpath_fmt+0x184/0x18c r8:ddde5f40 r7:c031a62c r6:c12cd464 r5:00000000 r4:c189b304 warn_slowpath_fmt from bpf_stream_page_check_room+0x78/0x7c r7:c2e2a907 r6:00000003 r5:00000fec r4:00000fec bpf_stream_page_check_room from bpf_stream_page_reserve_elem+0x3c/0x12c r7:c2e2a907 r6:800f0013 r5:00000003 r4:c4012000 bpf_stream_page_reserve_elem from bpf_stream_elem_alloc+0x5c/0x70 r7:c2e2a907 r6:800f0013 r5:00000000 r4:c189af5c bpf_stream_elem_alloc from bpf_stream_vprintk+0x134/0x1a8 r7:c2e2a907 r6:c274c400 r5:00000000 r4:00000000 bpf_stream_vprintk from bpf_prog_acae6871cd11984a_stream_syscall+0xe4/0x12c r9:ffffffff r8:fffffff8 r7:ffffffff r6:c031ab50 r5:be920898 r4:c2cd2a00 bpf_prog_acae6871cd11984a_stream_syscall from bpf_prog_test_run_syscall+0xdc/0x2ac r10:df93b000 r9:00000000 r8:00000051 r7:00000000 r6:00000000 r5:be920898 r4:c2cd2a00 bpf_prog_test_run_syscall from __sys_bpf+0x580/0xda8 r10:00000000 r9:be920898 r8:00000051 r7:00000000 r6:0000000a r5:dfb55eb0 r4:df93b000 __sys_bpf from sys_bpf+0x34/0x3c r10:00000182 r9:c2cd2a00 r8:c0100268 r7:00000182 r6:0000000a r5:be920898 r4:00000050 sys_bpf from ret_fast_syscall+0x0/0x54 Exception stack(0xdfb55fa8 to 0xdfb55ff0) 5fa0: 00000050 be920898 0000000a be920898 00000050 012abc70 5fc0: 00000050 be920898 0000000a 00000182 008c5319 b6f6bd80 00000000 012c27b8 5fe0: be920870 be920860 008ee593 b6e79f72 ---[ end trace 0000000000000000 ]--- torvalds#404 stream_syscall:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED This occurs because streams kernel code assumes 8-byte char buf alignment within both 'struct bpf_stream_page' and 'struct bpf_stream_elem', and makes bpf_stream_page_push_elem() round up consumed space to 8-bytes. This scheme breaks on 32-bit because bpf_stream_elem member 'struct llist_node' is pointer-sized and so triggers a warning in bpf_stream_page_check_room(): int min = offsetof(struct bpf_stream_elem, str[0]); int consumed = stream_page->consumed; int total = BPF_STREAM_PAGE_SZ; int rem = max(0, total - consumed - min); /* Let's give room of at least 8 bytes. */ WARN_ON_ONCE(rem % 8 != 0); Fix by instead rounding and checking alignment against 'sizeof(long)'. Fixes: 5ab154f ("bpf: Introduce BPF standard streams") Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com>
BPF selftests for streams commonly trigger warnings on 32-bit armhf like: root@qemu-armhf:~/kselftests-bpf# ./test_progs -a stream_syscall ------------[ cut here ]------------ WARNING: CPU: 0 PID: 86 at kernel/bpf/stream.c:107 bpf_stream_page_check_room+0x78/0x7c Modules linked in: bpf_testmod(OE) CPU: 0 UID: 0 PID: 86 Comm: test_progs Tainted: G OE 6.16.0-rc3-00371-g38238de3a9ea torvalds#44 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Generic DT based system Call trace: dump_backtrace from show_stack+0x20/0x24 r7:c031a62c r6:00000009 r5:600f0093 r4:c12b927c show_stack from dump_stack_lvl+0x70/0x7c dump_stack_lvl from dump_stack+0x18/0x1c r5:0000006b r4:c12cd464 dump_stack from __warn+0x8c/0x128 __warn from warn_slowpath_fmt+0x184/0x18c r8:ddde5f40 r7:c031a62c r6:c12cd464 r5:00000000 r4:c189b304 warn_slowpath_fmt from bpf_stream_page_check_room+0x78/0x7c r7:c2e2a907 r6:00000003 r5:00000fec r4:00000fec bpf_stream_page_check_room from bpf_stream_page_reserve_elem+0x3c/0x12c r7:c2e2a907 r6:800f0013 r5:00000003 r4:c4012000 bpf_stream_page_reserve_elem from bpf_stream_elem_alloc+0x5c/0x70 r7:c2e2a907 r6:800f0013 r5:00000000 r4:c189af5c bpf_stream_elem_alloc from bpf_stream_vprintk+0x134/0x1a8 r7:c2e2a907 r6:c274c400 r5:00000000 r4:00000000 bpf_stream_vprintk from bpf_prog_acae6871cd11984a_stream_syscall+0xe4/0x12c r9:ffffffff r8:fffffff8 r7:ffffffff r6:c031ab50 r5:be920898 r4:c2cd2a00 bpf_prog_acae6871cd11984a_stream_syscall from bpf_prog_test_run_syscall+0xdc/0x2ac r10:df93b000 r9:00000000 r8:00000051 r7:00000000 r6:00000000 r5:be920898 r4:c2cd2a00 bpf_prog_test_run_syscall from __sys_bpf+0x580/0xda8 r10:00000000 r9:be920898 r8:00000051 r7:00000000 r6:0000000a r5:dfb55eb0 r4:df93b000 __sys_bpf from sys_bpf+0x34/0x3c r10:00000182 r9:c2cd2a00 r8:c0100268 r7:00000182 r6:0000000a r5:be920898 r4:00000050 sys_bpf from ret_fast_syscall+0x0/0x54 Exception stack(0xdfb55fa8 to 0xdfb55ff0) 5fa0: 00000050 be920898 0000000a be920898 00000050 012abc70 5fc0: 00000050 be920898 0000000a 00000182 008c5319 b6f6bd80 00000000 012c27b8 5fe0: be920870 be920860 008ee593 b6e79f72 ---[ end trace 0000000000000000 ]--- torvalds#404 stream_syscall:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED This occurs because streams kernel code assumes 8-byte char buf alignment within both 'struct bpf_stream_page' and 'struct bpf_stream_elem', and makes bpf_stream_page_push_elem() round up consumed space to 8-bytes. This scheme breaks on 32-bit because bpf_stream_elem member 'struct llist_node' is pointer-sized and so triggers a warning in bpf_stream_page_check_room(): int min = offsetof(struct bpf_stream_elem, str[0]); int consumed = stream_page->consumed; int total = BPF_STREAM_PAGE_SZ; int rem = max(0, total - consumed - min); /* Let's give room of at least 8 bytes. */ WARN_ON_ONCE(rem % 8 != 0); Fix by instead rounding and checking alignment against 'sizeof(long)'. Fixes: 5ab154f ("bpf: Introduce BPF standard streams") Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com>
BPF selftests for streams commonly trigger warnings on 32-bit armhf like: root@qemu-armhf:~/kselftests-bpf# ./test_progs -a stream_syscall ------------[ cut here ]------------ WARNING: CPU: 0 PID: 86 at kernel/bpf/stream.c:107 bpf_stream_page_check_room+0x78/0x7c Modules linked in: bpf_testmod(OE) CPU: 0 UID: 0 PID: 86 Comm: test_progs Tainted: G OE 6.16.0-rc3-00371-g38238de3a9ea torvalds#44 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Generic DT based system Call trace: dump_backtrace from show_stack+0x20/0x24 r7:c031a62c r6:00000009 r5:600f0093 r4:c12b927c show_stack from dump_stack_lvl+0x70/0x7c dump_stack_lvl from dump_stack+0x18/0x1c r5:0000006b r4:c12cd464 dump_stack from __warn+0x8c/0x128 __warn from warn_slowpath_fmt+0x184/0x18c r8:ddde5f40 r7:c031a62c r6:c12cd464 r5:00000000 r4:c189b304 warn_slowpath_fmt from bpf_stream_page_check_room+0x78/0x7c r7:c2e2a907 r6:00000003 r5:00000fec r4:00000fec bpf_stream_page_check_room from bpf_stream_page_reserve_elem+0x3c/0x12c r7:c2e2a907 r6:800f0013 r5:00000003 r4:c4012000 bpf_stream_page_reserve_elem from bpf_stream_elem_alloc+0x5c/0x70 r7:c2e2a907 r6:800f0013 r5:00000000 r4:c189af5c bpf_stream_elem_alloc from bpf_stream_vprintk+0x134/0x1a8 r7:c2e2a907 r6:c274c400 r5:00000000 r4:00000000 bpf_stream_vprintk from bpf_prog_acae6871cd11984a_stream_syscall+0xe4/0x12c r9:ffffffff r8:fffffff8 r7:ffffffff r6:c031ab50 r5:be920898 r4:c2cd2a00 bpf_prog_acae6871cd11984a_stream_syscall from bpf_prog_test_run_syscall+0xdc/0x2ac r10:df93b000 r9:00000000 r8:00000051 r7:00000000 r6:00000000 r5:be920898 r4:c2cd2a00 bpf_prog_test_run_syscall from __sys_bpf+0x580/0xda8 r10:00000000 r9:be920898 r8:00000051 r7:00000000 r6:0000000a r5:dfb55eb0 r4:df93b000 __sys_bpf from sys_bpf+0x34/0x3c r10:00000182 r9:c2cd2a00 r8:c0100268 r7:00000182 r6:0000000a r5:be920898 r4:00000050 sys_bpf from ret_fast_syscall+0x0/0x54 Exception stack(0xdfb55fa8 to 0xdfb55ff0) 5fa0: 00000050 be920898 0000000a be920898 00000050 012abc70 5fc0: 00000050 be920898 0000000a 00000182 008c5319 b6f6bd80 00000000 012c27b8 5fe0: be920870 be920860 008ee593 b6e79f72 ---[ end trace 0000000000000000 ]--- torvalds#404 stream_syscall:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED This occurs because streams kernel code assumes 8-byte char buf alignment within both 'struct bpf_stream_page' and 'struct bpf_stream_elem', and makes bpf_stream_page_push_elem() round up consumed space to 8-bytes. This scheme breaks on 32-bit because bpf_stream_elem member 'struct llist_node' is pointer-sized and so triggers a warning in bpf_stream_page_check_room(): int min = offsetof(struct bpf_stream_elem, str[0]); int consumed = stream_page->consumed; int total = BPF_STREAM_PAGE_SZ; int rem = max(0, total - consumed - min); /* Let's give room of at least 8 bytes. */ WARN_ON_ONCE(rem % 8 != 0); Fix by instead rounding and checking alignment against 'sizeof(long)'. Fixes: 5ab154f ("bpf: Introduce BPF standard streams") Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com>
BPF selftests for streams commonly trigger warnings on 32-bit armhf like: root@qemu-armhf:~/kselftests-bpf# ./test_progs -a stream_syscall ------------[ cut here ]------------ WARNING: CPU: 0 PID: 86 at kernel/bpf/stream.c:107 bpf_stream_page_check_room+0x78/0x7c Modules linked in: bpf_testmod(OE) CPU: 0 UID: 0 PID: 86 Comm: test_progs Tainted: G OE 6.16.0-rc3-00371-g38238de3a9ea torvalds#44 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Generic DT based system Call trace: dump_backtrace from show_stack+0x20/0x24 r7:c031a62c r6:00000009 r5:600f0093 r4:c12b927c show_stack from dump_stack_lvl+0x70/0x7c dump_stack_lvl from dump_stack+0x18/0x1c r5:0000006b r4:c12cd464 dump_stack from __warn+0x8c/0x128 __warn from warn_slowpath_fmt+0x184/0x18c r8:ddde5f40 r7:c031a62c r6:c12cd464 r5:00000000 r4:c189b304 warn_slowpath_fmt from bpf_stream_page_check_room+0x78/0x7c r7:c2e2a907 r6:00000003 r5:00000fec r4:00000fec bpf_stream_page_check_room from bpf_stream_page_reserve_elem+0x3c/0x12c r7:c2e2a907 r6:800f0013 r5:00000003 r4:c4012000 bpf_stream_page_reserve_elem from bpf_stream_elem_alloc+0x5c/0x70 r7:c2e2a907 r6:800f0013 r5:00000000 r4:c189af5c bpf_stream_elem_alloc from bpf_stream_vprintk+0x134/0x1a8 r7:c2e2a907 r6:c274c400 r5:00000000 r4:00000000 bpf_stream_vprintk from bpf_prog_acae6871cd11984a_stream_syscall+0xe4/0x12c r9:ffffffff r8:fffffff8 r7:ffffffff r6:c031ab50 r5:be920898 r4:c2cd2a00 bpf_prog_acae6871cd11984a_stream_syscall from bpf_prog_test_run_syscall+0xdc/0x2ac r10:df93b000 r9:00000000 r8:00000051 r7:00000000 r6:00000000 r5:be920898 r4:c2cd2a00 bpf_prog_test_run_syscall from __sys_bpf+0x580/0xda8 r10:00000000 r9:be920898 r8:00000051 r7:00000000 r6:0000000a r5:dfb55eb0 r4:df93b000 __sys_bpf from sys_bpf+0x34/0x3c r10:00000182 r9:c2cd2a00 r8:c0100268 r7:00000182 r6:0000000a r5:be920898 r4:00000050 sys_bpf from ret_fast_syscall+0x0/0x54 Exception stack(0xdfb55fa8 to 0xdfb55ff0) 5fa0: 00000050 be920898 0000000a be920898 00000050 012abc70 5fc0: 00000050 be920898 0000000a 00000182 008c5319 b6f6bd80 00000000 012c27b8 5fe0: be920870 be920860 008ee593 b6e79f72 ---[ end trace 0000000000000000 ]--- torvalds#404 stream_syscall:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED This occurs because streams kernel code assumes 8-byte char buf alignment within both 'struct bpf_stream_page' and 'struct bpf_stream_elem', and makes bpf_stream_page_push_elem() round up consumed space to 8-bytes. This scheme breaks on 32-bit because bpf_stream_elem member 'struct llist_node' is pointer-sized and so triggers a warning in bpf_stream_page_check_room(): int min = offsetof(struct bpf_stream_elem, str[0]); int consumed = stream_page->consumed; int total = BPF_STREAM_PAGE_SZ; int rem = max(0, total - consumed - min); /* Let's give room of at least 8 bytes. */ WARN_ON_ONCE(rem % 8 != 0); Fix by instead rounding and checking alignment against 'sizeof(long)'. Fixes: 5ab154f ("bpf: Introduce BPF standard streams") Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com>
BPF selftests for streams commonly trigger warnings on 32-bit armhf like: root@qemu-armhf:~/kselftests-bpf# ./test_progs -a stream_syscall ------------[ cut here ]------------ WARNING: CPU: 0 PID: 86 at kernel/bpf/stream.c:107 bpf_stream_page_check_room+0x78/0x7c Modules linked in: bpf_testmod(OE) CPU: 0 UID: 0 PID: 86 Comm: test_progs Tainted: G OE 6.16.0-rc3-00371-g38238de3a9ea torvalds#44 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Generic DT based system Call trace: dump_backtrace from show_stack+0x20/0x24 r7:c031a62c r6:00000009 r5:600f0093 r4:c12b927c show_stack from dump_stack_lvl+0x70/0x7c dump_stack_lvl from dump_stack+0x18/0x1c r5:0000006b r4:c12cd464 dump_stack from __warn+0x8c/0x128 __warn from warn_slowpath_fmt+0x184/0x18c r8:ddde5f40 r7:c031a62c r6:c12cd464 r5:00000000 r4:c189b304 warn_slowpath_fmt from bpf_stream_page_check_room+0x78/0x7c r7:c2e2a907 r6:00000003 r5:00000fec r4:00000fec bpf_stream_page_check_room from bpf_stream_page_reserve_elem+0x3c/0x12c r7:c2e2a907 r6:800f0013 r5:00000003 r4:c4012000 bpf_stream_page_reserve_elem from bpf_stream_elem_alloc+0x5c/0x70 r7:c2e2a907 r6:800f0013 r5:00000000 r4:c189af5c bpf_stream_elem_alloc from bpf_stream_vprintk+0x134/0x1a8 r7:c2e2a907 r6:c274c400 r5:00000000 r4:00000000 bpf_stream_vprintk from bpf_prog_acae6871cd11984a_stream_syscall+0xe4/0x12c r9:ffffffff r8:fffffff8 r7:ffffffff r6:c031ab50 r5:be920898 r4:c2cd2a00 bpf_prog_acae6871cd11984a_stream_syscall from bpf_prog_test_run_syscall+0xdc/0x2ac r10:df93b000 r9:00000000 r8:00000051 r7:00000000 r6:00000000 r5:be920898 r4:c2cd2a00 bpf_prog_test_run_syscall from __sys_bpf+0x580/0xda8 r10:00000000 r9:be920898 r8:00000051 r7:00000000 r6:0000000a r5:dfb55eb0 r4:df93b000 __sys_bpf from sys_bpf+0x34/0x3c r10:00000182 r9:c2cd2a00 r8:c0100268 r7:00000182 r6:0000000a r5:be920898 r4:00000050 sys_bpf from ret_fast_syscall+0x0/0x54 Exception stack(0xdfb55fa8 to 0xdfb55ff0) 5fa0: 00000050 be920898 0000000a be920898 00000050 012abc70 5fc0: 00000050 be920898 0000000a 00000182 008c5319 b6f6bd80 00000000 012c27b8 5fe0: be920870 be920860 008ee593 b6e79f72 ---[ end trace 0000000000000000 ]--- torvalds#404 stream_syscall:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED This occurs because streams kernel code assumes 8-byte char buf alignment within both 'struct bpf_stream_page' and 'struct bpf_stream_elem', and makes bpf_stream_page_push_elem() round up consumed space to 8-bytes. This scheme breaks on 32-bit because bpf_stream_elem member 'struct llist_node' is pointer-sized and so triggers a warning in bpf_stream_page_check_room(): int min = offsetof(struct bpf_stream_elem, str[0]); int consumed = stream_page->consumed; int total = BPF_STREAM_PAGE_SZ; int rem = max(0, total - consumed - min); /* Let's give room of at least 8 bytes. */ WARN_ON_ONCE(rem % 8 != 0); Fix by instead rounding and checking alignment against 'sizeof(long)'. Fixes: 5ab154f ("bpf: Introduce BPF standard streams") Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com>
Files changed 272