This is caused by a race condition between one thread performing a tablespace delete and another doing a compressed page flush list relocation. The latter thread will remove a dirty, thus present on the flush list, uncompressed page image from page hash and LRU list, set its status to BUF_BLOCK_REMOVE_HASH. Then the former thread would call buf_pool_get_dirty_pages_count(), find such page there and assert.

A debug-only issue.

Not a bug in Oracle, since they take both flush list and buffer pool mutex in buf_pool_get_dirty_pages_count(), preventing seeing flush list just before the flush list relocation.

Even though buf_pool_get_dirty_pages_count() is not present in 5.5, a cursory glance at 5.5 suggests that the code there needs to be checked to not assume that for every page in the flush list buf_page_in_file() holds. Probably other places in 5.6 too.

In 5.6, if the LRU list mutex is held in addition to the flush list mutex, no BUF_BLOCK_REMOVE_HASH pages can be seen on the flush list. This is not the case for buf_do_flush_list_batch(), thus one of its subroutines buf_flush_page_and_try_neighbors() may hit the same issue. Likewise in buf_get_latched_pages_number_instance().

And the asserting code is inside the function buf_flush_page_and_try_neighbors()

Based on Laurynas' comment #13 the assertion raised from inside the function buf_flush_page_and_try_neighbors() looks similar to me.

Unfortunately the stack traces are not really helpful:
131111 23:07:37 InnoDB: Assertion failure in thread 140023754589952 in
file buf0flu.c line 1608
InnoDB: Failing assertion: buf_page_in_file(bpage)
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB:http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
05:07:37 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this
binary
or one of the libraries it was linked against is corrupt, improperly
built,
or misconfigured. This error can also be caused by malfunctioning
hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Please help us make Percona Server better by reporting any
bugs at http://bugs.percona.com/

key_buffer_size=33554432
read_buffer_size=131072
max_used_connections=33
max_threads=3002
thread_count=26
connection_count=26
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads =
6602304 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x40000
/opt/percona-server-5.5.34/bin/mysqld(my_print_stacktrace
+0x35)[0x7eb7c5]
/opt/percona-server-5.5.34/bin/mysqld(handle_fatal_signal
+0x3f4)[0x6a5ce4]
/lib64/libpthread.so.0[0x31e000f500]
/lib64/libc.so.6(gsignal+0x35)[0x31df8328e5]
/lib64/libc.so.6(abort+0x175)[0x31df8340c5]
/opt/percona-server-5.5.34/bin/mysqld[0x8953b7]
/opt/percona-server-5.5.34/bin/mysqld[0x895b8e]
/opt/percona-server-5.5.34/bin/mysqld[0x895e30]
/opt/percona-server-5.5.34/bin/mysqld[0x83b67d]
/lib64/libpthread.so.0[0x31e0007851]
/lib64/libc.so.6(clone+0x6d)[0x31df8e894d]
You may download the Percona Server operations manual by visitinghttp://www.percona.com/software/percona-server/. You may find
information
in the manual which will help you identify the cause of the crash.

If this is indeed the same bug, is there any chance for the fix to be backported from 5.6.13

The 5.6 crash was BUF_BLOCK_REMOVE_HASH pages unexpectedly encountered in some paths. To see if the 5.5 crash is the same issue or something else, a "thread apply all bt" in GDB or a core dump is needed.

131216 6:39:18 InnoDB: Assertion failure in thread 140026689693440 in
file buf0buf.ic line 749
InnoDB: Failing assertion: buf_page_in_file(bpage)
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
12:39:18 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Please help us make Percona Server better by reporting any
bugs at http://bugs.percona.com/

key_buffer_size=33554432
read_buffer_size=131072
max_used_connections=37
max_threads=3002
thread_count=29
connection_count=29
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads =
6602304 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x40000
/opt/percona-server-5.5.34/bin/mysqld(my_print_stacktrace+0x35)[0x7eb555]
/opt/percona-server-5.5.34/bin/mysqld(handle_fatal_signal+0x3f4)[0x6a5a84]
/lib64/libpthread.so.0[0x31e000f500]
/lib64/libc.so.6(gsignal+0x35)[0x31df8328e5]
/lib64/libc.so.6(abort+0x175)[0x31df8340c5]
/opt/percona-server-5.5.34/bin/mysqld[0x8a6506]
/opt/percona-server-5.5.34/bin/mysqld[0x8a69fe]
/opt/percona-server-5.5.34/bin/mysqld[0x8a6ca0]
/opt/percona-server-5.5.34/bin/mysqld[0x84c3bd]
/lib64/libpthread.so.0[0x31e0007851]
/lib64/libc.so.6(clone+0x6d)[0x31df8e894d]
You may download the Percona Server operations manual by visitinghttp://www.percona.com/software/percona-server/. You may find information
in the manual which will help you identify the cause of the crash.

The symptoms appear to be similar, there is a race condition between a user thread doing BP page relocation and at the same time the master thread attempting to flush the page as part of a bigger batch.