This finally migrated in lunar, so I can sponsor/adjust the other uploads. Will try to get to this tomorrow.
-- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1992454 Title: iptables: segfault when renaming a chain Status in iptables package in Ubuntu: Fix Released Status in iptables source package in Bionic: In Progress Status in iptables source package in Focal: In Progress Status in iptables source package in Jammy: In Progress Status in iptables source package in Kinetic: In Progress Bug description: [ Impact ] * An explanation of the effects of the bug on users This is the description for the upstream fix of this bug[1] : This is an odd bug: If the number of chains is right and one renames the last one in the list, libiptc dereferences a NULL pointer. * An explanation of the effects of the bug on users and * justification for backporting the fix to the stable release. Without this patch, users may experience segmentation fault when using the following versions of iptables : - Bionic : iptables - Focal : iptables - Jammy : iptables-legacy * In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug. The upstream fix adjust the size of the chain_index if the element is the last chain in the list. [1] http://git.netfilter.org/iptables/commit/?id=97bf4e68fc0794adba3243fd96f40f4568e7216f [ Test Plan ] * detailed instructions how to reproduce the bug The following code (adapted from the upstream commit to work on Kinetic) may be used to reproduce the issue : ----------------------------------------8<-------------------------------- #!/bin/bash # # Cover for a bug in libiptc: # - the chain 'node-98-tmp' is the last in the list sorted by name # - there are 81 chains in total, so three chain index buckets # - the last index bucket contains only the 'node-98-tmp' chain # => rename temporarily removes it from the bucket, leaving a NULL bucket # behind which is dereferenced later when inserting the chain again with new # name again ( echo "*filter" for chain in node-1 node-10 node-101 node-102 node-104 node-107 node-11 node-12 node-13 node-14 node-15 node-16 node-17 node-18 node-19 node-2 node-20 node-21 node-22 node-23 node-25 node-26 node-27 node-28 node-29 node-3 node-30 node-31 node-32 node-33 node-34 node-36 node-37 node-39 node-4 node-40 node-41 node-42 node-43 node-44 node-45 node-46 node-47 node-48 node-49 node-5 node-50 node-51 node-53 node-54 node-55 node-56 node-57 node-58 node-59 node-6 node-60 node-61 node-62 node-63 node-64 node-65 node-66 node-68 node-69 node-7 node-70 node-71 node-74 node-75 node-76 node-8 node-80 node-81 node-86 node-89 node-9 node-92 node-93 node-95 node-98-tmp; do echo ":$chain - [0:0]" done echo "COMMIT" ) | $XT_MULTI iptables-legacy-restore $XT_MULTI iptables-legacy -E node-98-tmp node-98 exit $? ---------------------------------------->8-------------------------------- [ Where problems could occur ] For Jammy and onward, only users of the -legacy commands may be affected. Since Jammy, iptables uses the new nft libraries which are not affected by the bug. For Bionic and Focal users, the regular iptables command is affected by the change. As stated in the manpage : E, --rename-chain old-chain new-chain Rename the user specified chain to the user supplied name. This is cosmetic, and has no effect on the structure of the table. In case of a problem, only the modification of the name would be affected as this is clearly outlined as a cosmetic only change. [ Other Info ] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1992454/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
