**** BEGIN LOGGING AT Sun May 24 02:59:59 2020 May 24 12:10:37 hauke: jow: just stumbled across the "brcm47xx: disable Netgear WNR2000 v2 by default" patch still in patchwork: May 24 12:10:43 https://patchwork.ozlabs.org/project/openwrt/patch/20191116202346.31885-14-jo@mein.io/ May 24 12:11:06 should it be applied (after fixed) or deleted? May 24 12:15:41 adrianschmutzler: I think this patch should be fixed May 24 12:16:05 the wnr3500l has 8MB flash May 24 12:16:15 Hauke: so apply it, but for the wnr2000v2 only? May 24 12:16:31 cause I would do this then ... May 24 12:27:45 adrianschmutzler: I think that should be ok May 24 12:28:10 I think jow added the wnr3500l accidentially May 24 12:29:10 I also do, and since this is lying around for about half a year, I'm happy to assume that and have it off the table :-) May 24 12:50:10 adrianschmutzler: thanks for merging my wndr4300sw patch. for uboot-envtools, do I just provide a patch stating 'add uboot-envtools support for $model'? May 24 12:50:50 I think I included a link, just do it like that ... May 24 12:51:14 uboot-envtools: ath79: add Netgear WNDR3700v2 May 24 12:51:16 you did, will do, thanks. May 24 12:51:22 just with the proper name May 24 12:51:47 I didn't add it myself since there are different settings for v1 and v2, so one should have a proper look May 24 12:52:19 package history is quite helpful in these cases: https://github.com/openwrt/openwrt/commits/master/package/boot/uboot-envtools/files/ath79 May 24 12:52:33 :) May 24 13:45:15 adrianschmutzler: please add https://git.openwrt.org/bc0c2db2a3a8fc790496d4eee481361ef903749c also to master May 24 14:23:19 Hauke: I checked before, and it looks like the whole patchset was only applied to 19.07, so I followed suit (most probably since the stable branch adds additional packages by default, so an image failing with stable would not necessarily fail with master). So, the question is whether we should apply all of them to master as well (as they will brake next stable release anyway) or keep them, hoping that at least sna May 24 14:23:59 brake->break May 24 14:32:27 adrianschmutzler: you last message was cut off May 24 14:32:47 "hoping that at least sna" May 24 14:32:55 hoping that at least snapshots will work and thus have additional devices for community testing. IIRC also the forum thread was about 19.07 images ... May 24 14:33:12 adrianschmutzler: ok, we only add luci to the stable builds May 24 14:33:15 thanks for telling, haven't been notified by the client May 24 14:33:21 so snapshot should still work May 24 14:33:33 and with the next release we will remove all the 4MB devices anyway May 24 14:33:48 ok then I am fine May 24 14:52:35 adrianschmutzler: irc messages are silently truncated. Different clients have additional scripts to split long messages automatically, e.g. irssi has autowrap.pl May 24 16:01:22 neoraider: FYI https://gitlab.com/openwrt/project/libubox/-/jobs/565368042 May 24 16:02:00 rmilecki: ^ May 24 16:05:50 neoraider: thanks for that ucert testcase May 24 16:11:53 I've reproduced the fuzzer crash here as well, so it's real May 24 16:12:48 running `echo AQQAAAABAAA1JQ== | base64 -d > tests/fuzz/corpus/crash-e0f8ecc694d96a09a1fced27b2a0838b670d34a0` is enough May 24 16:15:19 looks like an artificially truncated blob? May 24 16:21:04 yeah, fuzzer art May 24 16:21:14 (didn't checked the blob content) May 24 16:27:02 *yawn* May 24 16:40:47 ynezz: did your cdr appliance already arrive ? May 24 17:39:00 blogic: how do we want to handle swig? curently the mt7629 u-boot build is depending on it and makes the build bot fail May 24 17:39:43 for I removed the swig dependency from u-boot for sunxi u-boot, but I would also be fine if we make swig now a normal dependecy for OpenWrt May 24 17:52:54 its installed on my machine so i did not spot the dependency May 24 17:55:43 blogic: the binman part of u-boot uses it May 24 17:57:11 ok May 24 17:57:17 i can look tomorrow May 24 17:57:31 adding wifi-vlan and wifi-station to /e/c/wireless just now May 24 17:57:41 so we can run multi vlan/psk on a single BSS May 24 17:57:52 guest net 2.0 here we come .... May 24 17:58:51 blogic: but it still needs a PSK, so you can not run OWE and SAE on the same BSS? May 24 18:04:11 no May 24 18:04:24 but i was thinking that we should propose this as an extension May 24 18:04:39 so there is the usual psk IE and then a new one for extra auth like eap May 24 18:04:53 woudl certainly reduce 6mbit beacon spam May 24 18:05:13 blogic: do you know if this is possible with current standards? May 24 18:05:19 it is not May 24 18:05:21 checked today May 24 18:05:34 the various auth modes are non exclusive May 24 18:06:12 i am anxious to find out if multi psk will work with iwlwav May 24 18:06:18 Hauke: do you have a rax40 ? May 24 18:06:19 what I am really missing is authentication of APs, that each AP can authenticate itself with a public key and the client stores it like an SSH public key May 24 18:06:23 leds are on sso May 24 18:06:24 blogic: no May 24 18:06:29 kk May 24 18:06:41 I have never used any Wav device May 24 18:06:41 yeah May 24 18:06:47 Hauke: hahah May 24 18:06:52 *no comment* May 24 18:07:04 Hauke: like a post auth cert verification ? May 24 18:07:17 or real cert auth and then dynamic strong key exchange May 24 18:07:28 the SSO is supposed to be used for LEDs May 24 18:07:37 this way less pins on the SoC are needed May 24 18:07:53 so you have 1 or 2 wires to the SSO and can then drive 32 LEDs May 24 18:08:17 yeah May 24 18:08:23 but its borked on 8.4.70 May 24 18:08:28 and the fix i was given dont work May 24 18:09:15 I didn't try SSO for a longer time May 24 18:09:26 normally I do not care about LEDs ;-) May 24 18:09:34 blinken lights May 24 18:10:06 there were some changes 8 months ago about the clock source for the SSO May 24 18:10:36 CONFIG_LANTIQ_PHY implicit clock dep May 24 18:10:47 but turnign that on dont make my leds blink May 24 18:11:05 what do you mean with "CONFIG_LANTIQ_PHY implicit clock dep" ? May 24 18:12:01 .70 does not turn on CONFIG_LANTIQ_PHY due to a performance regression in bonding setups May 24 18:12:19 but that symbols apparently does somthing that sso needs for it to work May 24 18:12:27 ah this problem ;-) May 24 18:12:33 yes May 24 18:12:35 that one May 24 18:12:36 I was unaware this is related to SSO May 24 18:12:44 intels bug dependency tree May 24 18:14:38 grrr May 24 18:14:49 netifd segs May 24 18:14:59 now to find the bug in my last commit May 24 18:20:55 regarding wifi, it would be nice if the client sends a challange, and the AP signs it and sends it public key May 24 18:21:19 this could be an additional optional step May 24 18:21:49 then the client can store this public key and checks that do automatic conection only to this same AP May 24 18:22:49 Like when I start an AP named "WIFIonICE" clients would start to connect to it when they ever used the Wifi in Deutsche Bahn trains May 24 18:23:07 they would connect automatically if they do not have a better wifi May 24 18:35:10 hmm this sounds like an intresting project May 24 18:58:56 https://i.redd.it/l2jm2w8pxo051.jpg lol May 24 19:49:57 ynezz: neoraider: i see some test failure, for the commit ("blob: make blob_parse_untrusted more permissive") May 24 19:50:34 ynezz: neoraider: was 5e75160 ("blobmsg: fix attrs iteration in the blobmsg_check_array_len()") tested on its own, so we can we know my change is OK? May 24 20:06:55 rmilecki: your change was tested on its own, it failed with a similar error: https://gitlab.com/openwrt/project/libubox/-/jobs/565328935 May 24 20:17:07 rmilecki: commit 5e75160 makes no sense imho May 24 20:17:49 jow: :| why? May 24 20:18:25 it uses an iterator that does not work with untrusted data May 24 20:20:12 __blobmsg_for_each_attr() decrements the previously initialized rem by the amount of bytes each nested attribute occupies and it ensures that the next nested attributes fits within the remaining `rem` value May 24 20:20:14 jow: so should I use blob_len and somehow reduce it by a header size? May 24 20:20:50 blobmsg_for_each_attr() takes the length information from the blob data itself, making it unsafe for use with untrusted data May 24 20:22:31 apart from that they appear to be semantically identical May 24 20:22:48 so your commit does not appear to fix anything but to introduce a potential security issue (?) May 24 20:23:00 see: https://lxr.openwrt.org/source/libubox/blobmsg.h#L320 May 24 20:23:01 jow: it 100% fixes the problem for me May 24 20:23:22 i won't argue it's correct solution though May 24 20:23:27 maybe but the solution is wrong May 24 20:26:27 rmilecki: I think the proper fix would be changing the sole call site of blobmsg_check_array_len() May 24 20:26:33 rmilecki: https://lxr.openwrt.org/source/libubox/blobmsg.c#L117 May 24 20:26:56 change blob_len(attr) to blob_pad_len(attr), this is what blobmsg_for_each_attr() is using internally May 24 20:27:56 this should fix your problem in the same way but will not lower the security of blobmsg_check_array_len() for api users passing oob size information May 24 20:28:01 oh fun blob vs blobmsg voodood May 24 20:28:14 rmilecki: having fun ?! :-D May 24 20:28:22 nc May 24 20:28:39 lulz May 24 20:28:49 i was so happy about having right solutiona after Felix review :| May 24 20:29:02 blob_len() = size of payload May 24 20:29:12 blob_raw_len() = size of payload + header May 24 20:29:25 and then there is pad_lan May 24 20:29:34 blob_pad_len() = size of payload + header + 4 byte alignment May 24 20:29:36 only 8 permutations May 24 20:29:43 :| May 24 20:30:58 however I don't understand why/how your fix changes things May 24 20:31:35 if your iterator would *shorten* the iteration we wouldn't reach the blobmsg_check_attr_len() / return -1 check May 24 20:31:51 erm if it would *lengthen* it I mean May 24 20:32:10 so the original code seems to iterate more compared to your change May 24 20:32:30 yes, it was iterating over random memroy May 24 20:32:51 I assume it will yield one additional cycle pointing to garbage May 24 20:33:36 which is puzzling, since that would imply that the blob_len() result of the attr we're iterating is wrong (payload length too long / longer than the actually initialized contained memory) May 24 20:33:49 jow: see http://lists.infradead.org/pipermail/openwrt-devel/2020-May/023514.html there are two iterations: May 24 20:33:51 [instance_fill_array] [for_each_attr] blobmsg_name(sub): core blobmsg_type(sub): 3 (BLOBMSG_TYPE_STRING) May 24 20:33:52 [instance_fill_array] [for_each_attr] blobmsg_name(sub): blobmsg_type(sub): 5 (BLOBMSG_TYPE_INT32) May 24 20:34:08 the second one was over "empty" name attr of type 5 (INT) May 24 20:34:17 that was how that random memroy got interpreted May 24 20:34:38 and type mismatch (all attrs were expected to be STRINGs) - it returned with false May 24 20:35:37 the problem is elsewhere then May 24 20:36:10 your fix just solves this particular case because it trusts the length fields of the corrupted data structure May 24 20:36:39 somehow the overall payload length of the containing array does not agree with the sum of the length of the nested attributes May 24 20:37:20 do we know the call chain leading to this? May 24 20:37:37 what is building the array we're iterating here? May 24 20:37:51 jow: see "Backtrace" in http://lists.infradead.org/pipermail/openwrt-devel/2020-May/023514.html May 24 20:38:15 updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html May 24 20:52:47 rmilecki: this was netifd, right? May 24 20:53:01 jow: right May 24 20:53:36 but don't expect to reproduce that, it happens for me on 1 device only, without too many debugging messages added only May 24 20:58:34 in your debug output I've seen the string "core", so I assume it happen while parsing the "limit" array in the service definitions May 24 20:59:02 I wonder if that limits array happens to be the last member of the entire service blobmsg May 24 20:59:47 if yes, we simply might be passing along a wrong payload length all the time May 24 21:02:40 json key order is undefined May 24 21:03:02 not sure if the json to blobmsg conversion enforces any kind of stable internal order, but Iguess not May 24 21:03:39 so maybe the reason why you only occasionally see the problem is that only sometimes a table which is checked by instance_fill_array() happens to be the last member of the blobmsg May 24 21:03:55 thats just speculation though May 24 21:06:30 I randomly checked various blobmsg_parse() call sites and they all seem to invoke it with blob_data(attr), blob_len(attr) May 24 21:07:07 while procd uses blobmsg_data(in->config), blobmsg_data_len(in->config) May 24 21:08:47 the origin of in->config is here: https://lxr.openwrt.org/source/procd/service/service.c#L154 May 24 21:10:00 means we're in the middle of iterating a blobmsg and we pass the nested instance table attribute as *config to service_instance_add() May 24 21:12:46 rmilecki: can you test this change: https://pastebin.com/WKxa4z3s ? May 24 21:13:05 oops, i missed your messages above May 24 21:13:40 correction, this one: https://pastebin.com/QaXTrxPh May 24 21:14:00 maybe with a printf to compre blobmsg_data_len(in->config) with blob_len(in->config) May 24 21:15:50 I always though that blobmsg is the outermost blob... thing May 24 21:15:59 while all nested attributes are blobs May 24 21:16:26 so it seems odd to treat a nested blob attribute as blobmsg May 24 21:16:29 jow: this is output of PROCD_DEBUG=1 /etc/init.d/network restart https://files.zajec.net/openwrt/procd-111029.txt May 24 21:16:43 (regarding "limits" question) May 24 21:16:55 jow: i'll check your patch tomorrow, it's too late for me today, sorry May 24 21:17:02 np, for me as well May 24 22:28:58 build #81 of lantiq/ase is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/lantiq%2Fase/builds/81 May 24 22:49:15 jow: please invest some 30 seconds again to activate the json building. I started to rebuild all targets just to have the profiles.json https://images.aparcar.org/minio/rebuild/ May 24 22:56:28 build #82 of x86/64 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/x86%2F64/builds/82 **** ENDING LOGGING AT Mon May 25 02:59:57 2020