[Galaxy Note GT-N7000 General] Entropy512:
I have realized this post was sorely outdated. I have updated it partially, but more updates are needed.

Reinbeau asked me to summarize the situation with ICS leaks in a way that can be stickied, so here it is:

DO NOT FLASH OR WIPE USING ANY ICS REPACK OR STOCK KERNEL

While stock recovery is safer than CWM recovery, there is still evidence that it is dangerous.. Almost all ICS kernels for the GT-N7000 are affected. Only two are currently known to be safe - see the list below.

These kernels are fundamentally dangerous. They can trigger an underlying defect in the flash chip, and once this defect is triggered, the damage is unrepairable, not even with JTAG. Note that for danger, three things are needed:

1) A defective eMMC chip - Nearly every Note has this

2) A kernel that allows MMC ERASE commands to go through - All Samsung ICS stock kernels and leaks fall into this category

3) A recovery or update-binary within a ZIP that attempts to erase a partition when formatting. Unmodified CWM performs a secure erase, which is the most dangerous. Stock recovery performs a nonsecure erase, which is less dangerous but there is still evidence of danger.

The issue is not limited to just Clockworkmod Recovery - Stock recovery, along with factory resetting a device from Settings, can also be dangerous. When XXLPY first came out, a number of people bricked this way. Stock recovery is less dangerous due to using nonsecure erase rather than secure erase, but it has yet to be proven to be fully safe.

Kernels that have been confirmed affected are:

All ICS leaks for the Samsung Epic 4G Touch (SPH-D710)

All ICS leaks for the Samsung Galaxy Note (GT-N7000)

All ICS official releases for the Samsung Galaxy Note (GT-N7000) as of late May 2012 - This includes XXLPY, ZSLPF, and DXLP9, and future kernels should be assumed affected until further notice.

UCLD3 ICS leak for the AT&T Samsung Galaxy S II (SGH-I777) - Other leaks may also be affected

Kernels built using the most recent SHW-M250S/K/L official source code release as of May 3, 2012 - This includes SiyahKernel 3.1rc6 for GT-I9100 (all other Siyah releases are safe)

Damage is not guaranteed - it may only affect a small percentage of users, but even a 5% chance is far more dangerous than the effectively 0% chance of hardbricking due to kernel bugs in safe kernels.

Not all users hardbrick - some wind up with /system, /data, or another partition becoming unwriteable, which leads to an effectively useless phone even though they are able to flash kernels in Odin.

Kernels that have been confirmed safe:

All known Gingerbread kernels for the Galaxy Note and other affected devices listed above

Kernels built from the GT-I9100 Update4 source code release - this includes XplodWILD's CM9 release and my DAFUQ release, hopefully more kernel choices will become available soon

Kernels with MMC_CAP_ERASE removed from mshci.c should be safe - look for it in the listed features of any kernel based off of N7000 Update3. (N7000 Update3 source code without this change made to render it safe is dangerous.)

If you are running an affected kernel:

STOP USING IT IMMEDIATELY. FLASH A SAFE KERNEL USING ODIN/HEIMDALL.

DO NOT wipe in recovery

DO NOT flash anything else in recovery

In general, DO NOT use recovery at all

Right now, what we know:

Some people can wipe with affected kernels as often as they want without problems. Just because you didn't brick, DO NOT advise other users that they will be OK.

Based on reports from the Epic 4G Touch community, some people can wipe/flash 20-30 times before hardbricking - Just because you didn't brick once, DO NOT continue flashing with an affected kernel

What we don't know:

*this needs to be completely updated*

More info:

http://xdaforums.com/showthread.php?t=1607112 - Hardbricks on I777 UCLD3

http://xdaforums.com/showthread.php?t=1615058 - Issues with SHW-M250L Update4

http://xdaforums.com/showpost.php?p=26255080&postcount=159 - Information indicating that our eMMC chip has a serious firmware bug. All of the issues with fwrev 0x19 match our symptoms PERFECTLY. It explains partially why I9100 update4 is safe - MMC_CAP_ERASE is not enabled in the I9100 update4 MMC driver.