[HN Gopher] A 17-line C program freezes the Mac kernel (2018)
___________________________________________________________________
A 17-line C program freezes the Mac kernel (2018)
Author : goranmoomin
Score : 114 points
Date : 2022-12-09 18:28 UTC (4 hours ago)
(HTM) web link (jvns.ca)
(TXT) w3m dump (jvns.ca)
| anon291 wrote:
| Not surprised. I wrote some kqueue code in C once that not only
| froze the Mac Kernel. It caused the entire computer to crash. I
| reported the issue to Apple, and never really heard back. They
| don't really care, as long as all the mac store apps work, in my
| experience.
|
| This was one call to kqueue with incorrect (but not particularly
| malicious, just normal C silliness) arguments, and boom!
| catiopatio wrote:
| Is it still reproducible?
| anon291 wrote:
| I haven't had a mac in years. This was ~2010.
| amenghra wrote:
| In 2017, I wrote:
|
| _Over the years, I have found numerous four different bugs in
| Apple 's Calculator app. Here is today's wtf.
|
| Switch calculator to Scientific mode ([?]-2). Type: 1, 0, ^, 2,
| 0, enter, command-c (to copy), command-v (to paste)
|
| Expected result: an amount in $$$ I wouldn't mind having.
| Actual result: smallest number to appear 6 times in Pascal's
| triangle
|
| I reported all four and they never acknowledged any of them.
| They didn't fix any of them either. Doesn't motivate anyone to
| report more bugs to them._
|
| Some of the bugs got auto-closed after a while. Eventually, the
| bugs did get fixed, except the clipboard thing -\\_(tsu)_/-.
| jwilk wrote:
| > smallest number to appear 6 times in Pascal's triangle
|
| You mean exacty 6 times or at least 6 times?
| amenghra wrote:
| Exactly 6 times. What's happening is if the result is
| 1e<something>, a roundtrip to the clipboard results in
| 1<something>. I.e. 1e20 becomes 120.
| JonathonW wrote:
| Bugs _do_ get fixed (eventually; they 're not always timely
| about it depending on severity), but Apple's feedback systems
| are and always have been a black hole. Basically, as a
| reporter, the only time you hear anything back from Apple about
| a bug report is if they need additional information; nothing
| else in their process is visible externally (until you go back
| and retest a few macOS releases later and your bug is or isn't
| fixed).
| resters wrote:
| I asked ChatGPT to write some programs like this and it refused!
| throwaway09223 wrote:
| It's surprisingly easy to stumble into crash bugs when playing
| around with processes.
|
| I remember a decade or two ago I ran into a linux bug where the
| kernel would panic if a process was killed with an open
| descriptor on its /proc entries. That is:
|
| open /proc/$pid/something; kill -9 $pid #kernel crash
|
| We unfortunately discovered this when using fuser in a runscript
| to kill stale versions of a process, eg:
|
| sudo fuser --kill --namespace tcp 80 # kill whatever is listening
| on port 80
|
| This would reliably cause kernel panics every so often, with one
| straightforward shell command. This ended up causing a big
| problem because it was part of a runscript which ran on bootup.
| But, it normally would do nothing so it went unnoticed until the
| app in question had a startup problem, leaving a copy of itself
| dangling listening on the port -- and instead of killing the old
| instance, it began crashing the entire system in a loop. Oops.
| teawrecks wrote:
| It was also unsurprisingly easy to crash a kernel a decade or
| two ago.
| [deleted]
| [deleted]
| IceWreck wrote:
| Is this fixed now ?
| kayodelycaon wrote:
| Tested it on macOS 12.3. It's fixed.
| eesmith wrote:
| https://github.com/hishamhm/htop/issues/682#issuecomment-377.
| .. (the htop issue) says "according to others above, Apple
| has seemingly fixed this in 10.13.4."
| kayodelycaon wrote:
| It's freezing the querying of process status, which is very not
| good, but that isn't the entire kernel. If it was the entire
| kernel, you wouldn't be able to use Ctrl+C.
| anyfoo wrote:
| Yes. The title of the actual blog post seems more accurate.
| throwawaaarrgh wrote:
| It's very easy to freeze a system as a non-root user; cause too
| many interrupts, consume too many resources, etc. Many kinds of
| infinite loop will lock a system hard. Hell, you can crash
| systems with _too many packets_.
|
| And it's very easy to cause _ps_ to hang. Many different kernel
| syscalls hang / are blocking. Mostly you see this with kernel
| features dependent on a resource that doesn't resolve itself,
| like a stuck disk, network filesystem, etc. But other various
| quirks of the system can cause blocking.
| adrian_b wrote:
| While what you say is true, these are nonetheless kernel bugs.
|
| The kernel should never let any user process consume so many
| resources as to cause a system freeze.
| hinkley wrote:
| In the long dark ago there was a program called 'crashme' which
| would generate and run random code from user space to see if it
| could cause kernel panics.
| jwilk wrote:
| https://people.delphiforums.com/gjc/crashme.html
| xcdzvyn wrote:
| I presume there's a low yet non-zero chance this
| inadvertently messes up something on the FS?
| civopsec wrote:
| Did it predate the "fuzzing" term?
| hinkley wrote:
| By at least a decade or two. The last time I saw one in the
| wild was probably around 1998, and it was a very old idea by
| then.
| byteduck wrote:
| My naive guess is that this is probably some sort of lock
| contention thing.
| alin23 wrote:
| Coincidentally, I also stumbled upon a way to make the kernel of
| Apple Silicon Macs panic and restart while developing the
| https://lowtechguys.com website.
|
| I distilled the problem in a repo so it can be reproduced with a
| single command: https://github.com/alin23/m1-panic
|
| I found it while on Monterey and reported it 2 times through
| Feedback Assistant, but it still happens on Ventura.
|
| _NOTE: Don 't try it without saving all your work, it has a very
| high chance of restarting your computer forcefully._
| macshome wrote:
| Can you put the panic log text into the repo as well?
| alin23 wrote:
| Sure, added here: https://github.com/alin23/m1-panic#panic-
| crash-report-after-...
| catiopatio wrote:
| What's the feedback ID #?
| trollied wrote:
| Might have been better to report it to the security people.
| This sort of thing can be exploitable.
| saagarjha wrote:
| It's a null deref.
| nemetroid wrote:
| They did report it to Apple, multiple times:
|
| > I found it while on Monterey and reported it 2 times
| through Feedback Assistant, but it still happens on Ventura.
| [deleted]
| metadat wrote:
| Do you know what the underlying problematic instruction
| sequence is? Or the precise location where it halts?
| alin23 wrote:
| I have no idea how I could find that, given that the system
| freezes completely.
|
| Maybe tracing the CPU instructions using LLDB might be
| possible, but the bug is most likely in the kernel code so
| this would not help much.
| catiopatio wrote:
| You can debug the kernel remotely over Ethernet:
| https://developer.apple.com/documentation/apple-
| silicon/debu...
|
| If that still fails, virtualization tools provide debugging
| interfaces you can use to step the execution of the
| virtualized CPU; e.g. VMware's "debugStub" feature.
| Firmwarrior wrote:
| haha, let's just let the Apple engineers on this thread
| figure that shit out
| saagarjha wrote:
| ldr x9, [x8, #0x18]!
| saagarjha wrote:
| Past discussion of this bug:
| https://news.ycombinator.com/item?id=16082861
___________________________________________________________________
(page generated 2022-12-09 23:00 UTC)