This doesn't seem to have anything to do with upstream vs Ubuntu kernels. For example, on Ubuntu 16.04 LTS classic I see:

$ cat /proc/version_signature 
Ubuntu 4.4.0-66.87-generic 4.4.44

$ aa-enabled 
Yes

$ snap list
Name  Version  Rev   Developer  Notes
core  16-2     1441  canonical  -

# With AppArmor in strict mode
$ sudo snap run --shell --hook=configure core # NO HANG
...
$

with the following denials:
Mar 24 09:46:37 sec-xenial-amd64 kernel: [ 4103.232237] audit: type=1400 audit(1490366797.640:77): apparmor="DENIED" operation="create" profile="snap.core.hook.configure" pid=2407 comm="snapctl" family="inet" sock_type="stream" protocol=6 requested_mask="create" denied_mask="create"
Mar 24 09:46:37 sec-xenial-amd64 kernel: [ 4103.232471] audit: type=1400 audit(1490366797.640:78): apparmor="DENIED" operation="create" profile="snap.core.hook.configure" pid=2407 comm="snapctl" family="inet6" sock_type="stream" protocol=6 requested_mask="create" denied_mask="create"
Mar 24 09:46:37 sec-xenial-amd64 kernel: [ 4103.232579] audit: type=1400 audit(1490366797.640:79): apparmor="DENIED" operation="create" profile="snap.core.hook.configure" pid=2407 comm="snapctl" family="inet6" sock_type="stream" protocol=6 requested_mask="create" denied_mask="create"
Mar 24 09:46:37 sec-xenial-amd64 kernel: [ 4103.237185] audit: type=1400 audit(1490366797.644:80): apparmor="DENIED" operation="open" profile="snap.core.hook.configure" name="/run/snapd.socket" pid=2407 comm="snapctl" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0


If I add the following to the apparmor profile (or put the profile in complain mode with "sudo sed -i 's/attach_disconnected/attach_disconnected,complain'/ /var/lib/snapd/apparmor/profiles/snap.core.hook.configure"):
network inet,
network inet6,
/run/snapd.socket rw,


and reload:
$ sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.core.hook.configure


then run hook:
$ sudo snap run --shell --hook=configure core # HANG

I see:
Mar 24 09:47:56 sec-xenial-amd64 kernel: [ 4181.864114] audit: type=1326 audit(1490366876.272:82): auid=1000 uid=0 gid=0 ses=1 pid=2440 comm="snapctl" exe="/usr/bin/snapctl" sig=31 arch=c000003e syscall=49 compat=0 ip=0x563064039294 code=0x0

$ scmp_sys_resolver 49
bind

I can then add 'bind' to /var/lib/snapd/seccomp/profiles/snap.core.hook.configure and try again it runs without hanging:
$ sudo snap run --shell --hook=configure core # NO HANG
...
$


What the above clearly shows is that if apparmor policy is adjusted to not block the accesses snapctl is attempting, then snapctl hits a seccomp denial for bind. This explains why systems with apparmor disabled but seccomp enabled see this problem.

Digging into this more, if the apparmor policy is adjusted to have (and bind is removed from the seccomp policy):

#network inet,
network inet6,
#/run/snapd.socket rw,

I can reproduce the hang:
$ sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.core.hook.configure && sudo snap run --shell --hook=configure core # HANG

Ie, the '/run/snapd.socket rw' rule has no effect and is a red herring. I maintain my point in comment #4 that snapctl attempting to use /run/snapd.socket is causing confusion. Please either change snapctl or add 'deny /run/snapd.socket rw,' to all configure hook policy (I prefer the former since adding the explicit deny rule means a hook can never 'plugs: snapd-control).

What's interesting is that while Go's use of inet/inet6 (ie, bug #1644573) is triggering an inet and inet6 denial, there is a second inet6 denial that, when allowed, I suspect it allows the code to proceed to the point of the 'bind' seccomp denial. snapctl's use of bind() should be investigated and either avoided or conditionally add 'bind' to all configure hook policy.